Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Can a Hijacked Coding Agent Do With My AWS Keys?

A hijacked coding agent holding an AWS key can start instances, read buckets, rewrite IAM and run up a bill, and the limit on all of it is the key's policy and its lifetime. Check both, then replace standing keys with short-lived sessions scoped to one task.

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

For the team that owns a cloud account, an access key is a standing grant: whoever holds the string can call the API until someone notices, and a coding agent redirected by a line of text in a repository, an issue or a tool output is one such holder. The damage that follows is decided by the policy attached to the key and the time left on the clock, whatever the model intended. The page follows that order, from what a broadly permitted key can reach, to how a session policy and a duration set the edge of that reach, to what the vendors document about temporary credentials, vaults and rotation, and finally to what has to hold once an injection succeeds. One record type runs through it: a key with AdministratorAccess compared with a session scoped to a single bucket. The key is also the piece an agent is most likely to be handed, because it is the shortest path to a cloud account and the least visible in a review of the agent's own configuration, and its permissions are set once and inherited by every run. The consistent finding is that the key outranks the model, and that a smaller grant with a shorter clock changes the arithmetic. A team that reads only the rotation guidance will secure the string and leave the permission attached to it untouched, which is the half that decides the incident (What Is Least Exposure?).

Key findings

  • A session's permissions are the intersection of the role's identity policy and the session policies, so a role with broad reach can be handed out narrow for one task (AWS, AssumeRole, 2026).
  • Temporary credentials can be requested for as little as 900 seconds (15 minutes) and up to the maximum session duration set for the role (AWS, AssumeRole, 2026).
  • Centralized credential management "eliminates the need to embed secrets in agent code or configuration files," which removes one copy of a key without changing what the key can do (AWS, Features, 2026).
  • An automatic rotation schedule is one documented control: "With Secrets Manager, you can configure an automatic rotation schedule for your secrets" (AWS, What, 2026).
  • A governed environment replaces a value with a consistent token before any model reads the rendered page, so a hijacked agent that pastes a key into a console form pastes KEY_001 (Can Runtime Tokenization Protect Data Without Slowdowns?).
  • Real values resolve only at the approved destination at the moment of an approved action, so the credential reaches the console action a person approved and not the transcript or the page that follows (What Is Least Exposure?).

What can a hijacked coding agent do with an AWS key?

The scope comes first, because the title says coding agent and the answer depends on where the key is used. A governed browser environment covers what an agent reads and does on a rendered page: cloud consoles, dashboards, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A key exported into a shell and used with the CLI sits outside a browser control, and the IAM policy on that key is the control that applies. An agent that opens the console and works through the pages is inside it, including the page that displays a newly created key.

With a key that carries AdministratorAccess, four lines of damage open at once. Compute starts: instances, clusters and functions in any region the account can use. Storage opens: every bucket the account can list and get. Identity changes: new users, roles and policies, which is how an intruder keeps access after the key is revoked. And spend accrues, billed to the account until someone stops it. The record for this page sets that key beside a session scoped to a single bucket.

What the key allows AdministratorAccess key One-bucket session
Start compute Any instance type, region and count the account can use Denied by the session policy
Read storage Every bucket the account can list and get One bucket, listed actions only
Change identity Create users, roles and policies Denied
Spend Billed to the account until stopped Bounded by the work on one bucket
Time window Until the key is rotated or deleted 900 seconds up to the role maximum
Record A call attributed to the key A call attributed to the session

The distinction that matters is between authority and capability. A coding agent handed a key does not gain a new skill; it gains reach, and the reach is written in the policy. As What Is a Tethered Agent? puts it, the tether is a description of authority, not of capability. Nothing in the prompt that hijacked the agent changes that list.

How does the key's policy bound the blast radius?

The policy is the first bound, and it operates at two levels: the identity policy on the role and a session policy passed when the credential is issued. The service returns "a set of temporary security credentials that you can use to access AWS resources," and the session policy narrows what those credentials can do (AWS, AssumeRole, 2026).

A standing access key has only the first. It is not a session, so there is no session policy and no expiry; it is bounded by its identity policy alone and it works until someone deletes it. The AdministratorAccess key has an identity policy that allows every action on every resource, and no clock at all.

The duration is set at issue as well, bounded above by the role's maximum session duration. A team that raises that maximum for a long batch job has raised the ceiling for every session the role issues.

Amazon's guidance strongly recommends against creating access keys for the root user, which rules out the simplest durable top-level credential an agent might be handed (Is It Safe to Let an AI Agent Set Up Your Cloud Environment?). The same rule appears for administrative accounts: Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? records guidance that the super admin account should be used only when needed.

What a session policy should name is the task: one bucket, a list of actions, nothing else.

What do the vendors themselves say?

The vendor pages reviewed describe how a credential is issued, stored and retrieved. They differ in what each mechanism is for. What a model reads on the console page where a key is created or displayed is not described in the pages reviewed, and that is the gap the last section returns to.

The AssumeRole reference fixes the life of a role session. Role chaining limits a role session to "a maximum of one hour," which bounds how long a credential taken from a hijacked run stays usable (AWS, AssumeRole, 2026). The range for a single session runs from 900 seconds to the role's maximum, and that interval is the choice a team makes when it issues a credential for a task.

The AgentCore Identity pages describe the pattern for agents that call services. The token vault is built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets," and the agent retrieves them with its own workload token, which keeps the credential out of the code and leaves the credential's permissions where they were (Douglas III and Abrom, 2025).

A managed identity "doesn't require any secrets and is automatically authenticated based on the environment where the code runs," a design for a workload rather than for a key pasted into a coding agent (Microsoft, 2026).

The Secrets Manager page describes rotation and retrieval. The same page says you "replace hard-coded credentials with a runtime call to the Secrets Manager service," which hands the value to whatever process makes the call (AWS, What, 2026).

Dimension AWS, per its documentation What a buyer should verify
Credential type A role session returns temporary credentials Whether the agent holds a string or asks a service for one
Scope The intersection of the role policy and the session policy The exact actions and the one bucket the task needs
Lifetime 900 seconds up to the role maximum; one hour when chained The role's maximum, not only the requested duration
Where the value lives A token vault or a runtime call from a credential store Whether the calling process can print the value
Record Logs that separate an agent's action from a person's Whether the account records the session and the approval

How much does the key's lifetime change the outcome?

A key's life is the second bound, and it is the one teams forget because a key does not announce its age. A standing key is valid until it is deleted, so the useful question is when someone last looked at the key inventory.

The alternative is a session with an expiry fixed at issue. The documented floor is 900 seconds and the ceiling is the role's maximum, so the range covers most tasks and the choice belongs to the team that issues the credential. A session that expires in fifteen minutes turns a leak into a bounded exposure. A key that lives for a year turns the same leak into a standing liability.

Two credentials with the same policy differ by the window: fifteen minutes of work against a year of waiting. The window also decides how much of the incident a log review can recover.

Rotation and revocation are the controls for the standing key. Rotation replaces the value on a schedule, and a key used between rotations is still valid. Revocation is the emergency control, and guidance for AI systems asks teams to be able to act on it: two of the seven risk categories in university guidance for AI systems are Privilege and Identity Misuse and Governance and Visibility, and a stolen key moves between them (Harvard University Information Security and Data Privacy, 2026).

None of this depends on the model. A model upgrade raises the question in Can AI Models Change Without Changing Their Controls? and leaves the key's policy where it was: the new model inherits the same grant, and the ceiling stays where the role put it.

What still has to hold after the injection succeeds?

Detection is worth having and it is not the answer to the title. A guardrail system for agents reports that its injection detector "shows stronger efficacy at preventing indirect injections in general scenarios than previously proposed approaches," which is progress on detection and not a bound on what a key can reach (Chennabasappa et al., 2025).

The research that bears on blast radius is about privilege. A measured study of browsing agents reports "prompt injection, domain validation bypass, and credential exfiltration," the combination that turns a hijacked run into a stolen key (Mudryi et al., 2025). The defense the same literature measures is narrower authority: "Progent significantly reduces attack success rates while maintaining high utility" (Shi et al., 2026).

Two properties have to hold after the injection lands. The first is attribution: an audit log that attributes "every action unambiguously to either an agent or a human actor" is what turns a key's use into an account of who spent it (AWS, AGENTSEC03-BP02, 2026). The second is the ability to stop the work, which is a property of the owner and not of the model.

The route in is a separate question, examined in How Does Prompt Injection Get Into a Coding Agent?. What matters here is that the route does not change the key: an injection that arrives through a README, an issue comment or a tool output ends at the same policy, and the same policy decides the damage.

What does a governed environment change?

A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works with placeholders such as KEY_001 and ACCT_001 instead of the strings behind them. 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.

The change is in what the model reads: a console page that displays a newly created access key renders the key as a token. It does not change the key's policy, which is still the bound on what the credential can do, and it does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a key exported to a shell remains a matter of IAM.

Tokenization at runtime adds one bounded operation to the reading path, a mapping between a value and a surrogate whose cost profile is that of a lookup (Can Runtime Tokenization Protect Data Without Slowdowns?). A narrower key policy deserves a staged rollout too: the data loss prevention pattern of testing a policy in simulation mode before it blocks anything applies, as How to Enforce Data Security Without Disrupting Work? describes.

What the class does not do is make a bad grant safe. A key with AdministratorAccess rendered as tokens still authorizes compute, storage and identity changes. The gain is that the model never holds the string and the record shows what it saw.

Methodology and limitations

This page rests on the AWS Security Token Service and Secrets Manager reference pages, the AgentCore Identity developer guide and security blog, Microsoft's managed identity documentation, the Well-Architected agentic lens, Harvard's guidance for generative AI systems, three research preprints on injection, guardrails and privilege control, and existing RedactSure research pages. Vendor pages were read between October 16, 2026 and October 20, 2026, and each Sources line carries the date for its page. Quoted sentences are cited to the page that states them; figures are reported as the cited page gives them and not as independently measured.

RedactSure did not test any product hands-on. The record of a key with AdministratorAccess compared with a one-bucket session is an illustration of a record type, not an account of an organization, and its permission list describes what such a policy allows rather than a measured incident. Where a behavior is not described in the pages reviewed, the page says so and does not infer the behavior from silence. Vendor features change and the page carries its date, so a release after that date should be treated as unreviewed until the checks are repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers.

Determinations about whether a credential policy, a logging setup or an approval flow meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test on the organization's own account with a key scoped to a test bucket, repeated after each release.

What the record shows

The two keys in the record do the same thing with different edges. An AdministratorAccess key authorizes compute, every bucket and identity change, and it does so until someone deletes it. A one-bucket session authorizes a list of actions on one bucket and stops at an expiry the team chose. The difference lies in the policy and the clock, which are set before the run begins, while the model simply inherits whatever grant it is given. A governed environment adds a third property that neither key has: the model reads tokens on the console page rather than the credential, and a named person approves the action that resolves them, which RedactSure's design supplies. Comparing those edges on real work is the test that counts: name one agent and one task, write the policy the task actually needs, set the shortest session the task tolerates, and ask what the model would have read if that console page had been shown to it.

Frequently asked questions

What can a hijacked coding agent do with my AWS keys?

A key authorizes API calls, so the agent can do whatever the key's policy allows: start compute, read buckets, change users, roles and policies, and run up spend until someone stops it. The prompt does not widen that list and the model does not shrink it. A key with AdministratorAccess allows all of it, and a session policy scoped to one bucket allows the work on that bucket. Read the policy first, then the expiry, and write down which of the two you changed.

How quickly can I tell that a key was used?

Only as quickly as the account records calls. The guidance reviewed here asks for logs that attribute an action to an agent or a human actor, which is what makes a session traceable to the run that used it. A standing key shared by several processes is harder to attribute than a session issued for one task. Put an alert on the calls an agent should never make, and check the key inventory on a schedule you can keep, with the name of the person who owns it.

Does a short session make the incident harmless?

No. It shortens the window and narrows the authority, and inside that window the agent can still act. A one-hour session on one bucket can delete every object in the bucket, and the expiry only stops the next hour. What the session buys is a bound: the loss is what the policy allows while it lasts. Pair it with the smallest policy the task can use, review the action rather than only the credential, and keep that review with the run's record.

Is a secrets manager enough?

It keeps the string out of code and rotates it on a schedule, which are real gains. It does not change what the key can do, and a process that retrieves the credential holds the value for as long as it runs. The pages reviewed say a role that retrieves a credential hands the value to whatever process calls it, and they do not discuss coding agents. Treat a secrets manager as custody, not as scope, and check the policy that the retrieved credential carries.

What does AdministratorAccess add?

Everything the account can do, including identity changes. An agent that can create users, roles and policies can arrange to keep access after the original key is deleted, which turns a temporary incident into a longer one. The permission also makes the key attractive to anyone reading a transcript or a log. If a task needs one bucket, the policy should name one bucket, and the administrative key should stay out of the agent's environment and out of its transcript.

What should I ask for in writing before an agent gets a key?

The policy the key will carry, the maximum session duration on the role, who can revoke it and how fast, what the account records about its use, and whether the agent holds the string at all. Ask which console pages the agent will read, because a page that displays a key is part of the exposure. A vendor that answers with rotation alone has answered half the question, and the other half is what the policy allows. Ask for those answers in writing, with a date.

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 a Live Key Out of the Model's Hands

A session policy, an expiry and a vault each bound what a cloud key can do, but none bounds what the model reads on the console page.

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

Before: the agent opens the IAM console with the administrator key, reads the new key, and attaches AdministratorAccess. Inside it: the same page renders BUCKET_001 and KEY_001, the policy editor shows the single-bucket statement, and the key is released only to the deployment target a named person approved.

RedactSure is deploying now with enterprise and government customers. AWS documentation sets a 900-second floor and a one-hour cap on chained role sessions.

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

See it on your own workflow

An administrator key in a hijacked agent's context is a full account compromise. Bring an IAM task and see, with test values, what the model reads and what the policy editor shows. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.