Read-only access needs its own product language

Read-only access is not a small implementation detail. It is a product promise.

When a tool visualizes an AWS account or analyzes a live workload, the team needs to know whether it can change anything. The answer should appear in the product language, setup flow, and IAM policy.

“Connect your account” is too vague

That phrase describes the action but not the risk. A connection could grant permission to list resources, read logs, modify infrastructure, or deploy an entire application.

Use language that names the boundary:

• Connect with a read-only role.
• Review the exact IAM actions before creating the role.
• Grant deploy access separately when a deploy workflow begins.
• Remove either role without affecting the workload.

The wording helps the reader build an accurate mental model before security review begins.

Read-only products should behave read-only

Air maps resources and relationships. Hero analyzes configuration and operational signals. Neither job requires the ability to repair or redeploy a resource.

That limitation should exist in the IAM role, not only in application logic. If a software bug attempts a write operation, AWS should deny it.

This is defense in depth and a clearer product contract.

Avoid “one role for convenience”

Reusing a broad role across discovery, analysis, and deployment makes initial setup shorter, but it removes an important decision from the user.

A better model keeps two trust levels:

1. A read role for inventory, relationships, configuration, and approved operational signals.
2. A write role for a specific deployment capability, assumed only when the user starts that workflow.

The roles can share account registration and external-ID handling without sharing permissions.

Explain the limits of “read-only”

Read access can still expose sensitive metadata, logs, and resource configuration. The phrase should not imply zero risk.

Documentation should state which data classes are read, why each is needed, how long derived data is retained, and whether logs or traces are optional. A security reviewer needs the full data path, not just the absence of write actions.

Put the promise where the decision happens

Repeat the boundary in the places where it reduces uncertainty:

• the product overview;
• the account-connection screen;
• the IAM policy preview;
• the confirmation before analysis starts;
• the documentation for revocation.

Clear permission language lets a team approve inspection without accidentally approving mutation. That is not only better security. It is a better product.