Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Is It Safe to Let a Coding Agent Create Cloud Resources?

Yes, when the agent works from a scoped, short-lived grant and a named person approves the cost and exposure of each resource before creation. The resource is the easy part and the credential that created it is the hard part, so keep the creation in an adapter outside the agent and the agent in the description.

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

A coding agent that can create a GPU instance, a bucket or a database can also create the bill, the open port and the orphaned credential that come with it. The answer to the title question is a conditional one: the agent may describe what it needs and, under a grant limited to one task and a short window, cause the resource to exist, provided a person with a name has approved what it will cost and what it will expose before anything is created. The resource is rarely the hard part, since a wrongly sized instance is deleted in a minute. The credential that created it is a different matter, because whatever can create one resource can usually create another, and a credential the agent holds is a credential an injected instruction can use. This page separates the two parts: the request, which belongs in the agent's description of what it wants, and the creation call, which belongs in an adapter outside the agent's process that holds the grant. It works through one record, a GPU instance request approved and created, and reads what AWS, Microsoft, HashiCorp and Anthropic document about temporary credentials, managed identities and delegated tokens, alongside research on agent privilege control and prompt injection in coding tools. Is It Safe to Let an AI Agent Set Up Your Cloud Environment? covers the wider account setup; this page takes the act of creation.

Key findings

  • AWS documents AssumeRole as returning "a set of temporary security credentials," with a session's permissions being "the intersection of the role's identity-based policy and the session policies" and a duration that "can range from 900 seconds (15 minutes)" upward (AWS, 2026).
  • HashiCorp's Vault tutorial on agent permissions states that "token lifetime is reduced from days or weeks to minutes," while its wrapper script exports the token as VAULT_TOKEN and launches the agent, so the agent process holds the raw value (HashiCorp, Secure, 2026).
  • Anthropic's Claude Code security documentation states that for cloud sessions "GitHub credentials are stored encrypted on Anthropic's servers and never enter the session VM" (Anthropic, 2026).
  • Prompt injection against agentic coding editors reached attack success rates "as high as 84% for executing malicious commands" in one study, which is why the credential, not the resource, is the asset to protect (Liu et al., 2026).
  • A governed environment that replaces values with consistent tokens before any model reads the screen means an agent working a cloud console never holds the account identifier or any key the console displays. Real values resolve only at the approved destination, at the moment of an approved action, and a named person answers for that action (What Is Supervised Delegation?).
  • The steps in a GPU launch that commit the account to something it cannot take back are where the approval belongs, and the existing walkthrough of that launch stops at those steps (How to Use AI Agents to Launch an EC2 GPU Instance).

What does letting an agent create a cloud resource involve?

Three things, worth keeping apart. The request: a GPU instance request record holds an instance type, a region, a machine image, an attached volume, a set of inbound rules, a key pair, tags and an hourly rate. The grant: the credential under which the creation call is made, with its permissions and lifetime. The creation call: the API request or console action that turns the record into a running instance with a public address and a role attached. An agent can be good at the request and should be kept away from the grant and the call. How Do I Let a Coding Agent Create Cloud Resources Without Admin Keys? describes the mechanics; this page asks whether the arrangement is safe and what the approval must cover.

Scope matters because the two places an agent can act are governed by different controls. A governed browser environment covers what the agent reads and does on a rendered page: the console, the pricing page, the quota page, the instance detail page and the sign-up form for a new service. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. A CLI command or SDK call from the agent's shell is outside a browser control and is governed by whatever credential the shell holds.

The instance the agent creates may itself carry a role, and the MCP security guidance notes that "cloud metadata endpoints often expose IAM credentials, API keys, and other secrets" (Model Context Protocol, 2026). A resource created with a role attached is a new place a credential can be read from, so the attached role is one of the fields a person approves.

What do the vendors themselves say?

AWS documents AssumeRole as the way to obtain temporary credentials: 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, 2026).

Microsoft documents managed identities as the way to hold no credential: token acquisition "doesn't require any secrets and is automatically authenticated based on the environment where the code runs" (Microsoft, 2026).

HashiCorp documents response wrapping, under which "a new single-use token is generated with the TTL supplied by the client" (HashiCorp, Response, 2026). Anthropic's security page states that "the boundary is a permission prompt, so a Bash command you approve can still write anywhere your user account can" (Anthropic, 2026). An approver for a creation call and a record of what the model read are not described in the pages reviewed.

Source What it documents What a buyer should verify
AWS AssumeRole Temporary credentials; intersection of role and session policies; 15 minute minimum; one hour cap under chaining The role's maximum duration
Microsoft managed identities No credential; token from the environment What the resource may do
HashiCorp response wrapping Single-use token with a client-supplied TTL The TTL in use and who unwraps
Claude Code security Approval as the boundary; session-scoped cloud credential Which credentials the local shell holds

Why is the credential harder than the resource?

Because a resource is a thing and a credential is a capability. A GPU instance has one price, one address and one set of ports, which a person can judge. A credential that can create one instance can usually create many and read what already exists. HashiCorp's tutorial shows how narrow a grant can be made: the agent "receives a token that is read-only, repo-only, scoped to a single secret, and short-lived" (HashiCorp, Secure, 2026). Its wrapper script "obtains a short-lived delegated RAR token, exports it as VAULT_TOKEN, and launches the agent," so the agent process holds the raw token, and the page does not say whether the agent can read it.

That is the argument of this page. A narrow, short token is a large improvement over a standing administrator key, and it is still a value in the agent's environment. Anthropic's cloud sessions take the other route: the VM "holds a short-lived credential scoped to that session" and the GitHub credential never enters it (Anthropic, 2026). The difference is where the raw value sits: inside the process the model drives or outside it. Can a Coding Agent Use a Credential It Cannot Read? takes that question, and How Do I Give a Coding Agent a Short-Lived Credential? covers lifetime.

The MCP specification adds a scoping rule that transfers: servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server," and "poor scope design increases token compromise impact, elevates user friction, and obscures audit trails" (Model Context Protocol, 2026). A grant issued for one request and usable by one adapter is the resource version of that rule.

What should the approval cover before the instance exists?

Cost and exposure, read off the request record by a person whose name is attached to the approval. For the GPU instance request that means the hourly rate and expected hours, the region, the instance type, every inbound rule open to the internet, whether a public address is assigned, and which role is attached. Deleting the instance does not undo a bill already run, a port already scanned or a role already read. The walkthrough in How to Use AI Agents to Launch an EC2 GPU Instance stops at exactly those steps.

Field on the request Why a person approves it What the grant should limit
Instance type and hourly rate The cost begins at creation and runs until deletion Instance families and a spend ceiling
Region Residency and quota One region
Inbound rules and public address Exposure begins at creation No rule open to all addresses
Attached role A new place a credential can be read No role, or one limited to the job's own data
Lifetime The grant should expire before the instance is forgotten Minutes, not days

Research on privilege control supports restricting the grant over trusting the model. Progent, a framework for privilege control in agents, "significantly reduces attack success rates while maintaining high utility" on its benchmarks (Shi et al., 2026). The abstract reports no figures, so the reading is directional: a narrower grant costs little in task completion. The organization also has to be able to name the person who approved this instance, and What Is Supervised Delegation? notes that most enterprise agent deployments cannot name the person accountable for a given agent action, which becomes an audit finding after any incident.

What happens if the agent is hijacked during the task?

Assume it will be, and ask what the attacker collects. Injection against agentic coding editors achieved attack success rates "as high as 84% for executing malicious commands" in one study (Liu et al., 2026), and research on browsing agents reports "prompt injection, domain validation bypass, and credential exfiltration" and demonstrates "how untrusted web content can hijack agent behavior" (Mudryi et al., 2025). Anthropic's own position is that "while these protections significantly reduce risk, no system is completely immune to all attacks" (Anthropic, 2026).

What the hijacked agent collects depends on where the credential sits. With a creation grant in its environment, the attacker can create resources within the grant's permissions and lifetime, mining instances billed to the account being the usual case. With the raw value in an adapter and only a description in the agent, the attacker can make the agent describe a resource, and the description still goes to a person. Can a Credential Vault Protect What an AI Agent Reads? covers how the 2026 platforms converged on placeholders substituted at the destination.

There is also the quieter failure, in which the agent writes the credential somewhere. GitGuardian's test of a code assistant reported that it "generates 2702/900 = 3.0 valid secrets for one prompt on average" (GitGuardian, 2025). A creation grant pasted into a setup script is the same leak with a larger reach. How Do You Let an AI Agent Manage API Keys Without Reading Them? gives the leak figures for agent co-authored commits.

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 an agent reading the cloud console sees ACCT_001 for the account identifier, KEY_001 for an access key shown on a credentials page and the same placeholders on every page where those values recur. 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, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this page's question it changes two things. The agent working the console to size and price the GPU instance never holds the account's identifiers or any key the console displays, so a hijacked run collects tokens. And the creation itself, when it happens through the console, is a consequential action that waits for a named person who sees the cost and the exposure on the request before it exists. The record then answers the question an auditor asks after the instance is found: what did the model see on each page, who approved the creation, and what the approval covered (What Is an AI Control Record?).

Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a creation call made from the agent's shell with a credential in its environment is outside it. That path is closed by the grant design in the sections above: a scoped, short-lived credential held by an adapter and not by the agent, with the approval between the description and the call.

Methodology and limitations

This page rests on vendor documentation from AWS, Microsoft, HashiCorp and Anthropic, the Model Context Protocol security guidance, three research preprints on agent privilege control, prompt injection in coding editors and browsing agent security, one vendor research post from GitGuardian, and existing RedactSure research pages. Sources were read between October 20, 2026 and October 21, 2026. Quoted facts are cited to the page that states them, and the preprints are cited for the findings stated in their abstracts, which give no trial counts, tool versions or success rates beyond those quoted.

RedactSure did not test any of the tools hands-on. "Not described in the pages reviewed" means the pages reviewed and nothing broader. The tables summarize documentation as read and are not a configuration guide; the approval table is a design recommendation, not a vendor statement. Vendor features change, and the page carries its date. The HashiCorp tutorial states token lifetimes in minutes and gives no figure, so none is stated here. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, a GPU instance request approved and created, and not organizations.

Determinations about whether a grant design meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's security and compliance officers. Nothing here replaces a test of the organization's own agent against its own account, with the grant it intends to use and a dummy resource, repeated after each release or role change. The date on this page marks when the documents were read; a later release is unreviewed until the test is repeated.

What the record shows

The documentation gives a direct answer with a condition. Temporary credentials with an intersection of policies and a lifetime measured in minutes exist on every major platform, and a vendor tutorial shows a token narrowed to one credential and one repository. The research record shows why that narrowing matters: injection against coding agents succeeds often enough that the credential, not the resource, has to be the thing protected. The pages reviewed describe the grant and the lifetime; none of them describes who approved a creation or what the model read while deciding what to create. A team can run this test with one agent and one GPU instance request: write down which process will hold the creation credential and for how long, then ask the agent to create the instance while a person reads the cost and the inbound rules before approving. If the credential is in the agent's environment, the design has the hard part left.

Frequently asked questions

Is it safe to let a coding agent create cloud resources?

Yes, under two conditions. The agent works from a grant limited to one task and a short window, held outside its own process, and a named person approves the cost and the exposure of each resource on the request record before anything is created. Without the second condition the agent can run up a bill or open a port; without the first a hijacked agent can create whatever the grant allows. Both conditions are cheap next to one orphaned GPU instance with a public address.

Why is the credential harder to protect than the resource?

A resource has one price, one address and one set of ports, and a person can read all of them off the request and delete the instance if the judgment was wrong. A credential is a capability: whatever created one instance can usually create many and read what already exists. AWS and HashiCorp both document ways to narrow and shorten it, and the remaining question is whether the raw value sits inside the agent's process or in an adapter the agent cannot read.

What should the approver look at before saying yes?

The hourly rate and the expected hours, the region, the instance type and volume size, every inbound rule and whether a public address is assigned, and the role attached to the instance. Those fields commit the account to a cost or an exposure the moment the resource exists. The approver should also see the grant's lifetime, since a grant that outlives the task is the next thing an attacker reaches for after the instance is deleted.

Does a short-lived token solve the problem?

It narrows it. A token scoped to one credential and expiring in minutes limits what a hijacked agent can do and for how long, which HashiCorp's tutorial shows in detail. It does not change where the token sits, and the same tutorial exports it into the agent's environment. The stronger design keeps the raw value in an adapter outside the agent and gives the agent only the request to describe, so expiry becomes the second line rather than the only one.

Can a managed identity remove the credential entirely?

For code running on a managed resource, Microsoft documents that token acquisition needs no credential and is authenticated by the environment the code runs in. That removes the stored value, and it makes the resource the identity, so an agent process on that resource inherits what the resource may do. Treat the attached role as the credential: approve it on the request, keep it narrow, and remember that a created instance with a role is a new place a token can be read from.

What does a governed browser environment add for this question?

It governs what the agent reads and does on the console, the pricing page and the instance detail page, replacing account identifiers and displayed keys with consistent tokens before the model reads them, and holding each creation for a named approver who sees the cost and the exposure. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a creation call from the agent's shell still needs the adapter and the scoped grant described above.

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 Puts a Named Approver Before the Instance Exists

Shortened grants still leave a Vault token in the agent's process and account identifiers on the console page, and none names who approves cost and exposure before creation.

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

Before: the agent sizes the GPU instance in the console with the account identifier in context, and a hijacked run launches whatever the session allows. Inside the governed environment: the console renders ACCT_001 and KEY_001, the agent prepares the request on placeholders, and the launch waits for a named person to approve the hourly rate, inbound rules and attached role.

RedactSure is deploying now with enterprise and government customers. Anthropic states that no system is completely immune to attacks.

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

See it on your own workflow

A cloud resource should have a named approver before it exists, not after the bill arrives. Bring an infrastructure task and see, with test values, what the approver reviews before the launch. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.