Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Is It Safe to Let an AI Agent Set Up Your Cloud Environment?

It is safe only when the agent never holds root or owner credentials, works under least-privilege roles scoped to the task, and a named person approves every billing, IAM and network change. Check which identity the agent's console session runs as, and whether a person's name is on each change that widens access or spends money.

Connected geometric cloud resources form a branching hierarchy above separated infrastructure platforms.

It is safe only when the agent never holds root or owner credentials, works under least-privilege roles scoped to the task, and a named person approves every billing, IAM and network change. Check which identity the agent's console session runs as, and whether a person's name is on each change that widens access or spends money. A cloud console is the most powerful page an organization renders. One signed-in browser session can create projects, attach a payment method, grant a role to any principal, open a network to the internet and create keys that outlive the session. Handing that page to an agent hands it the controls of everything the organization will later build there. The cloud providers' own guidance already says how the most powerful identities should be treated, and that guidance applies unchanged when the operator is a model. This page states what a browser control covers for a developer and what it does not, walks through the power a console exposes, sets out which credentials the agent should never hold, names the changes that need a person's approval, describes what the record of an agent-built environment should contain, and lists the claims a buyer should refuse. It builds on an earlier walkthrough of how an agent can set up environments on Google Cloud while the environment holds the keys.

Key findings

  • AWS states that it strongly recommends not creating access keys for the root user, which rules out the simplest way an agent might be given durable top-level power (AWS, 2026).
  • The major providers document identity designs that avoid handing a long-lived secret to whatever is doing the work: Google Cloud's workload identity federation (Google Cloud, 2026) and Azure's managed identities for Azure resources (Microsoft Learn, 2026) are both documented alternatives to distributed keys.
  • CISA and partner agencies have issued joint guidance on the careful adoption of agentic AI services, which places delegation of infrastructure work to an agent within a formal risk review (CISA, 2026).
  • OWASP describes excessive agency, an agent granted more functionality, permissions or autonomy than its task requires, as a top-ten risk for LLM applications, and a console session under an owner role is the clearest case of it (OWASP, 2025).
  • Zero trust architecture evaluates each request at a policy enforcement point rather than trusting a session once it is open, which is the model a console session for an agent should follow (NIST, 2020).
  • A record that holds every screen as tokens, every action and every approval with a name is what turns an agent-built environment into something an auditor can reconstruct (How to Set Up an AI Control Record for AI Agents).

What does a governed browser environment cover when an agent sets up a cloud environment?

The scope comes first. A governed browser environment covers what an agent reads and does on a rendered page. For cloud setup that means the console: the project creation screen, the billing page where a payment method is attached, the IAM page where principals and roles are listed, the network page where firewall rules and public addresses are set, the key creation dialog that shows a secret once, and the dashboards and settings pages the agent reads to confirm its work. On each of those pages the environment decides which values the agent sees and which actions it may take, and it can hold a human approval in front of any action.

The same environment does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP servers. A developer who asks an agent to run a cloud provider's command-line tool, apply an infrastructure template from a shell, or call the provider's API from a script is working outside the browser, and a browser control makes no claim about those paths. Nothing on this page implies that a control on rendered pages governs a shell. Microsoft documents computer use in Copilot Studio as automating web and desktop applications through their interfaces (Microsoft, 2026), which is a useful reminder that the interface path and the API path are distinct even when the same vendor offers both. A developer evaluating an agent for cloud setup should ask, for each safeguard a vendor describes, whether it applies to the console, the shell or both.

What power does a single cloud console session expose?

Take one record type: the console for a newly created project, as it renders after sign-in under the account that created it. The overview page shows the project identifier, the billing account it is linked to and the owner's email. The IAM page lists every principal with a role, including the creating account as owner. The billing page shows the payment method on file, a spending view and the controls to attach another card. The network page shows the default firewall rules and the option to open a port to any address. The service account page offers to create a new identity and to generate a key for it, displayed once in a dialog. The audit log page shows who did what, with timestamps.

Everything on that list is readable by an agent that works the console, and most of it is writable. Google Cloud documents its resource hierarchy of organization, folders and projects as the structure through which policies attach and inherit (Google Cloud, 2026), which means a role granted high in that hierarchy by an agent on one page reaches every project beneath it. The page the agent is reading, and the role its session carries, together set the blast radius of any mistake or any injected instruction.

The values on the console are also sensitive in themselves. The owner's email, the billing contact, the project identifiers and any key shown in a creation dialog are exactly the values an attacker-shaped page would try to extract, and they are rendered in plain text for the operator. The question of what an agent sees in a screenshot of such a page is covered elsewhere; here it is enough to note that a console session shows the agent both the controls and the secrets.

Which credentials should the agent never hold?

The providers' own guidance is the starting point. AWS states that it strongly recommends not creating access keys for the root user (AWS, 2026). A root or owner credential is not a role that can be narrowed; it is the account itself. An agent whose console session runs as root, or that is handed a root access key to complete a step, holds everything, and no approval placed in front of a single action changes what it could do on the next one.

Credential or identity What the provider documents What an agent session should use instead
Root user access keys (AWS) Strongly recommended not to create them A scoped IAM role assumed for the task
Service account keys (Google Cloud) Best practices for service accounts published; federation documented as a keyless path Workload identity federation or a short-lived token
Managed identities (Azure) Platform-managed identity for Azure resources The managed identity of the governed environment, not a user's credentials
Owner or super admin console session Not a role to delegate A least-privilege role scoped to the project and the task

Google Cloud publishes best practices for using service accounts (Google Cloud, 2026) and documents workload identity federation as a path to credentials without a distributed key. Microsoft documents managed identities as platform-managed identities for Azure resources, so the resource authenticates without a secret in its configuration. The common thread is that the identity belongs to the environment doing the work and is scoped to that work, rather than being a person's credential pasted into an agent's session. The page on setting up S3 with GitHub using OIDC rather than keys walks one such design.

Which changes need a named approver?

Three categories of console change deserve a person's name on them: anything that spends money, anything that widens access and anything that opens a network. Attaching a payment method, raising a quota or enabling a billed service is a financial commitment. Granting a role, creating a service account, generating a key or adding a member to a project is an access change, and in a hierarchy it may be inherited downward. Opening a firewall rule, assigning a public address or peering a network is an exposure change. These are the actions where an agent's error, or an instruction injected through a page it read, does lasting damage.

The joint guidance from CISA and partner agencies on the careful adoption of agentic AI services treats delegation to an agent as a decision to be made deliberately, with the organization's risk process engaged (CISA, 2026). OWASP's excessive agency entry describes the failure that approval prevents: an agent with more permissions or autonomy than the task requires taking an action no one intended (OWASP, 2025). A gate on these three categories slows only the handful of actions whose consequences outlast the session.

Zero trust architecture supplies the shape of the gate. NIST describes a model in which access to a resource is decided per request at a policy enforcement point rather than granted once at sign-in (NIST, 2020). For a console session that means the agent's open session is not itself permission to grant a role or attach a card; each such action is a request that a named person decides. Whether that enforcement point should belong to the model vendor is taken up in whether the model vendor should own the agent environment.

What should the record of an agent-built environment contain?

An environment built by an agent will be inherited by people who were not watching. They need to know what was created, under which identity, with whose approval, and what the agent saw while doing it. The provider's audit log answers the first two for API-level events, but it records the identity the session ran as, not the person who approved the step, and it does not show the screen the agent read.

The record this page argues for has three parts. Every screen the agent read, kept as tokens so the record itself does not reproduce the owner emails, billing details and keys that appeared on the console. Every action the agent took, with the page and the field. Every approval, with the name of the person who gave it and the action it released. That structure is set out in how to set up an AI Control Record for AI agents, and when it exports to the organization's SIEM the agent's work sits alongside human administrative activity rather than in a separate silo. Google Cloud's documented resource hierarchy (Google Cloud, 2026) is a useful index: each approved change can be placed at the level where it took effect.

The record also settles a question that otherwise lingers after any agent-built environment: whether a key or credential was ever displayed to the model. If the key creation dialog was rendered with the secret as a token, the record shows that; if the session was outside a governed environment, no record can show it and the key should be rotated. Posture tools report what exists; how posture tooling compares with controlling what an agent sees is treated separately.

What does a governed environment change?

In a governed environment, an agent working in a cloud console never reads a root key, an owner session token or a principal's secret in the clear, and every billing, IAM and network change it proposes waits for a named person before it takes effect.

The mechanism is a class of control between the rendered console and the model. Secrets shown in key creation dialogs, principal emails on IAM pages and billing account identifiers are replaced with consistent tokens before any model reads them, and the setup task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, with billing, IAM and network changes on the list. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This bears on the title question because the two conditions the page sets are the ones this class of control enforces at the screen. The provider guidance against creating access keys for the root user (AWS, 2026) is a rule about what the agent is given; tokenizing the dialog is a rule about what the model can read if someone gives it anyway, since a credential shown to a model has been shown. A console session under an owner role is the clearest case of excessive agency (OWASP, 2025), and the approval gate on access-widening and money-spending changes is the limit on it. The record of a pilot run in the organization's own SIEM is the fourth item described above.

The control covers the rendered console and not the CLI, the terminal or infrastructure-as-code files, and it does not change the project hierarchy, the role bindings or the model.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design places the agent's console session inside a governed environment in the customer's cloud, running under the environment's own scoped identity rather than a person's credentials or a root key. Values on the console are substituted at the render layer before any model reads the screen, so the owner's email appears as USER_001, the billing account as ACCT_001 and a key shown in a creation dialog as a token, with the same token for the same value across every page of the run. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, which for a console means every billing, IAM and network change, under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, needs no per-application integration with the cloud provider, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on one real project setup would show the identity the session ran as, the IAM and key pages as the model received them, and the named approvals on each change that spent money or widened access. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on vendor documentation from AWS, Google Cloud and Microsoft on root users, service accounts, workload identity federation, managed identities and resource hierarchy, on Microsoft's documentation of computer use in Copilot Studio, on joint official guidance from CISA and partner agencies on agentic AI services, on NIST Special Publication 800-207 on zero trust architecture, on the OWASP Top 10 for LLM Applications entry on excessive agency, and on RedactSure research pages on cloud setup, the AI Control Record and agent environments. All sources were read as of October 16, 2026.

No hands-on testing of any named product or cloud console was performed, and no environment was built for this page. Provider guidance is cited for the recommendations it states, and where this page says a behavior or control is not described, it means not described in the pages reviewed, not that a provider or product lacks it. Vendor documentation is read as a statement of design intent rather than as test evidence. Provider features, console layouts and role definitions change, and the page carries its date for that reason. Statements about RedactSure describe its current design, with deployments in pilot. The project console, IAM page, billing page and key creation dialog described here are record types, not any organization's systems, and no customer or prospect is described.

Whether a given delegation of cloud setup to an agent, its identity design and its approval gates meet an organization's security policy and regulatory obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

A cloud console concentrates the power to spend, to grant and to expose in one signed-in page, and the providers' own guidance on root users, service account keys and managed identities already says that this power should not travel as a durable secret in the hands of whatever does the work. An agent is the newest such hand. Setting up a cloud environment with an agent is safe in the same way it is safe with a new contractor: the session runs under a scoped identity that belongs to the environment, the changes that spend money, widen access or open a network wait for a named person, and a record that an auditor can read is kept of every screen, action and approval, a record RedactSure's design keeps as tokens. The test is to name one agent and one project setup and ask which identity the console session will run as, which actions will stop for a name, and where the key creation dialog goes when the model reads it.

Frequently asked questions

Can an agent set up a cloud environment without ever being given root?

Yes, and the providers' guidance points that way. AWS strongly recommends against creating access keys for the root user, and the work of creating projects, roles and resources is done under scoped identities in every major console. The agent's session should run under a role limited to the project and the task, and any step that appears to need root is a step that should be redesigned or performed by a person rather than by widening the agent.

Why should billing, IAM and network changes be approved separately?

Because they are the three categories whose consequences outlast the session. Attaching a payment method commits money, granting a role may be inherited across a resource hierarchy, and opening a firewall rule exposes whatever sits behind it. Most console work is reading and configuring, and it can proceed without interruption. An approval gate on these three categories slows only the actions where an agent's error or an injected instruction would do lasting harm.

Does the provider's audit log already record what the agent did?

It records API-level events under the identity the session ran as, with timestamps. It does not record who approved each step, and it does not show the screen the agent read when it acted. If the session used a shared or over-broad identity, every line carries that identity and the path back to a person is lost. A separate record of screens, actions and approvals with names closes the gap the provider log leaves.

Is a browser control enough to govern a developer's cloud setup?

Only for the console path. A governed browser environment covers what the agent reads and does on rendered pages: project screens, IAM pages, billing pages, network pages and key dialogs. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP servers. Setup work that runs through a command-line tool or an infrastructure template is a separate path with separate controls, and the two should be reviewed as two.

What happens if a key was displayed to the model during setup?

Treat it as disclosed and rotate it. A key shown once in a creation dialog is a rendered value, and a model that read the page read the key. If the session ran in a governed environment that substituted the secret with a token at render, the record shows that and rotation is unnecessary. If no such record exists, the organization cannot prove the key was not seen, and rotation is the only way to restore certainty.

How does workload identity federation or a managed identity help here?

Both let the thing doing the work authenticate without a long-lived secret in its hands. Google Cloud documents workload identity federation as a path to credentials without distributed keys, and Microsoft documents managed identities as platform-managed identities for Azure resources. If the agent's governed environment carries such an identity, there is no key for the agent to read, leak or outlive, and the identity's scope is the agent's scope.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

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.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.