Identity and egress: the invariants that must hold on any cloud

Lesson 3 of 5 in Choosing a Cloud for Agents: A Decision You Can Defend.

Here is the move that makes this decision tractable: stop comparing security features and start writing security invariants. An invariant is a sentence about your system that must be true on every run, on any substrate — AWS, Azure, Google Cloud, your own Kubernetes cluster, a laptop in CI. Write seven of them and the platform comparison becomes mechanical: for each invariant, which mechanism enforces it here, and can you demonstrate it to an auditor?

The invariants also survive the rebrands. "Credentials never enter the context window" was true before any of these services existed and will be true after the next renaming. The mechanism that satisfies it — a token vault, a toolbox injecting credentials, a gateway brokering egress auth — is the part you look up.

Trace a single tool call and you can see every place an invariant has to bite. Nothing in this diagram is optional; the only question a platform answers is which layer already implements it for you.

One tool call, and every gate that must exist somewhere

Model emits a tool-call request
Still just text. Nothing has happened yet — which is exactly why enforcement belongs here and not in the prompt.
Is there a named principal?
The agent’s own identity, and — when acting for a person — the user whose authority is being exercised. Anonymous calls cannot be scoped, audited, or revoked.
Is this tool in that principal’s scope?
Checked by a policy engine outside the model: Cedar policies at the AgentCore gateway, guardrail controls at Foundry tool-call intervention points, semantic governance policies over tool calls on Google Cloud.
High-impact or irreversible?
The gate question from foundations, asked per action rather than per product.
Human or policy approval before commit
A gate only counts if the reviewer sees the amount, the recipient and the diff — and has time to say no.
Broker injects the credential at call time
Vault or toolbox hands the token to the call, scoped to this principal. The credential must never appear in the prompt, the tool arguments, or the trace.
Is the destination allowlisted?
Default-deny egress. Without this, exfiltration needs only one poisoned document and one outbound-capable tool.
Execute with least privilege, in a sandbox
Per-session isolation matters here: a dedicated microVM, a VM-isolated session sandbox, or a managed code-execution sandbox — so one run cannot read another’s filesystem.
Append audit record: principal, tool, args, decision
The trace and the audit log are different products with different retention. You need both — one to debug, one to answer "who authorised this".
Result returns to the loop as untrusted data
Tool output is attacker-influenceable input. Scan it, tag it, and never let it silently upgrade its own privileges.
Refuse and record
A refusal that is not logged is invisible. Denials are your best early signal that an agent — or someone driving it — is probing.

Now the crosswalk. Same seven invariants, three clouds, one column each — and one honest observation: the further down this table you read, the more the wording turns from "here is the service" to "here is where you would have to check". That is not evasion; it is the actual state of the market in September 2026. Egress control for agents is the least mature column across all three platforms, and it is the one that stops a poisoned document from becoming a data breach.

Seven invariants and the documented mechanism on each platform (September 2026 — verify per component and region)
Invariant	AWS — Bedrock AgentCore	Microsoft Foundry	Google Cloud — Agent Platform
1 · Every call carries a named principal	AgentCore Identity gives the agent a workload identity; inbound auth is IAM SigV4 or OAuth JWT bearer via a configured authorizer (IdP discovery URL plus allowed clients), and AWS resource access runs through the Runtime execution role.	Each hosted agent automatically receives a dedicated Entra identity — a special kind of service principal created from a blueprint, with an optional human sponsor. With a user token present it can use OAuth 2.0 on-behalf-of; without one it authenticates as itself.	Agent Platform runtime operations include IAM-based agent identity, so the agent is a Google Cloud principal that IAM policies can name.
2 · Credentials never enter the context window	AgentCore Identity’s token vault stores OAuth access and refresh tokens, API keys and client secrets, KMS-encrypted with customer-managed keys supported; user-specific credentials are accessible only by the agent acting for that user.	A Toolbox centralises credential injection, token refresh and OAuth identity passthrough via Entra ID; MCP connections choose from none, custom keys, OAuth2, user Entra token, project managed identity or the agent’s own identity.	Agent Gateway sits in front of tool and API calls and processes authorization requests (it is even metered that way); ADK documents tool authentication as a first-class concern.
3 · Tool scope is least privilege, enforced outside the prompt	AgentCore Policy evaluates attribute-based Cedar policies (permit/forbid over principal, action, resource, with when-conditions) against every action passing through the Gateway — including conditions on tool-call input attributes.	Guardrails are named collections of controls with four intervention points: user input, tool call and tool response (preview, agents only), and output. Toolbox adds policy enforcement at the tool endpoint.	Semantic Governance Policies are natural-language constraints that govern agents through their tool calls, applying to all agents on Agent Runtime.
4 · Outbound network is default-deny	Route tool traffic through the Gateway so there is one egress point with brokered credentials, and use custom browser/network configuration for the sandboxed tools. Ask specifically how a code interpreter or browser session reaches the internet in your configuration.	Network egress controls exist in preview and apply to hosted agents only, configured inside the same guardrail; private networking uses an injected VNet with private endpoints.	VPC Service Controls are listed for Runtime, evaluation, Sessions, Memory Bank and Code Execution, with Private Service Connect interfaces for private connectivity.
5 · One session cannot read another’s data	Dedicated microVM per session (documented defaults: terminate after 15 minutes idle, 8-hour maximum life, ephemeral state); Memory events are scoped by actor and session with namespace paths.	Per-session VM-isolated sandbox with a persistent filesystem, idle timeout configurable 2–60 minutes (default 15), state restored on resume, session deleted after 30 days of inactivity.	Managed sandboxes for code execution and Computer Use, with Sessions as the per-conversation store and per-instance resource controls.
6 · Every action is auditable with the principal attached	OTel-format telemetry to CloudWatch (a one-time per-account Transaction Search enablement is required before traces and spans appear), plus audit logging.	Traces stored in Application Insights using OpenTelemetry generative-AI semantic conventions, viewable in the portal or Azure Monitor.	Cloud Trace and Cloud Logging, with Access Transparency and Access Approval listed for Runtime, Sessions and Memory Bank.
7 · Untrusted content is treated as untrusted	Bedrock Guardrails’ six safeguard types include prompt-injection content filters; since July 2026 AgentCore Policy evaluates guardrail checks at the Gateway on inputs to targets and outputs of authorized actions — outside the agent’s code.	Prompt Shields covers user prompt attacks and document attacks (indirect injection), scanned at user input and tool response; spotlighting (preview) tags and base-64 encodes third-party content so the model trusts it less.	Configurable safety filters cover four harm categories with per-threshold blocking, plus non-configurable filters for CSAM and PII; semantic governance applies at the tool-call layer.

Preview-tier controls, production-tier promises

Three of the most security-relevant capabilities above carry qualifiers you must read: Foundry’s network egress controls are preview and hosted-agents-only, Foundry’s tool-call and tool-response guardrail intervention points are preview, and Google’s per-service support matrix for VPC Service Controls, CMEK and residency has per-component gaps (Example Store, for instance, is not listed alongside the others).

Never let a slide-level "yes, that is supported" stand in for a per-component check. The three questions that catch most of this: Which components does the control cover? What launch stage is it in for my region? Can I demonstrate it in an audit — a denied call, logged, with the principal attached? If your compliance story depends on a preview feature, you have a dependency on a roadmap, not a control.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.