Skip to content
redactsure
Book a demo

Explore.

Guide · By Chris Sowa · Published
Last updated

How to Secure AI Agents Across AWS, Azure and GCP: One Governed Environment, Three Consoles, No Keys in the Model

Give the agent no key on any of the 3 clouds; let cloud identity govern what it may do and a render layer govern what the model sees.

Three cloud environments connect through a shared security boundary and layered controls.

62% experimenting · 23% scaling · 3 consoles

62% of organizations are experimenting with AI agents and 23% are scaling them (CX Today, 2026). The gap sits in places like your cloud accounts, where an agent's mistake becomes an invoice or a breach. Each of your three consoles renders an account ID, a key ID or a connection string on the second screen the agent opens, and the agent reads whatever is on the screen in front of it.

Today it is probably an access key in a file on a laptop, the agent in that shell, "always allow" switched on after a few prompts, and the API audit log as the record. That puts the key and every account identifier in front of the model, and leaves no one on the record for the role it widened.

Rome kept the keys to the treasury with a quaestor and the right to spend with the Senate, two offices, never one. Cloud agents need the same split. Cloud identity governs what the agent may do. A render layer governs what the model sees. A named person stands in front of every key, role, port and dollar, and one record across three consoles lands in your SIEM.

AWS, Azure and Google Cloud each tell you to delete the key the agent would hold

AWS calls for temporary credentials and no long-lived access keys for workloads (AWS, 2026). Azure documents managed identities in place of stored credentials (Microsoft Learn, 2026). Google Cloud documents Workload Identity Federation in place of service account keys and says such keys should rarely exist (Google Cloud, 2026). The agent gets no key of its own; it works under the identity a named person already holds, and nothing outlives the task.

That removes the first exposure, the key in the shell. It does not remove the second. A console still renders the account ID, the role ARN and the key ID whether a person or an agent is reading the page. Identity answers "may this principal call this API." It does not answer "what did the model read before it chose that call." Content a model reads can carry instructions (Greshake et al., 2023), and OWASP lists prompt injection first among LLM application risks (OWASP, 2025). A page the agent reads on your behalf is content.

An IAM role governs what the agent may call on 3 clouds; a render layer governs what the model reads

Permissions govern acts. Exposure governs sight. The principle for the second is Least Exposure: for each piece of work, the AI receives exactly the data the task requires and nothing more, enforced before any model reads the screen. The mechanism is render-layer tokenization: replacing sensitive values with consistent stand-in tokens at the point where a screen is rendered, before any AI model reads it, so the model works with SSN_001 and ACCT_001 and real values resolve only at approved destinations at the moment of action. On a console that means ACCT_001, ROLE_001, KEY_001 and SECRET_001, with instance types, regions and policy documents in clear.

Property Keys in a shell on a laptop Vendor-hosted cloud computer Customer-owned governed environment
Where the key lives A file the model can read Sign-in outside the model's context (OpenAI, 2026) No key; the person's own identity
What the model reads on the IAM page The whole page The webpage text (OpenAI, 2026) Task fields, with ACCT_001 and KEY_001
Who holds the environment's keys You, on one laptop Not disclosed (OpenAI, 2026) You
Who approves a widened role Whoever clicked "always allow" Custom Rules the user sets A named person, on the record

The password stays out of the model's context. The account ID on the next screen does not.

7 actions commit a key, a role, a port or a dollar, and each waits for a named person

Supervised Delegation means a named person grants the access, chooses the applications, confirms what is tokenized, can watch and pause the run, and approves every consequential action, on the record. The agent under it is a tethered agent: an agent that works only inside the governed environment a named person connected it to, on the applications that person chose.

The 7 actions stop for that person: creating a credential; attaching a policy, a role assignment or a binding; opening a port; launching an instance; requesting a quota increase; creating a deployment; writing a secret.

"Always allow" is the setting you reach for after a few prompts. Microsoft's AI Red Team catalogued agent failure modes, including those caused by observed content (Microsoft, 2025). A model turned by a page it read cannot create a key or open a port when the step waits for a person.

One record across 3 consoles replaces 3 audit logs and a vendor's activity view

The AI Control Record is the record of every screen the agent saw as tokens, every action, every approval with a name, exported to the customer's own monitoring.

CloudTrail, the Azure activity log and Cloud Audit Logs record which principal made which API call; the vendor's activity view lets the user follow, redirect or stop work (OpenAI, 2026). Neither shows what the model read before it chose the call, and neither carries a named approval.

Property Cloud API audit log Vendor activity view Control record in your SIEM
Which principal called which API Yes As the vendor shows it Yes, plus the agent's draft
What the model saw before the call No The page as the vendor renders it Each screen as tokens
Who approved the step No The user's own rules Name, time, decision, scope
Retention and format Three clouds, three formats The vendor's One format, your retention

OMB M-24-10 asks federal agencies for human oversight and monitoring of rights- and safety-impacting AI (OMB, 2024). The named stop is the oversight. The record is the monitoring.

A secret resolves only inside Secrets Manager, Key Vault or Secret Manager, at the moment of an approved write

The agent drafts a deployment that needs a connection string in AWS Secrets Manager, Azure Key Vault or Google Cloud Secret Manager (Microsoft Learn, 2026; Google Cloud, 2026). The run stops. The named person approves the write. The real value resolves only at that destination at that moment. The model saw SECRET_001 throughout; the vault's version history shows the write under the person's identity.

Compare the ungoverned path. A person opens a secret's page in the vault with an agent in the same browser, and the model reads the secret. No DLP rule catches it, because DLP governs where data may go, not what a model may see on a screen it is already reading. No connector scope catches it, because a scope decides which app the agent reaches, not which fields the model receives.

The environment belongs to you whichever of Claude Code, Claude Cowork or OpenAI Dots does the work

4,000+ apps · 1 cloud computer per agent · 1 page read in full

One vendor's own account: Dots connect to more than 4,000 apps, each with its own cloud computer and browser (The Next Web, 2026), and the model sees the webpage text (OpenAI, 2026). Claude Code runs in the terminal, reads and edits files and runs commands (Anthropic, 2026). Neither is the control.

Separation of model and control is the principle that the environment deciding what an AI agent sees and who approves what it does is owned by the customer and independent of whichever model performs the work. In cloud terms: the render layer, the planner, the named person and the record sit in a secure VM you deploy, with keys you hold. The agent you chose (Claude Code in the terminal, Claude Cowork on the desktop, or an OpenAI dot) does the work inside the environment. Swap the model and the stops, the tokens and the record stay put.

6 Rules for securing agents across three clouds

Delete every long-lived key before the agent arrives

For the workloads the agent sets up, an instance profile, a managed identity or Workload Identity Federation replaces the access key or service account key (Google Cloud, 2026). The agent itself gets no key and no workload identity; it works under the named person's existing permissions. Test: search every machine the agent will use for credential files and key material; the search returns nothing.

Connect under the named person's identity and create nothing for the agent

The person who owns the task connects the environment to the three consoles and CLIs under the permissions they already hold; no principal is created for the agent, and permissions do not change. CloudTrail, the Activity Log and Cloud Audit Logs then show the person's principal for the agent's actions and the person's own alike; the control record is what tells them apart. Before: a service account named for the agent, a key in a file, a role wider than any task. After: the person's own principal in all three API logs, the agent's actions marked in the control record, and nothing that did not exist before the agent.

Tokenize identifiers and keep the facts the task runs on in clear

The planner proposes the policy; the person confirms it as the first entry in the record.

Becomes a token Stays in clear
Account, subscription and project IDs (ACCT_001) Instance types and regions
Role ARNs and service account emails (ROLE_001) Quota values and error text
Key IDs, secrets, connection strings (KEY_001, SECRET_001) Policy documents, firewall rules, costs

Stop every credential, role, port, launch, quota request and deployment

Each commits exposure or spend. The agent drafts; the person reviews the scope and submits. Before: the agent requests a GPU quota overnight under "always allow" and the launch runs with no named approval when it clears. After: the request waits in the record with the estimated spend; the person submits it in the morning.

Write secrets only at the vault, only at the moment of approval

The secret is written to Secrets Manager, Key Vault or Secret Manager after the person approves; the real value resolves there and nowhere else. Test: the record entry for the write shows SECRET_001; the vault's version history shows the person's identity.

Export one record, in one format, to the SIEM you already run

Every screen as tokens, every action and every approval with a name lands in one schema across the three clouds.

The SIEM query What it returns when the rule holds
All entries for the run AWS, Azure and Google Cloud in one format
Any entry with a real account ID, key ID or secret Zero rows
Every launch, quota request and IAM change A matching approval with a name

How to choose where the agent runs

  • If the account carries production workloads, run the agent in a customer-owned governed environment with keys you hold, never on a laptop with keys in a file.
  • If the work is terminal-heavy, put Claude Code inside the governed environment, where no key file exists and consequential commands stop for the named person.
  • If the work is console-heavy, put a browser agent inside the same environment rather than in an employee's own browser or a vendor's cloud computer.
  • If a vendor's documentation says the model sees the page in full, keep that agent off IAM and secret store pages.
  • If a vendor's cloud computer does not disclose its key holder, keep federal and regulated accounts in your own environment.
  • If you expect to change models within a year, choose the environment that keeps the render layer, the stops and the record when the model changes.

The checklist

Check Pass Fail
Key files on any machine the agent uses None found A key file or shell profile entry
Principal in the cloud API logs The named person's existing identity A new principal for the agent
First record entry The confirmed per-task policy with the person's name A screen
One IAM screen in the record ACCT_001, ROLE_001, KEY_001 A real account ID, ARN or key ID
A secret store screen in the record SECRET_001 The secret in clear
Every key, role, port, launch and quota request Matches an approval entry with a name Any action with no approval entry
SIEM search for the run Three clouds, one format, no real identifier A cloud missing, or a real identifier
A test injection in a page the agent read Collected only tokens; the step still stopped A real value left, or a step ran without a name

Questions

Should the agent ever hold an access key?

No. AWS calls for temporary credentials and no long-lived access keys for workloads (AWS, 2026), and Azure and Google Cloud say the same of their own keys. A governed agent works under the identity a named person already holds. When a task needs a key for another system, the creation stops for that person, and the key ID reaches the model as KEY_001.

Can one environment govern all three clouds?

Yes. The environment works the console and the terminal the way a person does, and all three clouds render a console and accept a CLI. The identity scheme differs per cloud: an IAM role on AWS, a managed identity on Azure, Workload Identity Federation on Google Cloud. The render layer, the planner, the named person and the record do not differ.

Does a managed identity or IAM role solve the problem on its own?

No. A managed identity or IAM role governs which calls the principal may make. It does not govern what the model reads on the console page that renders the account ID or the connection string. Identity is the answer to "may it act." The render layer is the answer to "what may it see." You need both, and they sit in different places.

Can Claude Code run aws, az and gcloud inside the environment?

Yes, and a terminal inside the governed environment is where those commands belong. Claude Code runs in the terminal, reads and edits files and runs commands (Anthropic, 2026). That terminal holds no key file, the agent works under the named person's existing permissions, and a command that creates a key, binds a role or opens a port waits for that person. Any console screen the agent opens reaches the model with identifiers as tokens.

What happens when the agent hits a quota limit?

It stops and reports. GPU instance families often require a quota increase (AWS, 2026), and that request commits spend. The agent drafts the request with the family, the region and the count; the named person submits it; the agent resumes once the quota is in place. The request, the approval and the estimated spend sit in the record together, under one name.

Is a vendor's secure sign-in enough?

It covers the password. OpenAI's documentation says sign-in submits credentials without exposing them to the model's context, and that the model sees the webpage text (OpenAI, 2026). On a cloud console the screen after sign-in carries the account ID, the role ARNs and the key IDs. Sign-in protection ends at the login page; the render layer continues on every page after it.

What if an injected page tells the agent to create a key?

The model reads the instruction, because content a model reads can carry instructions (Greshake et al., 2023). It drafts the key creation, and the draft stops for the named person, who sees a request the task did not call for and declines it. The attacker collected ACCT_001 and ROLE_001, and the record shows the page, the draft and the refusal.

Methodology

What this page rests on. AWS, Azure, Google Cloud and Anthropic documentation; OpenAI's September 29, 2026 account of Dots; McKinsey's State of AI 2026 as reported by CX Today; OWASP LLM01; Greshake et al. (2023) and Microsoft's AI Red Team taxonomy (2025); OMB M-24-10; all read as of October 9, 2026.

What was not tested. No hands-on testing of Claude Code, Claude Cowork, OpenAI Dots or any cloud console was performed for this page. Console flows and quota behavior change with releases; the page carries its date.

Whose determination it is. Whether an agent, environment or record meets your obligations under OMB M-24-10 or any contract is for your counsel, your assessor and your security and compliance officers to decide.

How RedactSure does this

3 consoles · 1 render layer · 1 record

RedactSure runs the agent inside a customer-owned governed environment: a secure virtual machine in the cloud your posture requires, on hardware-encrypted enclaves, with keys you hold. The render layer tokenizes each console screen before any model reads it, so the model receives the task's fields with identifiers as ACCT_001, ROLE_001, KEY_001 and SECRET_001. The planner writes the per-task policy; a named person confirms it, then approves every credential, role, port, launch, quota request, deployment and secret write under Supervised Delegation. Real values resolve only at Secrets Manager, Key Vault or Secret Manager at the moment of an approved write. Every screen, action and approval lands in the AI Control Record and exports to your SIEM in one format across the three clouds.

The agent you chose (Claude Code in the terminal, Claude Cowork on the desktop, or an OpenAI dot) does the work inside the environment, and the model is swappable without moving the controls. RedactSure does not change permissions. Prompt injection that succeeds collects tokens, and the consequential action still stops for a named person. Deployments are in pilot.

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.