Why Your AWS Security Tool Should Use Read-Only AssumeRole, Not Access Keys

When you connect an AWS security tool to your cloud account, the first question should not be about dashboards, charts, or how many findings it can generate.

The first question should be:

What kind of access am I giving this product?

That access model decides the blast radius if something goes wrong. It decides whether the tool becomes a safer way to understand your AWS account, or a new security liability sitting next to your production infrastructure.

For AWS security, cost, and posture tools, the safest default is usually clear:

Use a read-only IAM role assumed through AWS STS. Do not use long-lived access keys.

That sounds like a small implementation detail. It is not. It is one of the most important trust decisions in the whole product.

Access keys are the wrong default for cloud security tools

AWS access keys are simple. That is why people still use them.

You create an IAM user, generate an access key and secret key, paste them into a tool, and the tool can start calling AWS APIs.

The problem is that access keys are long-lived credentials. They are secrets. They can be copied, leaked, logged, stored incorrectly, forgotten, or reused somewhere they were never meant to exist.

That is bad in normal software.

It is worse in a security tool.

A security product is supposed to reduce risk. If it asks you to create a permanent AWS credential and paste it into a third-party system, it is asking you to add a new secret with access to the same environment it is supposed to protect.

Even if the key is read-only, the model is still uncomfortable:

• The key has to be stored somewhere.
• Someone has to rotate it.
• Someone has to know where it is used.
• If it leaks, it can keep working until it is revoked.
• If permissions are too broad, the damage is not always obvious.
• If the tool later needs more permissions, the key often becomes more privileged over time.

Many teams start with a narrow key, then gradually add permissions because something breaks. After a few months, nobody remembers exactly why the IAM user exists or what it can see.

That is not a good foundation for a cloud security product.

AssumeRole is a cleaner model

AWS already gives us a better pattern: cross-account IAM roles with STS AssumeRole.

Instead of creating an IAM user and handing out long-lived keys, the customer creates an IAM role inside their AWS account. That role trusts a specific external AWS principal. When the tool needs to scan, it calls AWS STS and asks to assume that role.

If the request is allowed, AWS returns temporary credentials.

Those credentials expire automatically.

That changes the security model in a useful way.

The tool does not need a permanent access key for your account. It gets short-lived credentials for a specific role, for a specific session, with permissions defined in your AWS account.

If you want to remove access, you remove the trust policy or delete the role. There is no forgotten access key sitting in a vendor database. There is no secret you need to rotate inside the vendor product.

For a cloud security scanner, that is a much better default.

Read-only still needs to mean read-only

There is another detail teams often miss.

“Read-only” should not be a vague marketing phrase. It should map to the actual IAM policy.

For a security and posture scanner, read-only usually means the tool can call AWS APIs such as:

• List*
• Describe*
• Get* for configuration metadata
• Cost Explorer read APIs
• Security posture read APIs
• Inventory and configuration read APIs

It should not call mutating APIs such as:

• Create*
• Update*
• Delete*
• Put*
• Modify*
• Start* for destructive operations
• Stop*
• Terminate*

There are exceptions in some enterprise workflows, such as opt-in writeback to Security Hub or ticketing systems. But the core scanning path should not need write access to your infrastructure.

This matters because auto-remediation sounds attractive until you think about the failure mode.

A tool that can detect a risky security group is useful.

A tool that can automatically change that security group is powerful.

A tool that can automatically change that security group incorrectly is dangerous.

For many small and mid-size AWS teams, the right balance is simple: detect, prioritize, explain, and guide the fix. Leave the actual infrastructure change in the hands of the team that owns the system.

Metadata-only scanning is the real trust boundary

Read-only access is not enough by itself.

There is a difference between reading AWS configuration and reading customer data.

A cloud security tool usually needs to know that an S3 bucket is public. It does not need to read the objects inside the bucket.

It may need to know that a DynamoDB table exists. It does not need to scan the rows.

It may need to know that a Lambda function uses an old runtime. It does not need to read payloads, queue messages, or secret values.

That boundary matters.

For a metadata-only AWS scanner, the useful questions are:

• Which resources exist?
• Which regions are active?
• Which security groups are open to the internet?
• Which IAM users have stale access keys?
• Which roles have risky trust policies?
• Which S3 buckets are public?
• Which RDS instances are publicly reachable?
• Which services have logging, backup, encryption, or monitoring disabled?
• Which resources appear idle, oversized, or wasteful?

Those questions can be answered from configuration metadata.

The scanner does not need your application data.

• It does not need S3 object contents (s3:GetObject).
• It does not need DynamoDB items (dynamodb:Scan).
• It does not need CloudWatch log event contents.
• It does not need Secrets Manager values.
• It does not need SQS messages.
• It does not need Step Functions execution payloads.

This distinction should be obvious in the product, in the IAM policy, and in the onboarding flow. If a tool says “read-only” but quietly asks for access to data-plane APIs, that deserves scrutiny.

External ID protects against the confused deputy problem

For cross-account access, AssumeRole should also use an external ID.

The external ID exists to prevent a class of issue known as the confused deputy problem.

The short version: if a third-party SaaS has a shared AWS principal that many customers trust, one customer should not be able to trick the SaaS into using its access to another customer’s account.

External ID helps prevent that.

The customer configures the IAM role trust policy so that the third-party principal can assume the role only when it provides the expected external ID. The SaaS then includes that external ID when calling STS.

A good product should make this hard to get wrong.

The external ID should be generated by the service, tied to the customer or workspace, and shown during setup. The client should not be able to choose or override it. The trust policy should require it.

That gives both sides a cleaner trust boundary:

• The customer controls the IAM role and trust policy.
• The SaaS can only assume the role with the correct external ID.
• The role can be revoked from the customer’s AWS account.
• No long-lived AWS key needs to be stored by the SaaS.

What a good AWS security scanner should be able to see

A useful scanner still needs broad visibility. Otherwise, it cannot give a real picture of the account.

For AWS posture work, useful read-only coverage often includes:

• IAM users, roles, groups, policies, MFA devices, and access key age
• Security groups, routes, internet gateways, load balancers, and public endpoints
• S3 bucket configuration, public access settings, encryption, and logging status
• RDS, EBS, EFS, FSx, and backup configuration
• EC2, Lambda, ECS, EKS, and ECR configuration
• CloudTrail, AWS Config, GuardDuty, Security Hub, Inspector, and Macie status
• Cost Explorer, Compute Optimizer, Savings Plans, and Reserved Instance signals
• Tags, ownership metadata, environments, and resource inventory

That is a lot of surface area, but it is still configuration metadata.

The goal is not to copy your environment. The goal is to understand enough of the structure to answer operational questions:

• What is exposed?
• What is overprivileged?
• What is unencrypted?
• What is unmonitored?
• What is costing money without providing value?
• What should be fixed first?

The tradeoff: no automatic infrastructure changes

A strict read-only model has one obvious tradeoff: the tool cannot fix things for you directly.

That is intentional.

A read-only scanner can tell you that port 22 is open to the internet. It can show the affected security group. It can explain the risk. It can link to the AWS console. It can provide CLI or Terraform guidance.

But it should not silently change the rule unless you have explicitly opted into that kind of workflow.

For many teams, especially smaller AWS teams, that is the right separation of responsibility.

The product detects and prioritizes.

The engineer reviews and applies.

That keeps the scanner useful without turning it into an infrastructure automation system with dangerous permissions.

How trueno applies this model

trueno is built around this access model.

A customer connects an AWS account through a read-only IAM role. trueno assumes that role server-side through AWS STS using external ID protection. It does not ask customers to paste long-lived AWS access keys into the product.

The scanner reads AWS configuration metadata, not customer data. It uses that metadata to find security exposure, identity risk, compliance gaps, operational drift, and cost waste.

The practical result is a single posture view of the account:

• Public resources
• Risky IAM patterns
• Missing logging or monitoring
• Unencrypted or unbacked resources
• Cost waste
• Compliance gaps
• Prioritized findings and recommendations

The important part is not just that trueno can find those issues. It is that the access model is designed so the customer stays in control.

• You can revoke the IAM role.
• The credentials are short-lived.
• The scanner does not need write access.
• The scanner does not need your application data.

That is the trust foundation a cloud security product should have.

Questions to ask any AWS security vendor

Before connecting a security, cost, or posture tool to AWS, ask these questions:

1. Do you require long-lived AWS access keys?
2. Can I connect through STS AssumeRole instead?
3. Is the IAM role protected with an external ID?
4. Who generates the external ID?
5. Can the client override the external ID?
6. Do you require write permissions?
7. Which exact AWS actions are in the IAM policy?
8. Do you read configuration metadata only, or do you read customer data?
9. Do you ever call data-plane APIs like s3:GetObject or dynamodb:Scan?
10. How do I revoke access immediately?

The answers should be clear. If they are vague, that is a signal.

Security products should be held to a higher standard than normal SaaS tools because they sit close to the most sensitive parts of your infrastructure.

Final thought

The best AWS security tool is not the one with the flashiest dashboard.

It is the one you can safely connect to production.

Read-only STS AssumeRole, external ID protection, metadata-only scanning, and customer-controlled revocation are not just implementation details. They are the minimum trust model for a serious AWS posture product.

If a tool wants access to your cloud account, make it earn that trust before you connect it.

trueno was built around that principle: no agents, no stored AWS access keys, metadata-only scanning, and a read-only role you control.

That is where cloud security should start.