Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Do IAM Roles Keep Cloud Keys Away From Coding Agents?

A role on an instance takes the static key out of the file and leaves a temporary credential that any process on the machine can collect from the metadata address, the coding agent included. Ask which process obtains the role's credential, how long it lasts and what narrows it before you attach one.

A credential reference travels from a browser record through a bounded route to a separate API destination.

Platform teams that run coding agents on instance roles have stopped putting a cloud key in a file, and the role does that job. It does not remove the credential from the machine; it changes where on the machine the credential lives and who can reach it. What the role issues is a temporary credential, and on a cloud instance that credential waits at a link-local address that every process on the machine can call, with no list of allowed callers. The agent is one of those processes, and so is a package the agent installed and a build step it started. This means the role settles the file half of the title and leaves what is still within reach to a separate control. The evidence is what AWS documents about access keys, AssumeRole, Secrets Manager and a token vault built for agents, what OWASP's CI/CD guidance says about credential hygiene, and what the research record says about credentials in source and in web text. A browser control covers the rendered page and most of the credential work in this question happens outside it, so each section says which control answers which half. The worked record is one agent on one instance that curls 169.254.169.254 for the role's credentials and then opens the IAM console page for the role it has just used, and the owner of that agent should know which control covers each step.

Key findings

  • AWS's IAM guide states plainly that "IAM users with access keys are an account security risk" (AWS, Manage access, 2026).
  • The AssumeRole call "Returns a set of temporary security credentials that you can use to access AWS resources," and what the session may do is "the intersection of the role's identity-based policy and the session policies," a grant that says nothing about which process may ask for it (AWS, AssumeRole, 2026).
  • The Model Context Protocol's security guidance records that "Cloud metadata endpoints often expose IAM credentials, API keys, and other secrets" (Model Context Protocol, 2026).
  • OWASP's CI/CD guidance says to "Prefer using temporary credentials over static credentials," a rule a role satisfies at the moment it is attached and a session policy narrows afterward (OWASP, 2026).
  • A governed environment replaces values chosen by policy with consistent tokens before any model reads the screen, so a console page shows ACCT_001 where the account number sits (What Is Least Exposure?).
  • Real values resolve only at the approved destination at the moment a named person approves the action, and every screen and approval is written to a record that exports to the organization's monitoring (What Is a Tethered Agent?).

What does a governed browser environment cover when the agent runs on an instance role?

A governed browser environment covers what an agent reads and does on a rendered page: a cloud console, a role summary page, an access key table, a settings page, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. The split matters because the title names two places. The role is enforced wherever the call is made, and the page is what the model sees when the agent checks its own work.

Most of the credential work happens on the far side of that line. An agent asks the metadata address for the role's credential inside a terminal session, and no page-level control changes what that request returns. The same agent then opens the console to read the trust policy or list the account's access keys, and those pages render values the model keeps.

The record type on this page is one agent on one instance that curls 169.254.169.254 for the role's credentials and then opens the IAM console page for the role it has just used. The first step is governed by the role and any session policy attached to it. The second is governed by what the page renders. A team that scopes the role and stops there has bounded what a stolen credential can do and has not touched what the model read.

Launching an instance from a console is a task with steps that commit the account, and five of them cannot be taken back (How to Use AI Agents to Launch an EC2 GPU Instance). A role attached at launch hands the agent the authority for all five at once.

Where does an instance role's credential come from, and who else can fetch it?

The instance profile points at a role, and the platform makes that role's credentials available at the metadata address. A process sends a request to 169.254.169.254 and receives a credential with a session token. No password and no prompt sit in between, which is the gain over a key pasted into a configuration and also the exposure. The address answers any process that asks, and nothing on the instance separates the agent from a test runner or a package installed a minute earlier.

The Model Context Protocol's security guidance puts the risk in one line: "Cloud metadata endpoints often expose IAM credentials, API keys, and other secrets" (Model Context Protocol, 2026). The guidance is written for server implementers and does not address how a coding agent's own credentials are held, so it records the exposure without proposing a control for it.

What makes the caller list unpredictable is that the agent adds to it. Code generating models invent package names at a rate of "at least 5.2% for commercial models and 21.7% for open-source models," so an install step can put unreviewed code on the instance (Spracklen et al., 2025).

Scope decides what the credential can do, and a session policy narrows it further when one is passed. Neither decides who may obtain it, which is a property of the instance. Is It Safe to Let an AI Agent Set Up Your Cloud Environment? reaches the same point from the account side, where the root user's access keys are the durable form of the same exposure.

What do IAM roles remove, and what do they leave?

A role removes a static key from the machine's files. A key in a file works until someone revokes it, survives a reboot and travels into images and backups. SecretBench counts "97,479 secrets (of which 15,084 are true secrets)" in source code, the population a role keeps a key out of (Basak et al., 2023).

What the role leaves is a credential issued on demand to whoever can reach the endpoint, a different shape of risk rather than a smaller one. Expiry does the work, and it is what OWASP's guidance points at: "Prefer using temporary credentials over static credentials" (OWASP, 2026).

Custody is the part a role does not decide. AWS documents the store alternative in one sentence: "You replace hard-coded credentials with a runtime call to the Secrets Manager service to retrieve credentials dynamically when you need them," a call that hands the value to whichever process makes it (AWS, What, 2026).

The same guidance adds a rule an instance role breaks by construction: "Avoid sharing the same set of credentials across multiple contexts" (OWASP, 2026). Every process on the instance shares the role. That is the difference between a key that moved from a file into the air and an identity issued per task, the question taken up in How Do You Let an AI Agent Manage API Keys Without Reading Them?.

What do the vendors themselves say?

The AWS pages reviewed describe issuance, scope, storage and attribution, and each stops short of the page the agent renders.

A call "Returns a set of temporary security credentials that you can use to access AWS resources," the session's permissions are "the intersection of the role's identity-based policy and the session policies," the duration "can range from 900 seconds (15 minutes) up to the maximum session duration set for the role," and "Role chaining limits your AWS CLI or AWS API role session to a maximum of one hour" (AWS, AssumeRole, 2026). All four govern the call, and none says which process on the instance may ask for the credential.

Amazon's developer guide for a credential provider says it "stores the resulting credentials in the token vault, and provides the agent with the necessary access tokens," which keeps a client secret out of code and still leaves the agent holding a usable token (AWS, Configure, 2026). An AWS security blog post describes the vault as built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets," with the agent retrieving them under its own workload token (Douglas III and Abrom, 2025). What that custody means for a coding agent is read in Does AWS Bedrock Keep Company Credentials Away From Agents?.

The Well-Architected Agentic AI Lens asks for a separation a shared instance role does not make, so that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, AGENTSEC03-BP02, 2026). An action taken with an instance role is attributed to the role, and the role belongs to a machine that runs several processes.

Dimension AWS, per its documentation What a buyer should verify
Credential form Temporary credentials from AssumeRole, from 900 seconds to the role's maximum The session duration set on the role, and whether chaining cuts it to an hour
Scope Intersection of the role policy and the session policy Who can edit the role policy, and whether a session policy is passed at all
Storage Secrets Manager rotation and runtime retrieval; a token vault for agent credentials Whether the agent receives a value or a token for it
Page exposure Not described in the pages reviewed What the model reads on the role page and the access key table

Does a role change what the model reads on the pages the agent opens?

No. A role governs a call, and a call returns data. The model reads whatever the response holds, whatever the console renders and whatever the agent writes into its own notes. On the role page that means the trust policy, the attached policy documents, the account identifier and the ARNs of the resources the role can reach. On the access key table it means key identifiers and last-used dates, which are enough to plan an attack without the credential.

The record on credentials in public text explains why a value on a page matters: "11,908 Live Secrets were detected using TruffleHog in 400TB of web data," and "2.76 Million Web Pages contained live secrets" (Truffle Security, 2025). The post does not establish that any named corpus included those pages, so it is cited for the standing supply of real values in text.

Rendered pages are also where injected instructions arrive. In a measured environmental injection attack on generalist web agents, the success rate at stealing users' specific personal information reached 70 percent (Can an AI Agent Sign Up for Developer Services Without Seeing Your Payment Card or Identity?). An agent holding a role's credential and reading a page it did not write is that case.

So the page decides what an injected instruction can collect. A credential that expires in an hour limits what an attacker can do with it. It does not limit what the model already read.

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders. Real values resolve only at the approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this question it covers the console. An agent that opens the role page to check its own authority reads the account number, the role ARN and the policy document as tokens such as ACCT_001 and ROLE_001, and the model drafts the next change against those placeholders. The real values resolve at the IAM endpoint when the named person approves the change.

The credential itself stays outside that control. A role's temporary credential comes from the metadata address in a terminal session, so the scope, the session policy and the instance's process list remain the controls that govern it. A governed environment does not issue the credential and does not shorten its life. It decides what the model reads on every rendered page of the run.

The narrower claim is the accurate one. Least privilege governs actions and credentials; the content of a rendered page is a separate question, and an agent can satisfy a least-privilege review in full and still hold every value it was shown.

Methodology and limitations

This page rests on AWS documentation for IAM access keys, the AssumeRole API, Secrets Manager and a credential provider for agent workloads, an AWS security blog post and the Well-Architected Agentic AI Lens, OWASP's CI/CD credential guidance, the Model Context Protocol's security guidance, two research preprints and one vendor research post. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted terms are given as the pages state them, and where a source supports only a premise, the section says so rather than presenting it as proof of the design. Where a source records a limit on its own finding, that limit sits beside the finding.

RedactSure did not test any of the named products hands-on. "Not described in the pages reviewed" means the AWS pages read for this page and nothing broader, so a feature those pages do not cover may exist without being described here. Vendor features change, and the page carries its date; a release after the read date should be treated as unreviewed until the test at the end is repeated on the current documentation. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The worked example is a record type, one agent on one instance with a role attached, and not an organization.

Determinations about whether an identity arrangement meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a review of the organization's own roles, session policies and instance inventories, or a test of which processes on a given machine can reach the metadata address and what each of them does with a credential.

What the record shows

A role answers the file half of the title and not the air half. It removes a static key from the machine and issues a temporary credential to any process that can reach the metadata address, which includes the agent and anything the agent installed. The AWS pages reviewed describe how that credential is issued, narrowed and stored, and none of them describes a control over which process may fetch it. The Well-Architected Lens asks for attribution that a role shared by a whole machine cannot give. The console page the agent opens afterward carries the policy, the account number and the key table, and the role has no effect on what that page renders; RedactSure's environment is built to render those pages as tokens. For each agent and instance role in use, the owner should test the setup by recording which process obtained the credential and what the model read on the role page afterward, and keep both answers beside the run.

Frequently asked questions

Do IAM roles keep cloud keys away from coding agents?

A role takes a long-lived key out of the environment and replaces it with a temporary credential, so the key is no longer a file anyone can copy. The credential still exists, and on an instance it sits at the metadata address where any process can request it. An agent that can run a command can obtain it. The role changes the form of the credential and not the set of processes able to receive it. It is a real gain and not a boundary.

Where does a coding agent get an instance role's credentials?

From the instance metadata address. A process running on the machine sends a request to 169.254.169.254 and receives temporary credentials for the role attached to the instance, with a session token and an expiry. No person types anything. Whether a session policy narrows the result depends on how the request is made, and without one the credential carries the role's identity policy as written. Nothing about that request requires the caller to be the agent, and nothing logs which process made it.

Does a session policy limit what a compromised agent can do?

If one is passed at the assumption, yes. The session's permissions are the intersection of the role's identity policy and the session policy, so the credential cannot exceed the role and can be held below it. The limit is the request: a process that reaches the metadata address without a session policy gets the role as it stands, so the narrowing is a choice made at the call and nothing enforces it on the agent's behalf.

Is a temporary credential safer than an access key in a file?

Usually, because it expires without anyone remembering to rotate it and it need not be stored where a snapshot can capture it. The trade is that it can be issued to a caller nobody named, which is the point about the metadata address. A key in a file is a credential someone placed; the role's credential is one the machine will hand to whichever process asks. The expiry works without anyone watching it.

What should a team check before attaching a role to an agent's instance?

Which processes the machine runs, since all of them can reach the endpoint. The role's identity policy, and whether a session policy narrows it per task. The maximum session duration and whether role chaining applies. Whether the audit trail separates the agent from the role. And whether the console pages the agent opens print the values the role protects. Each answer belongs in a written review rather than in a memory.

Can a page control keep the console out of the model's context?

A governed browser environment can render the role page as tokens, so the account number, the role ARN and the policy document arrive as placeholders such as ACCT_001 while a named person approves the real change at the endpoint. It governs the rendered page and not the metadata call, so the credential itself still follows the role's scope and its expiry. RedactSure builds that environment, and the two controls are used together on the same run, with the page as the boundary between them.

About the author

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

How RedactSure Keeps an Instance Role's Credential Out of the Model

An IAM role removes keys from files but leaves a credential any process on the machine can collect and a console page that prints the policy and keys.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the role page renders the account number, the role ARN and the policy document to the model in the clear. Inside the governed environment: the same page renders ACCT_001, ROLE_001 and POLICY_001, and the real values resolve at the IAM endpoint only on a named person's approval.

RedactSure is deploying now with enterprise and government customers. Code generating models invent package names at a rate of 5.2 percent or more.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

An instance role keeps keys off disk, but the console still shows the account and the policy. Bring a cloud task your team delegates and see, with test values, what the model reads on the role page. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.