Data Report · By Chris Sowa · Published
Last updated
How Do I Let a Coding Agent Create Cloud Resources Without Admin Keys?
Grant the adapter, not the agent, a role limited to the resource types and region the task needs, and require approval for anything that costs money or opens a port. The agent describes the resource and the adapter creates it under the grant, so check who holds the role.

Admin keys are convenient because they never refuse a request, and that is the problem when an agent holds them. A task that needs one virtual machine does not need the ability to delete a database or change who can log in. Cloud platforms offer ways to issue narrow, short grants, and the harder step is deciding what the grant should say. Creating cloud resources is the point at which an agent's work turns into a bill and an attack surface: an instance runs and costs money, a port opens and the network changes. Admin keys make every one of those actions available at once, which is why they are the wrong thing to hand over. This page uses one record type as its example, an EC2 instance created under a one-run grant. It tests that design against the vendor documentation and the research record, and it separates what a grant limits from what an approval decides. The finding is that a narrow grant limits what the agent can create, while the cost and the network changes it causes still need a named person who answers for them. What Is Least Exposure? supplies the framing.
Key findings
- The role the task needs is narrower than the role an administrator holds. Design research proposes "principled design patterns for building AI agents with provable resistance to prompt injection" (Beurer-Kellner et al., 2025).
- AWS's AgentCore documentation says the credential provider "stores the resulting credentials in the token vault, and provides the agent with the necessary access tokens," so in that design the agent still receives a usable access token (AWS, Configure, 2026).
- AWS's Well-Architected guidance says "audit logs attribute every action unambiguously to either an agent or a human actor," which a shared admin key cannot satisfy (AWS, AGENTSEC03-BP02, 2026).
- Injected instructions can pull an agent away from its task; researchers define the deviation as "task drift," which is why a grant scoped to the task matters even when the agent is not hostile (Abdelnabi et al., 2025).
- A governed environment that replaces values with consistent tokens before any model reads the screen means a cloud console page shows placeholders where account identifiers and keys would be (What Is Least Exposure?).
- Real values resolve only at the approved destination, and a named person approves anything that costs money or opens a port, so the irreversible steps stop for a human (How to Use AI Agents to Launch an EC2 GPU Instance).
What does it mean to let an adapter hold the role instead of the agent?
In the usual setup the agent holds credentials and calls the cloud API itself. With admin keys, anything the API allows is available: instances, networks, storage, identity. The alternative separates description from action. The agent describes the resource it wants, such as an instance of a given type in a given region. An adapter that holds a role limited to those resource types and that region creates it and returns the identifier.
The record type is an EC2 instance created under a one-run grant. The grant names the resource type, the region and the run. When the run ends, the grant ends. The agent receives an instance identifier and a status and never a key. AWS's own IAM and STS documentation on roles and session policies was not among the pages reviewed, so the mechanics of scoping are described at the level of the page's hypothesis and should be checked against AWS's current documentation.
Scope note: the controls discussed concern what an agent holds and what an adapter does for it. A governed browser environment, discussed at the end, covers what an agent reads and does on a rendered page such as a cloud console. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. Is It Safe to Let a Coding Agent Create Cloud Resources? takes the safety question for the same task, and Is It Safe to Let an AI Agent Set Up Your Cloud Environment? covers the root user, where AWS strongly recommends not creating access keys.
What do the vendors themselves say?
AWS's Bedrock AgentCore documentation describes a credential provider that "stores the resulting credentials in the token vault, and provides the agent with the necessary access tokens" (AWS, Configure, 2026). The vault removes the credential from code and configuration, and the agent still receives a usable access token. That is custody at rest. What the model reads on a rendered page is not described in the pages reviewed.
AWS's AgentCore Identity documentation, as summarized in existing research, says centralized credential management eliminates the need to embed credentials in agent code or configuration files (Does AWS Bedrock Keep Company Credentials Away From Agents?, 2026). That governs where a credential is stored and does not describe an approver for resource creation.
AWS's Well-Architected guidance for agents requires that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, AGENTSEC03-BP02, 2026). HashiCorp publishes a tutorial titled "Secure agent permissions with Vault" (HashiCorp, 2026), cited here only for what its title plainly covers.
| Source | What it documents | What the pages reviewed do not describe |
|---|---|---|
| AWS AgentCore credential provider | Credentials held in a token vault; agent receives access tokens | An approver; what the model reads on a page |
| AWS AgentCore Identity (via linked research) | No credentials embedded in code or configuration | Approval of resource creation |
| AWS Well-Architected | Attribution of every action to an agent or a person | Role scoping for a specific task |
What should the grant contain?
Three things: the resource types, the region and the lifetime. A grant for an EC2 instance names EC2 and not storage, networking or identity services. It names one region, not all. And it ends with the run. The point of the grant is that the adapter cannot do what the task did not need, whatever the agent asks.
| Grant element | Example for the record type | What it prevents |
|---|---|---|
| Resource types | EC2 instance, one type family | Creating storage, networks or identity objects |
| Region | One region | Spreading resources across regions unnoticed |
| Lifetime | One run | A standing credential that outlives the task |
| Approval | Anything that costs money or opens a port | Cost and exposure the agent chose alone |
OWASP's agentic list names the categories at stake, including ASI02 Tool Misuse and ASI03 Identity & Privilege Abuse (OWASP GenAI Security Project, 2025). A grant limited to the task answers the second directly and narrows the first. Design research proposes "principled design patterns for building AI agents with provable resistance to prompt injection" (Beurer-Kellner et al., 2025), and one preprint describes a defense "operating at the agent-tool interface" that reported strong benchmark results, while its title asks whether stronger benchmarks are needed (Bhagwatkar et al., 2026). Both are design arguments and benchmark results, not deployment guarantees.
What does approval cover that a grant cannot?
A grant limits what the adapter may do. It cannot decide whether a permitted action should happen now. An instance is within the grant and still costs money. A security group rule is within the grant and still opens a port. The hypothesis for this page puts approval on exactly those two: anything that costs money or opens a port. A named person approves the request before the adapter acts.
Existing research on launching a GPU instance with an agent makes the same cut: five of the steps commit the account to something that cannot be taken back, and those five stop for a person (How to Use AI Agents to Launch an EC2 GPU Instance). The approval is attached to the action. It is not attached to the agent's summary of the action.
Task drift is the other reason. Researchers define the deviation from a user's original task under injected instructions as "task drift" (Abdelnabi et al., 2025). A grant scoped to the task bounds what a drifting agent can ask for, and an approver sees what it did ask for. Can a Coding Agent Read My AWS Credentials File? covers the file path to the same credentials, and How Do You Let an AI Agent Manage API Keys Without Reading Them? covers key handling.
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 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 the incidents involved broad authority and not a particular key type.
Harvard's security office lists seven risk categories for AI-enabled systems, including Privilege and Identity Misuse and Governance and Visibility (Harvard University Information Security and Data Privacy, 2026). Admin keys in an agent's reach sit in both. A role scoped to the task answers the first, and a record of who approved each cost or port answers the second.
Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? makes the parallel point for SaaS administration, where the super admin account should be used only when needed, a rule written for people that applies with more force to an agent. Does Cursor Read My .env File? takes one vendor's version.
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 creating a resource that costs money. 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 cloud console, an account identifier, a key or a network address shown on a page is replaced with a placeholder before the model reads it, and the approver sees the create request before it is submitted. The adapter and the scoped role bound the authority and the call. The governed environment bounds what the model reads on the pages it works. OWASP names the failure class as excessive agency, the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, with excessive functionality, permissions and autonomy as its listed root causes (OWASP, LLM06:2025, 2025).
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 creates resources from a shell is a case for the adapter and the scoped role.
Methodology and limitations
This page rests on AWS documentation for Bedrock AgentCore and Well-Architected guidance, a HashiCorp tutorial title, OWASP guidance, three research preprints, 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, and the position-paper figures are cited as reported, not as independently measured. The page is a reading of public documents and should be read with AWS's current documentation open. Where a source supports only a premise, such as the incident list, the page says so.
AWS's own documentation on IAM roles, STS temporary credentials and session policies was not among the pages reviewed, so the mechanics of scoping a role are described at the level of the page's hypothesis and are not quoted. The grant table is a design, not a description of any product. RedactSure did not test AWS, AgentCore 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 as set out in its Developer Workspace one-pager, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as an EC2 instance created under a one-run grant, and not organizations.
Determinations about whether a cloud-access 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 IAM roles, cost controls and network policy.
What the record shows
The question has a consistent answer in the sources. Do not give the agent admin keys. Give an adapter a role limited to the resource types and region the task needs, and have the agent describe the resource. Put a named person on anything that costs money or opens a port. AWS's own agent guidance moves credentials into a vault and asks for attribution of every action, and in the AgentCore design the agent still receives an access token, which is why the adapter form goes one step further. None of the sources describes what the model reads on a console page. Before anything is created, a reviewer should be able to pass a simple test: name one agent and one resource, the role the creating call runs under and who holds it, and the person who approves the cost and the port.
Frequently asked questions
How do I let a coding agent create cloud resources without admin keys?
Give an adapter, not the agent, a role limited to the resource types and region the task needs, with a lifetime of one run. The agent describes the resource and the adapter creates it under the grant, returning an identifier. Anything that costs money or opens a port waits for a named person. The agent never holds a key, and the role cannot do what the task did not need, whatever the agent asks for or is told to ask for.
What is wrong with giving the agent a vault-issued access token to use?
A vault removes the credential from code and configuration, which is a real gain. In AWS's AgentCore design the credential provider still provides the agent with the necessary access tokens, so the agent holds something usable. A prompt injection can send it. An adapter that makes the call keeps the usable credential out of the agent's process, and the agent receives only results, which is the further step the hypothesis describes and the one that leaves a prompt injection nothing to send.
What should the grant name?
The resource types, the region and the lifetime. For an EC2 instance that means EC2 and not storage, networking or identity, one region and one run. The grant is the limit on what the adapter will do whatever the agent asks, and it should be written down before the run. It does not decide whether an action should happen now, which is why cost and exposure changes need a separate approval from a named person, recorded against the action.
Why approve cost and open ports separately from the grant itself?
Because they are within the grant and still consequential, and a grant alone cannot judge timing. An instance costs money and a security group rule changes who can reach it, and the agent's request for either can be wrong or injected, which is why a person reads it first. A named person reads the request before the adapter acts, and the approval is recorded against the action, not against the agent's description of it, so a later review can see who decided and what they were shown.
Does the adapter cover the cloud console?
No. An adapter governs API calls. If the agent works the cloud console in a browser, the model reads whatever the pages show, so the pages need 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, and each is tested on its own surface before an agent is trusted with either.
What should a security team ask for in writing?
Ask in writing which role the creating call runs under, who holds it, what its resource types, region and lifetime are, and who approves cost and port changes. Ask what the model reads on any console page and where the record is exported. Treat anything the vendor does not document as unanswered, and do not assume a default is safe, and ask for a dated answer from the vendor, naming the account, the role and the approver.
How RedactSure Puts a Named Approver in Front of Every Cost and Port
A scoped role bounds what the adapter may do, yet it does not decide whether a permitted instance should launch, and no page reviewed covers the console.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the EC2 console, reads the account identifier and any key shown, and launches alone. Inside the governed environment: the model reads ACCT_001 on every page, the launch stops for the named person, and the instance is created on that approval, which the record holds.
RedactSure is deploying now with enterprise and government customers. AWS's AgentCore documentation says the credential provider still "provides the agent with the necessary access tokens."
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A cloud launch made without a person can become a bill or an open port before anyone looks. Bring an infrastructure task your team delegates and see, with test values, the launch wait for a named person. Book a demo







