Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can I Run a Coding Agent in My Own Cloud Account Without Giving It My Keys?

Yes, if the instance role is scoped to one task and the agent receives the credential through an adapter rather than reading it from the instance metadata endpoint. Ask which route the credential takes, and what the model receives on the console pages the agent renders.

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

The cloud account was meant to make this easy. The agent runs on a machine the team already pays for, inside its network boundary, under an identity the platform issues instead of a key someone pastes into a file. That identity is also the difficulty. A role attached to an instance is available to the workload, which is what makes it useful, and the same availability makes it ambient: nothing has to hand the credential over, because the credential is within reach of whatever runs on the machine. The title's question therefore has two halves. One is the scope of the role, which the platform documents and a team can narrow. The other is the route by which the agent receives what the role can obtain, which decides whether the model ever holds the key. This page takes them in that order, then reads what AWS and Microsoft document about temporary credentials, managed identities and credential services, and what the research record says about credentials that reach model-facing text. The worked record throughout is one agent in one cloud account that curls the metadata endpoint for the role's credentials and then opens the console's role page.

Key findings

  • AWS documents that AssumeRole "Returns a set of temporary security credentials that you can use to access AWS resources," a credential the platform issues to a workload rather than a stored key (AWS, AssumeRole, 2026).
  • Microsoft's managed identity documentation states that "Managed identities eliminate the need for developers to manage these credentials," which removes the stored key and leaves the workload's reach to be governed elsewhere (Microsoft, 2026).
  • The Model Context Protocol's security guidance warns that "Cloud metadata endpoints often expose IAM credentials, API keys, and other secrets," which is why a role on an instance is ambient before any adapter is involved (Model Context Protocol, 2026).
  • A study of neural code completion tools found that "two valid credentials were identified during our experiments" and that the tools can "return the precise piece of their training data" (Huang et al., Your, 2024).
  • A governed environment replaces credential values with consistent tokens before any model reads a rendered screen, so the model works with CRED_001 where the key sits (What Is Least Exposure?).
  • Real values resolve only at the approved destination when a named person approves the action, so the console page can be read without the key entering the transcript (What Is a Tethered Agent?).

What does a governed browser environment cover when the agent runs in my cloud account?

The scope comes first, because the title names a coding agent in a cloud account and the controls split at the page boundary. A governed browser environment covers what an agent reads and does on a rendered page: the cloud console, an identity and access management (IAM) role page, a settings page, a cost dashboard, a sign-up form. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. Most of the credential work in the title happens on the far side of that line. An agent that runs a command and receives a role's temporary credential from the metadata endpoint is outside a browser control, and no page-level mechanism changes what the command returns. The same agent, asked to check which policies a role carries or to rotate an access key, opens the console, and that page is inside the boundary.

The console is where the account's keys are listed, where a role's policy is displayed and where a rotation is confirmed. How to Use AI Agents for Google Cloud Deployment treats the deployment work as the unit of analysis, and the same console pages appear in it. A scoped role answers the outside half and says nothing about the inside half.

The record is one agent in one cloud account that curls the metadata endpoint and then opens the console's role page. The first step is governed by the role: what it can do, for how long, and what the platform logs. The second is governed by what the page renders. A team that scopes the role and stops there has bounded the credential, not what the model reads about the account.

Where does the credential come from when a coding agent runs on my instance?

A role attached to an instance is assumed by the platform, and the workload obtains temporary credentials from the instance metadata endpoint. The credentials expire, which beats a key in a file, and the expiry is not custody. Until it expires, the credential is a bearer token that a process able to reach the endpoint can obtain.

A coding agent does not have to be compromised to receive a credential it should not hold; it has to be running. The platform gives three controls. A session policy narrows what the assumption can do, because "The resulting session's permissions are the intersection of the role's identity-based policy and the session policies" (AWS, AssumeRole, 2026). Duration bounds the window: "The value specified can range from 900 seconds (15 minutes) up to the maximum session duration set for the role" (AWS, AssumeRole, 2026).

A chain has its own ceiling: "Role chaining limits your AWS CLI or AWS API role session to a maximum of one hour" (AWS, AssumeRole, 2026). None of the three decides who receives the credential: a scoped role still gives its bearer the scope, and the agent that reaches the endpoint gets it. The root-key advice in Is It Safe to Let an AI Agent Set Up Your Cloud Environment? points the same way.

The record makes the gap concrete. One agent curls the endpoint, receives credentials valid for the rest of the task, and the model now holds a bearer token that no person typed. Narrowing the role reduces what that token can do, not what the model holds, and says nothing about the console page the agent opens next.

What do the vendors themselves say?

The vendor pages describe how a credential is issued, scoped and stored, and they stop at the boundary of the workload. AgentCore Identity states that "Centralized credential management eliminates the need to embed secrets in agent code or configuration files," the adapter pattern in a vendor's own words, though the page does not describe what the model reads on a console (AWS, Features, 2026). The service's security blog describes a token vault built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets," and says the agent retrieves them with its own workload token (Douglas III and Abrom, 2025).

Secrets Manager, read the same day, states that "you can configure an automatic rotation schedule for your secrets," which shortens the life of a stored key (AWS, What, 2026). The same page says "You replace hard-coded credentials with a runtime call to the Secrets Manager service to retrieve credentials dynamically when you need them," a handoff to whatever process makes the call (AWS, What, 2026).

Microsoft documents that "This token acquisition doesn't require any secrets and is automatically authenticated based on the environment where the code runs," which makes the credential a property of the environment rather than of the task (Microsoft, 2026). None of the pages describes the screen that follows the call, so a buyer learns the custody design and not what the model sees when the agent opens the console page that lists the account's keys.

Dimension AWS, per its documentation What a buyer should verify
Credential form Temporary credentials from AssumeRole; sessions from 900 seconds to the role maximum The session duration set on the role and whether chaining extends it
Scope Intersection of the role policy and the session policy Who can change the role policy and how the scope is reviewed
Storage Secrets Manager rotation and runtime retrieval; the AgentCore vault for OAuth tokens and API keys Whether the agent receives the value or a token for it
Attribution Audit logs that separate an agent's actions from a person's That the log records the agent separately from the person
Page exposure Not described in the pages reviewed What the model reads on a console page that lists keys

What does an adapter add that a scoped instance role does not?

An adapter is a small piece of software that holds the credential and makes the call, so the agent asks for an action and never receives the key. The pattern appears in vendor documentation: a vault that issues the agent a token for its own workload, or a credential store that hands a value to a caller. Both move the credential into a component the agent does not read.

What an adapter adds to the role is a place to decide. The role answers what the credential may do. The adapter answers which request is made and on whose approval. A role attached to the instance is ambient by design: the platform authenticates the environment, not the task (Microsoft, 2026). An explicit request can be logged, approved or refused.

It also adds attribution. The AWS Well-Architected guidance asks for designs where "audit logs attribute every action unambiguously to either an agent or a human actor," which a role assumption alone does not provide (AWS, AGENTSEC03-BP02, 2026). A role assumption recorded against an instance is not the same record as an action recorded against the agent that requested it.

The limit is that the adapter governs the call and not the page. An agent that uses it correctly can still open the console, read the role's policy and describe the account's keys to its model. The OWASP entry for excessive agency, summarized on How Do You Secure AI Agents in Production?, is a control on authority for the same reason.

What can the agent still read once its keys are out of the environment?

More than the credential layer suggests. The agent that curls the metadata endpoint is also the agent asked to check a policy, rotate a key or confirm a deployment, and each task ends on a console page. The page renders the access key table, the policy document, the account identifier and the resource list. Whatever the page renders, the model receives, and the credential the environment withheld is often printed on the screen the agent was sent to read.

The research record is direct. Zhang and colleagues report that "Our benchmark results reveal critical vulnerabilities in different stages of agent operation" and "limited effectiveness shown in current defenses" (Zhang et al., 2025). The benchmark does not measure console pages, but a page read is one of the stages it names.

Truffle Security reports that "11,908 Live Secrets were detected using TruffleHog in 400TB of web data" (Truffle Security, 2025). It also found that "2.76 Million Web Pages contained live secrets," though the post does not establish that any particular corpus included those pages (Truffle Security, 2025).

The practical question is which pages the agent reads while using the credential. A scoped role and a short session reduce what a leaked credential can do. They do not reduce what a console page shows the model. Does an AI Agent Need Your Admin Login to Set Up a SaaS Tool? makes the same case for the admin account: the rule written for people applies with more force to an agent.

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 a key becomes CRED_001 and an account number becomes ACCT_001 on every page the agent opens. 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. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring. The cost is a lookup on the path that renders the screen, one bounded operation (Can Runtime Tokenization Protect Data Without Slowdowns?).

For this page's question it changes the half the IAM controls leave open. A scoped role decides what the credential may do. A short session decides how long. Neither decides what the model sees on the console page where the credential's effects are displayed, and neither produces a statement of what the model read. The governed environment does, screen by screen, with the name of the person who approved the rotation.

The agent can still be given a scoped role for the work that happens outside a page; the governed environment does not pretend to govern the terminal, the IDE, the local filesystem, direct API calls or MCP. What it covers is the rendered page, which is where the keys are listed, the policies displayed and the approvals recorded. A team that scopes the role and stops there has bounded the credential. A team that also governs the page has bounded the exposure.

Methodology and limitations

This page rests on vendor documentation from AWS and Microsoft, one standards document from the Model Context Protocol project, two research preprints on agent security and credential memorization, and one vendor research post from Truffle Security, together with existing research pages from this site. Vendor pages were read as of October 20, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and the preprints are cited for what their abstract pages report rather than for figures those pages do not give. The role, session and credential facts are quoted rather than summarized, so each can be checked against the page that states it.

No hands-on testing was done on any of the named products. Where this page says a behavior is not described in the pages reviewed, it means the pages listed in Sources were read and the behavior was not among them, not that the vendor does not support it. Vendor features change, and the page carries its date, so a release after that date should be treated as unreviewed until the test at the end is repeated. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. The worked record describes a record type, one agent in one cloud account, and not an organization.

Determinations about whether a role, a session policy or a logging arrangement satisfies a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a review of the account's IAM policy against the task, or a test of what the agent's model actually received on the pages it read.

What the record shows

The documented controls answer the credential half of the title cleanly. A role can be scoped to a task through its identity policy and a session policy, a session can be shortened, and a credential service can keep the key out of code and configuration. What none of those controls describes is the page. The agent that gets its credential from the instance metadata endpoint is also the agent that opens the console to check what the credential can do, and the console renders the key table and the policy in full. The research record on memorization and on credentials in web data explains why that matters: text a model reads is text it can repeat. RedactSure's environment is built to render those pages as tokens, which is one answer to the title and not the only one. One named agent, one role and one console page are enough for a platform team to test which process held the credential and what the model received when the page rendered.

Frequently asked questions

Can I run a coding agent in my own cloud account without giving it my keys?

Yes, with two conditions. Attach a role scoped to the task and to a short session, and put an adapter between the agent and the credential so the agent asks for an action rather than receiving the key. Scope covers which actions, which resources and which conditions. The role narrows what a leaked credential can do. The adapter decides whether the model ever holds it. Neither condition changes what a console page renders, which is the part to test next.

Is an instance role safer than an access key in a file?

It removes the long-lived credential from the disk, which is a real gain: there is no file to commit, paste or forget to rotate. What it substitutes is a credential the workload obtains from its environment, so anything running there can obtain it too. A role with a wildcard action is not scoped in any useful sense. Safety depends on the role's scope and the session length, not on the absence of a file. Compare the two by asking what each can do and for how long.

What ends up in the model's context when the agent runs in my account?

Whatever the agent reads. A command's output, a log line, a console page, a policy document and an error message all arrive as text, and a credential printed in any of them is in the context. The transcript, the summary and any file the agent writes keep it. The instance metadata response is one route; the console page that lists access keys is another. The only reliable answer is to trace one task and write down each value the model received.

Does a short session limit the damage?

It limits the window. A credential valid for fifteen minutes is worth less to an attacker than one valid for a day, and a session policy can narrow what it does inside that window. It does not decide who holds the credential during those minutes. Minutes matter more than days, and scope matters more than either. An injected instruction that runs in the first minute still has the full window ahead of it. Treat duration as one setting among three, with scope and custody.

What should I ask a platform team in writing?

Which role the agent assumes, what its identity policy allows, whether a session policy narrows it further, and how long a session can last. Ask how the agent obtains the credential and whether any component holds it on the agent's behalf. Ask what the audit log records and whether it separates the agent's actions from the person's. Ask which console pages the agent reads and what those pages display, and get the answers before the first task runs.

Is a secret manager enough?

It solves storage and rotation. A secret manager can keep the key out of code and configuration and rotate it on a schedule, which removes two common failures. It still hands the value to the process that calls it, and it says nothing about the page. Ask where the value goes after the call returns. If the agent reads the key from the store and then displays it, or reads a console page that shows it, the store did its job and the exposure happened anyway.

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 Cloud Key Out of the Agent's Context

The IAM half is documented and a team can do it today, but the platform does not govern the console page that displays the keys.

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

Before: the agent opens the console's role page to check the role it runs under, and the key table and policy render in full. Inside: the same page renders with CRED_001 for the key and ROLE_001 for the policy, and the real key resolves only when the named reviewer approves the rotation.

RedactSure is deploying now with enterprise and government customers. TruffleHog's scan found 11,908 live credentials exposed in public web data.

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

See it on your own workflow

Running the agent in your own cloud account changes where it runs, not what the console shows it. Bring a task in your console 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.