Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do I Let a Coding Agent Use AWS Without Giving It My Access Keys?

Never put long-lived keys in the agent's environment: have it assume a role for short-lived STS credentials with a session policy scoped to the task, and hand even those to an adapter where possible. Check the role's maximum session length and the session policy's limits, because both are set by you, not by default.

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

Cloud credentials differ from a GitHub token in a way that shapes the answer: one AWS account can issue credentials that last for months or for an hour, scoped to the whole account or to a single bucket. AWS's own guidance leans toward the short end, recommending temporary credentials from IAM roles over long-term access keys wherever the workload allows (AWS, Security best practices in, 2026). A coding agent is a workload that can almost always use a role, which makes the interesting question what the role's credentials are allowed to do, how long they last and where they sit while the agent works. The record type here is a session policy allowing one S3 bucket for one hour. The record supports three controls that work together: a short session, a session policy narrower than the role that issued it, and an adapter that holds even those credentials so the agent never does, which limits what any single mistake can reach. What Is Least Exposure? supplies the framing. Session length and session scope are kept apart throughout, because the console shows the model both.

Key findings

  • AWS recommends that workloads use temporary credentials from IAM roles rather than long-term access keys, and says that where possible it recommends "relying on temporary credentials instead of creating long-term credentials such as access keys" (AWS, Security best practices in, 2026).
  • An AssumeRole session lasts from 900 seconds up to the role's maximum of 43,200 seconds, and "by default, the value is set to 3600 seconds," so a one-hour grant is the default and anything longer is a choice (AWS, AssumeRole, 2026).
  • A session policy narrows the credential: the session's permissions are "the intersection of the role's identity-based policy and the session policies," and a session policy cannot grant more than the role allows (AWS, AssumeRole, 2026).
  • Even the safest language model agent in one emulated-sandbox study exhibited risky failures, such as irreversible actions, 23.9% of the time, so scope should assume mistakes as well as attacks (Ruan et al., 2024).
  • A governed environment that replaces values with consistent tokens before any model reads the screen means a cloud console page shows ACCT_001 and a placeholder where a key would appear (What Is Least Exposure?).
  • Real values resolve only at the approved destination, and a named person approves each consequential action, so a bucket policy change is authorized by a person and not by the model's description of it (What Is a Tethered Agent?).

What does it mean to give a coding agent AWS access without access keys?

An access key is a credential that works until someone revokes it. A temporary credential issued by the AWS Security Token Service works until it expires, and a session policy attached when it is issued narrows what it may do below what the role allows. The record type used on this page is a session policy allowing one S3 bucket for one hour. After the hour, the credential is inert whatever happens to the string.

That framing separates three questions. What authority does the agent have: one bucket. For how long: one hour. And where is the credential while the agent works: in the agent's environment, in a file, on a screen the model reads, or held by a component outside the agent's process that makes the AWS call. The first two are answered by the credential's type and policy. The third is a question of custody, and most advice about AWS credentials does not address it.

Scope note: the controls discussed here concern what an agent holds and what a broker does for it. A governed browser environment covers what an agent reads and does on a rendered page such as a cloud console, and it does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. How Do I Let a Coding Agent Create Cloud Resources Without Admin Keys? takes the creation case.

What do the vendors themselves say?

AWS's IAM best practices say workloads should use temporary credentials with IAM roles, that "there is no need to distribute long lived credentials for an IAM user to your workloads running on AWS," and that long-term access keys are for cases such as workloads that cannot use roles or third-party clients not hosted on AWS (AWS, Security best practices in, 2026). A coding agent on a developer's laptop is a workload outside AWS, which is one of the cases where the guide lists other ways to deliver temporary credentials.

The AssumeRole API reference sets the mechanics: DurationSeconds has a "minimum value of 900" and a "maximum value of 43200," the default is 3600 seconds, and the plaintext of a session policy "can't exceed 2,048 characters" (AWS, AssumeRole, 2026). The same page states that "you cannot use session policies to grant more permissions than those allowed by the identity-based policy of the role that is being assumed."

For S3, AWS's security best practices recommend that you "grant only the permissions that are required to perform a task" and "use an IAM role to manage temporary credentials for applications or services that need to access Amazon S3" (AWS, Security best practices for, 2026). Coder's documentation says "LLMs and agents can be dangerous if not run with proper boundaries" and advises separate identities with limited scope (Coder, 2026). None of these pages describes what a model reads on a console page, or a person approving an action taken with the credential.

How do short-lived credentials and session policies change the exposure?

A short-lived credential bounds the damage after exposure, and a session policy bounds the authority while it lasts. Together they turn a leak from an incident into an expiry. For the example record, a string that allows one S3 bucket for one hour is worth little to an attacker who obtains it later, and the session policy keeps it from reaching any other bucket or service. The default session of 3600 seconds already matches the one-hour grant; the minimum is 900 seconds.

They do not prevent the exposure, and they do not prevent mistakes inside the grant. In one study of language model agents tested in an emulated sandbox, "even the safest LM agent exhibits such failures 23.9% of the time," where the failures were risky actions such as irreversible ones (Ruan et al., 2024). An agent with delete rights on one bucket for one hour can still delete the bucket's contents inside that hour. Scope limits the blast radius; it does not review the action.

Property Long-lived access key Short-lived credential with session policy
Lifetime Until revoked Until it expires, such as one hour
Scope Whatever the key's identity allows Narrowed by the session policy, such as one bucket
If the agent holds the string Exposed until someone notices Exposed for the lifetime and scope only
Review needed Rotation, inventory Policy per task, approval per action

How to Set Up S3 and GitHub With Cowork or Dots reaches the same place from the pipeline side, where OIDC settles how the pipeline authenticates and the agent never receives a standing key.

Why hand even short-lived credentials to an adapter?

Because the string is still a string. If the agent holds a one-hour credential for one bucket, a prompt injection in that hour can send it, and the bucket is exposed for the hour. If an adapter holds it, the agent requests an operation, such as reading an object or listing a prefix, and the adapter performs it under the session policy and returns the result. The agent has no string to send.

Design research points the same way. One preprint proposes "principled design patterns for building AI agents with provable resistance to prompt injection" (Beurer-Kellner et al., 2025), and another describes a "simple, modular, and model-agnostic defense operating at the agent-tool interface" that reported "perfect security with high utility across all four public benchmarks," while its title asks whether stronger benchmarks are needed (Bhagwatkar et al., 2026). Both are results on benchmarks and design arguments, not deployment guarantees, and both locate the control between the model and the tool.

The adapter has costs. It becomes the custodian, so its host, logs and policy are where a review looks, and an adapter that offers every S3 operation gives the agent every S3 operation. The operation list is the real scope. How Do You Let an AI Agent Manage API Keys Without Reading Them? covers the key-handling side, and Can a Coding Agent Read My AWS Credentials File? covers the file path to the same credentials.

What does the incident record add?

Columbia's DAPLab lists incidents in which agents with broad access acted outside their task, including a Cursor agent that deleted a production database through a single rogue API call, a Replit agent that did so despite instructions not to, and a 13-hour AWS outage caused by an agent rebuilding a production environment (Columbia DAPLab, 2026). The list is a position paper's summary, not a measured rate, and none of the incidents turned on an access key as such. They show what broad authority allows.

OWASP's agentic list names the categories this page's question touches, among them ASI02 Tool Misuse and ASI03 Identity & Privilege Abuse (OWASP GenAI Security Project, 2025). Harvard's security office lists seven risk categories for AI-enabled systems, including Privilege and Identity Misuse and Sensitive Data Exposure (Harvard University Information Security and Data Privacy, 2026). A credential an agent holds sits in several at once.

For the example record, a session policy that allows one bucket for one hour answers the identity category. It does not answer what the agent reads in the bucket, what a console page shows, or who approved the action. Does Each Coding Agent Task Need Its Own Credential? takes the per-task grant question directly.

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 an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, such as changing a bucket policy or deleting objects. 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. If the agent works in a browser on the AWS console, an access key, an account identifier or a bucket's object names shown on a page are replaced with placeholders such as ACCT_001 before the model reads them, and the approver sees the action before it is submitted. The session policy and the adapter bound the authority and the call. The governed environment bounds what the model reads on the page, and the approver bounds what the agent is allowed to submit.

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so an agent that calls AWS from a shell is a case for short-lived credentials, a session policy and an adapter, not for a browser control.

Methodology and limitations

This page rests on AWS documentation on IAM best practices, the AssumeRole API and S3 security, Coder's documentation, three research preprints, OWASP's agentic list, a Columbia lab post, Harvard University guidance and existing RedactSure research pages. Sources were read between October 16, 2026 and October 20, 2026. Quoted facts are cited to the page that states them, with the AWS limits quoted as the API reference gives them, and the position-paper and benchmark figures are cited as reported, not as independently reproduced. Where a source supports only a premise, such as the incident list, the page says so and does not present it as proof of the design.

The AWS pages read cover AssumeRole parameters, IAM best practices and S3 security; they were not read for other STS operations such as GetSessionToken or federation, and limits for those are not stated here. RedactSure did not test AWS or any adapter hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as a session policy for one bucket, and not organizations.

Determinations about whether a credential arrangement meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. The page is a reading of public documents, dated as above, and it should be read with AWS's current documentation open. Nothing here replaces a review of the organization's own IAM roles, session policies and credential inventory.

What the record shows

The question has three separable answers. Remove long-lived keys from the agent's environment. Issue credentials that expire and carry a session policy narrower than the role that issued them. And keep even those out of the agent's process by letting an adapter make the call. AWS's own guidance points the same way: roles and temporary credentials before long-term keys, and only the permissions the task requires. The research record supports putting the control between the model and the tool, and the incident record shows what broad authority allows. None of the AWS pages reviewed describes what the model reads on a console page or who approves a consequential action. For one agent and one task, a team passes this test when it can say which credential the agent uses, how long it lasts and which policy narrows it, along with where the string sits and who approves the first change.

Frequently asked questions

How do I let a coding agent use AWS without giving it my access keys?

Do not put long-lived keys in the agent's environment. Issue short-lived credentials through the AWS Security Token Service with a session policy scoped to the task, such as one S3 bucket for one hour, and where possible let an adapter hold them and make the calls. The agent then requests operations and receives results, and a leaked string expires quickly and covers little. Approval of consequential actions by a named person stays in place, and the grant is issued per task.

Are short-lived credentials enough on their own?

They bound the damage but do not prevent exposure. A one-hour credential for one bucket, held by the agent, can be sent by a prompt injection within that hour, and the agent can still act inside the grant, which a session policy does not prevent. One emulated-sandbox study found risky failures in 23.9% of cases even for the safest agent tested. Short-lived credentials work best with an adapter and an approver, and with a log of what was requested.

How long should the agent's AWS credential last?

As short as the task allows. An AssumeRole session can run from 900 seconds up to the role's maximum of 43,200, and the default is 3600 seconds, so a one-hour grant needs no special setting. Longer sessions are a choice that should be written down against the task and approved by someone other than the agent. A shorter session limits how long a leaked string works, and a session policy limits what it can reach in that time. Neither limits what the agent does inside the grant.

Does an adapter cover the AWS console?

No. An adapter governs API calls. If the agent works in the AWS console in a browser, the model reads whatever the page shows, including account identifiers and object names, so the page needs a separate control that replaces values with placeholders before the model reads them. A governed browser environment does that, and it does not cover a terminal, an IDE or MCP, so the two controls are used together. Test the console case separately from the API case.

Why not give the agent long-term access keys?

AWS recommends temporary credentials from IAM roles over long-term access keys wherever the workload allows, and lists specific cases where keys remain acceptable, such as workloads that cannot use roles. A coding agent can usually assume a role, and the role's credentials expire without anyone remembering to rotate them. A long-term key keeps working until someone revokes it, and a leaked one has no built-in end date or narrowing policy, which is the point of the comparison.

What should a security team ask for in writing?

Ask which credential the agent uses, how long it lasts, which policy narrows it, which component holds the string and which operations the agent can request. Ask what the model reads on a console page and who approves each change, where the record is exported, and who can raise the role's maximum session duration. Ask for a dated answer from the vendor, because features and defaults change between releases.

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 Governs the Console Page the Agent Reads

A short-lived credential, a session policy and an adapter all act on the API call, and none decides what the console shows the model.

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

Before: the agent opens the S3 console, reads the account identifier, bucket name and object keys in the clear, and submits the change. Inside the governed environment: the console renders ACCT_001 and BUCKET_001, the agent drafts the change on placeholders, and the real identifiers resolve only on a named person's approval.

RedactSure is deploying now with enterprise and government customers. The emulated-sandbox study found the safest agent taking risky actions 23.9 percent of the time.

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

See it on your own workflow

Keeping keys away from the agent is only half the job when the console shows account details. Bring an S3 task your team delegates and see, with test values, what the model reads. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.