The trust signals developers need before connecting AWS

Developers do not trust a product because its website says it is secure. They look for evidence they can evaluate.

For a tool that connects to AWS, the strongest trust signals are operational, not decorative.

Show the permission model early

Before signup, a reader should be able to answer:

• Which IAM role does the product assume?
• Is the workflow read-only or can it deploy?
• Are read and write permissions separate?
• Is the policy scoped to named actions and resources?
• How is cross-account access revoked?

Hiding these answers in a setup guide creates unnecessary friction for the engineer and the security reviewer.

State where the workload runs

“Built on AWS” and “runs in your AWS account” are different claims. The page should say which one applies.

If the product is a control plane, explain what metadata leaves the account, what remains there, and whether customer code ever executes in the vendor’s environment. If it is a runtime, explain the operational and portability trade-off directly.

Make access proportional to the job

A visualization tool should not need deployment permissions. An analysis tool should not be able to mutate the resource it is reviewing. A deploy tool may need write access, but only after the user starts an explicit deployment workflow.

The product language should reflect those distinctions. “Connect your account” is not enough context when the connection could mean very different things.

Show ownership of the output

Developers also evaluate what happens after the tool produces a result.

Can the team edit the generated CDK? Can it export the system map? Does a finding include the evidence behind it? Does removing the connection leave the AWS workload untouched?

Ownership reduces both technical and procurement risk.

Use precise maturity language

Private beta, preview, and generally available should not be interchangeable. The CTA and surrounding copy should make availability, support expectations, and likely product change clear.

A smaller honest promise builds more trust than an expansive claim that the product surface cannot yet support.

Treat trust content as product content

Permission boundaries, data flow, workload location, and exit behavior are not fine print. They are part of the product.

The best place to communicate them is next to the workflow they affect: read-only language beside account discovery, deploy-role language beside the deploy action, and ownership language beside generated code.

Trust grows when the website, documentation, IAM policy, and product behavior all tell the same story.