An enterprise agent investigating an alert may read an email, query cloud logs, inspect an endpoint, and recommend containment. Each capability is useful. Each also creates a route through which malicious instructions, faulty reasoning, or compromised code could cause an unwanted action.

Identity establishes which agent is represented; authority determines what it may do under current conditions. The architecture must establish how that identity is authenticated, where its credentials can be used, what currently authorizes each action, and whether those controls survive a change of model, runtime, or cloud.

There are several sound approaches. An agent runtime can authenticate with short-lived, cryptographically bound credentials. A managed gateway can broker access to tools. Trusted infrastructure outside an agent’s sandbox can hold both its workload credential and its integration credentials. These approaches can coexist, and each places different obligations on the enterprise.

For enterprises operating across systems and clouds, the recommended destination is an enterprise-controlled authority model with enforceable boundaries around every consequential action. Cloud IAM, SPIFFE, managed gateways, and isolated execution can support that model. Choosing among them should preserve the enterprise’s ability to change infrastructure without rebuilding the meaning of permission.

This article compares those choices and develops an external credential-custody pattern in detail. The examples describe architecture and expected behavior; they are not reports of measured deployments.

Start with credential custody and the threat model

Identity is the principal being represented. Authentication verifies its asserted identity under a defined trust model. Authority is the bounded permission granted to that principal; authorization evaluates whether it permits a particular operation under current conditions. A stable agent identity can persist while the credentials representing it expire and its permissions change.

The first design decision is which components remain trusted when the agent fails. Consider the stronger threat model: malicious code can execute inside the agent’s container or microVM, inspect accessible memory and files, and issue its own network requests. Protecting against this requires more than keeping secrets out of prompts.

Two credential layers matter. The workload credential authenticates the agent’s execution to trusted services. The integration credential authenticates access to a destination such as an incident platform, cloud API, or model provider. A design may protect the second while allowing the runtime to use the first.

The following matrix gives simple, representative paths for reading an incident. It compares documented cloud examples with an architectural option; it is not a ranking of complete products or every configuration they support.

Cloud examples: Google Cloud Run authentication, AWS AgentCore Gateway, Microsoft Foundry agent identity. Documentation reviewed 8 September 2026; the referenced Cloud Run agent feature is Preview.

Cloud services also combine these patterns. Google documents an Agent Gateway and Gemini Enterprise flow in which raw end-user credentials are decrypted at the gateway and remain inaccessible to the agent. Its Agent Identity design also uses certificate-bound tokens and proof-of-possession mechanisms. The correct comparison is the custody and enforcement boundary of a particular path. Google Agent Identity.

A managed cloud path can be a sensible choice when its controls match the workload and the organization benefits from managed operations. External custody deserves consideration when agents execute untrusted code, use many integrations, or must retain consistent governance across environments. Protocol compatibility and operational capability matter as much as architectural preference.

SPIFFE and external custody solve different parts of the problem

SPIFFE provides standards for workload identity, identity documents, and authentication across heterogeneous systems. It does not by itself define which business actions a workload may perform. An X.509 SPIFFE Verifiable Identity Document can support mutual TLS. SPIFFE also supports JWT identity documents, so adopting SPIFFE does not automatically make every token proof-of-possession bound. The selected credential type and verifier behavior matter. SPIFFE overview.

When an agent runtime uses credentials, short lifetimes, audience restrictions, protected keys, and appropriate token binding reduce exposure. Binding a token to a key can prevent someone who steals only that token from replaying it elsewhere. It does not prevent compromised code from using a credential or signing facility that remains accessible within its authorized runtime. Business-action authorization is still required.

External custody changes that boundary. The agent remains an identified principal, but trusted infrastructure authenticates requests attributed to its execution. The guest does not possess the workload token or destination credential. It may know its public identifier; knowing an identifier does not grant authority.

In a design with secure node enrollment, authenticated channels, and trustworthy host-to-workload binding, the governed guest path can operate without SPIFFE. The node can present a short-lived workload token under the enterprise’s established issuer and validation contract. This removes the requirement to distribute an identity credential into each agent guest.

The infrastructure still needs a trustworthy identity system. SPIFFE may be the appropriate choice for nodes, proxies, or federation, including when credentials stay outside guests. Removing guest access to credentials does not make SPIFFE incompatible or unnecessary everywhere. Nor does runtime credential access make SPIFFE the only valid authentication mechanism.

The useful design question is therefore where identity proof occurs and what remains usable after compromise. External custody reduces guest credential exposure. SPIFFE can improve identity interoperability. Either approach needs narrow authority and an enforcement path the agent cannot bypass.

Keep enterprise authority portable

Cloud lock-in can extend to the meaning of identity and authorization rules and the structure of audit evidence. As agents accumulate permissions, delegation relationships, approvals, and investigation history, moving code alone becomes insufficient. A migration must preserve what actions were allowed, why they were allowed, and what the new environment will enforce. Federation establishes trust relationships; it does not establish equivalent authorization controls or evidence.

Cross-cloud access is already possible. Google supports workload federation from external environments, and Azure Arc manages servers outside Azure. These capabilities extend reach; they do not by themselves make provider control planes interchangeable. Google Workload Identity Federation, Azure Arc overview.

An enterprise-controlled authority model defines stable principals, delegation rules, business actions, resource identities, task constraints, approvals, leases, revocation, and evidence. Native IAM and resource services continue enforcing their own protections. Effective permission must satisfy both enterprise requirements and destination controls; an enterprise allow decision cannot override a native denial.

One logical control plane can have distributed enforcement near workloads and resources. It does not require one global gateway, one region, or one credential with access to everything. Teams can operate separate trust domains and retain local administration while sharing explicit enterprise contracts.

Ownership means controlling those contracts, policy decisions, and exit options. It does not require implementing cryptography or operating every service internally. An organization can use managed components, open standards, and replaceable providers while retaining its authority model.

For a focused deployment in one cloud, native controls may provide the best operational trade-off. Preserve stable enterprise identifiers and evidence mappings from the beginning. As workflows span clouds or acquired businesses, a shared authority model can reduce repeated policy work. That benefit must justify the adapter, availability, and security operations it introduces.

The enterprise control plane must itself be replaceable: document contracts, export policy and evidence, and test migration. Otherwise, cloud independence merely transfers dependency to another supplier.

Mediate effects outside the guest

Consider an agent running inside a microVM whose guest may be compromised. The trusted boundary contains the host node, hypervisor, authority services, and integration proxy. The design goal is to prevent guest code from acquiring either credential layer while preserving useful access to approved services.

At admission, trusted services bind an agent, tenant, task, permitted integrations, and authority relationship to a particular execution instance. The node receives only the workload authority assigned to that instance. Guest-supplied headers, workload names, and source addresses must not select another principal’s permission.

The node attributes outbound traffic using host-controlled runtime and network state. Bindings must remain correct through concurrent execution, restarts, migration, and address reuse. The proxy independently checks that the authenticated node is permitted to represent the claimed workload. Trust in a node should not imply authority to impersonate every enterprise agent.

For a supported HTTPS integration, the node terminates the governed TLS connection, removes guest-supplied authentication and routing assertions, and reconstructs the approved request. It supplies the current workload token over an authenticated, protected channel to the integration proxy. The proxy checks current authority, authorizes the actual operation, and applies the destination credential.

Figure 1. External credential custody in a reference execution path. The diagram describes the external-custody option. Public CA trust material may be in the guest; workload and provider credentials remain outside it.

Both credentials remain outside guest memory, files, environment variables, checkpoints, traces, and model context by design. The response path also needs controls: prevent diagnostic echoes, token responses, or credential-management APIs from returning reusable credentials into the guest. A rule about outbound headers alone cannot establish custody.

Mandatory egress must cover browsers, shells, subprocesses, raw sockets, and alternative network paths. Block direct cloud credential metadata access and unapproved destinations. Resolve DNS, redirects, IPv4, IPv6, and connection targets consistently. An SDK convention or optional proxy setting cannot enforce this boundary against malicious guest code.

TLS mediation creates a privileged plaintext observation point. Protect node memory and software integrity, signing and CA keys, telemetry, and tenant separation. Public CA trust material may enter the guest without becoming an identity credential. Certificate-pinned clients, incompatible protocols, and non-HTTP integrations require a supported connector or another enforceable path. Reject unsupported paths rather than silently allowing direct access.

A microVM supplies a separate kernel boundary. Security comes from combining that isolation with lifecycle-safe attribution, mandatory mediation, current authorization, and protected credential custody. The same goals may be implemented with other execution technologies, but equivalent enforcement requires evidence.

Combine short credential lifetimes with current authorization

Within the reference path, one current workload token can carry authenticated identity and references to bounded authority from the trusted node to the enforcing services. Each recipient must be an intended validator under explicit issuer, audience, purpose, and workload-binding rules. Reusing one token is an implementation simplification; its scope and custody determine its security.

The destination still receives the credential it accepts. An enterprise workload token is not a universal bearer for every cloud API, MCP server, or model provider. Crossing a different trust boundary may require appropriately scoped destination authentication while preserving the task’s identity and lineage.

Token lifetime and permission lifetime are separate. An authorization lease defines the actions, resources, validity deadline, renewal conditions, and revocation state governing the work. A valid token cannot revive a revoked lease, and an active lease cannot make an expired token valid. Renewal stays in trusted custody and must recheck eligibility.

A token-family record can connect successive short-lived tokens to the originating actor, represented subject, task, integration, and source authority. Family revocation must prevent both renewal and further governed use within the declared enforcement bound. OAuth token exchange does not automatically supply this lifecycle or propagate every parent revocation to every descendant. RFC 8693.

Authority also needs an explicit mode. User-delegated work must remain within the user’s delegable permissions, the agent’s allowed functions, and the task constraints. Service-owned automation uses an approved service role and separate rules for who can trigger it. A requester’s name in an audit record does not establish either relationship.

Authenticated channels and, where appropriate, sender or workload binding should constrain replay between trusted services. Protect tokens from logging and disclosure. A signature proves a statement’s integrity under an issuer; it does not establish that a requested business operation remains permissible.

Authorize operations and data movement

Keeping credentials outside the guest reduces extraction risk. A compromised agent can still request harmful operations, and a trusted proxy can become a confused deputy when its credential permits more than the task allows. Deny tool operations by default and grant only the actions and resources required for the workflow within its tenant and environment. The enforcing component must check current authority and validate the specific action, target, and arguments.

An allowed hostname or API path is insufficient. GraphQL, RPC, batch requests, and ordinary JSON APIs can place the decisive operation, resource, and arguments in the body. The enforcing component must resolve these into a canonical enterprise action and reject ambiguous or unsupported operations. OWASP GraphQL access-control guidance.

A typed connector, operation-aware proxy, or downstream resource service can perform that enforcement. Name the responsible component for each integration. A generic HTTPS forwarder cannot claim action-level control solely because it validates a destination. Provider credentials should also have the least privilege the integration allows, limiting damage if broker enforcement fails.

Data movement needs comparable precision. Permission to read an incident and permission to create a support ticket must not automatically permit copying the investigation into that ticket. Enforce source access, destination, recipients, data classification, and task purpose. Apply equivalent rules to retrieval, vector search, cached responses, retained memory, and derived summaries.

Model routing must select from policy-eligible destinations before optimizing cost or latency. Fallback, tool discovery, skills, and child agents cannot expand authority. Child work needs explicit delegation, bounded lifetime, ancestor revocation behavior, and trusted attribution to the parent budget. Concurrent reservations must not spend the same remaining allowance repeatedly.

MCP and direct API access should resolve the same integration and authorization relationships. A second interface must not create a parallel credential store or permission bypass. External MCP servers receive authentication valid for their own audience; internal token reuse is limited to intended recipients. MCP security guidance.

These controls constrain what an agent can cause. They do not guarantee correct reasoning or eliminate prompt injection. Malicious content may still distort an investigation or misuse permitted functions. Narrow capabilities, output validation, bounded data access, and appropriate human review remain necessary. OWASP excessive-agency guidance.

Align hosted model versions with replayable execution

Consistent authority needs a consistent, evaluated execution configuration. An agent can retain its permissions while a changed hosted model, prompt, or routing policy alters its tool choices and results. The enterprise control plane should bind each run to an approved, versioned execution manifest and enforce model eligibility at the gateway. This applies to provider-hosted and privately hosted models.

The manifest identifies the resolved model and deployment version, endpoint and API version, inference settings, agent runtime, prompt and tool-schema versions, and routing and fallback policy. Record the model actually used for every call, including retries and fallback. An unchanged endpoint name or moving alias is insufficient evidence of an unchanged model. Where the enterprise operates inference, also retain model, tokenizer, adapter, and serving-image digests and configuration. Where a provider exposes less, state the resulting reproducibility limit.

Retain the actual permitted inputs, retrieved context, model responses, tool observations, and event order alongside the manifest and original authorization decisions. Capture other nondeterministic inputs needed by the runtime.

Treat this evidence as sensitive enterprise data. Minimize collection, exclude credentials, redact sensitive content where required, restrict access, encrypt records in transit and at rest, and enforce retention limits. Protect record integrity and audit access. Record omissions and redactions so investigators understand the resulting replay limits; hashes alone cannot reconstruct deleted content. OWASP logging guidance.

These records support three different capabilities:

Evidence replay reconstructs the observed run and, where the runtime supports it, replays its control flow using recorded model and tool responses. It performs no fresh inference or production effects. Its purpose is to explain what happened and reproduce a failure from retained observations, not expose unavailable internal model reasoning.

Evaluation reruns submit retained inputs to the pinned model or a proposed replacement in an isolated test environment. Compare task completion, tool selection, policy violations, quality, latency, and cost against declared acceptance criteria. Version pinning improves experimental control; it does not guarantee identical generated output. Microsoft’s reproducible-output guidance explicitly notes variability even with matching seeds and backend fingerprints. Microsoft reproducible-output guidance.

Operational retry or resume performs new work and must satisfy current identity, lease, policy, model eligibility, and approval checks. Historical permission cannot authorize a new effect. Preserve idempotency and unknown remote outcomes; a request to replay an investigation must not automatically repeat containment actions.

Treat model upgrades and fallback changes as controlled releases. Evaluate the proposed combination, authorize promotion, record the change, and retain a rollback option while the prior version remains available and eligible. For an incident responder, this means testing whether a replacement still selects the correct host, respects approval boundaries, and completes the investigation effectively. Continuously monitor production behavior against those expectations.

Hosted model retirement limits how long live reruns remain possible; Google publishes model retirement and migration guidance. If the required version disappears, pause or use an explicitly approved replacement and record the change. Preserve evidence replay where retained records allow it, and never label a substitute model an exact reproduction. Google model lifecycle guidance.

This alignment makes agent behavior attributable to a known execution configuration, supports controlled improvement, and helps separate model drift from policy or integration failures. Moving clouds should preserve the manifest, evidence, and acceptance requirements, with any change in model or serving environment made explicit.

Follow one incident through approval and failure

Consider incident INC-482. An analyst authorizes evidence collection and a containment recommendation. Isolating host-884 requires approval. Disabling endpoint protection and exporting the archive to arbitrary destinations are outside the task’s authority.

The evidence-read request succeeds only if current policy permits the specific source and records. If a retrieved email tells the agent to disable protection, the enforcing component rejects that operation even when the model requests it. This illustrates why credential custody and action authorization must work together: a credential-free guest can still issue malicious requests.

For a legitimate isolation request, approval binds the tenant, environment, incident, workload and run, canonical action and tool contract version, exact host, security-relevant argument digest, validity deadline, and intended use. The reviewer sees the actual target and effect derived from the enforced operation, rather than relying solely on an agent-written summary. The system verifies the reviewer’s current authority. Changes to the approved operation require a new decision. Enforce an explicit use limit through an atomic reservation or equivalent control. OWASP transaction-authorization guidance.

The service must bind the approved representation to the operation actually dispatched, with defined canonicalization. DPoP alone does not protect every business argument or provide general request-body integrity. RFC 9449, Section 11.7.

Record the policy version used for each decision, then recheck the lease, current policy, and approval immediately before dispatch. Binding an approval to its original policy version must not bypass a later restriction or revocation. Use target-side versions or conditional operations where available. A remote system may still change between authorization and effect; the design must account for that remaining race.

Now suppose the provider accepts isolation but the response is lost. The recorded outcome is unknown. Retain the intent, approval, dispatch identifier, and uncertainty; reconcile with the provider before retrying a non-idempotent action. A local restart is not evidence that the remote operation failed.

Approval use limits and retry deduplication are separate controls. Idempotency keys require downstream support, appropriate retention, and binding to the caller, tenant, operation, and arguments. A fresh key must not make a consumed approval usable again. Retries must remain tied to the original operation and satisfy current authority and outcome-reconciliation requirements. AWS guidance on safe retries.

If the lease is revoked during recovery, new governed effects must stop within the declared bound. Investigation and reconciliation require their own permitted access. A recovered plan cannot restore withdrawn authority, and terminating the agent cannot necessarily cancel work already accepted elsewhere.

A useful evidence record distinguishes admission, approval, dispatch, provider acknowledgment, and observed effect. This incident is a worked example of required behavior. A deployment claim needs corresponding traces and independently observed outcomes.

Bound the trusted infrastructure and its failure behavior

External custody reduces exposure inside guests while concentrating responsibility in trusted infrastructure. Segment credential stores and integration permissions by tenant, production versus non-production environment, and workload needs. Keep broad provider credentials off execution nodes. Limit node enrollment and token issuance to assigned workloads, and enforce those assignments at the receiving proxy.

A compromised node may misuse the authority of workloads assigned to it. A compromised proxy may misuse the provider credentials it holds. Design these boundaries so one failure does not automatically expose every tenant or integration. Separate high-risk execution pools, protect signing keys, restrict administration, and exercise node removal, key rotation, and recovery.

Current authorization also creates an availability contract. Decide which actions require an online decision and which may use explicitly bounded cached authority. When freshness cannot be established, pause consequential actions that require it. Do not convert a policy-service outage into unrestricted access or silently extend a lease.

Define the maximum age of accepted authorization state and the maximum delay from revocation commitment to denial at every relevant enforcement point. Include caches, queues, partitions, and in-flight dispatch. Short token expiry provides a backstop; it does not prove a tighter revocation bound.

Measure the added request latency and throughput of mediation and authorization under representative load. Test service outages, cold starts, invalidation loss, and recovery. A control plane that meets its security policy only during healthy, low-volume operation is incomplete.

Disconnected on-premises execution needs a deliberate offline policy. Selected low-risk work may use narrow, expiring authority; actions requiring fresh approval must wait. Local execution also does not establish local data residency: model calls, prompts, artifacts, and telemetry need separate destination controls.

Prove consistency before claiming portability

The ideal is the same enforced security requirements across AWS, Google Cloud, Azure, and on premises. That does not mean identical components or identical risk. Each environment has different runtime, network, identity, and service contracts. NIST’s multi-cloud zero trust guidance provides a foundation for applying identity and policy across locations. NIST SP 800-207A.

Moving INC-482 should preserve its enterprise principal, delegation lineage, permitted operations, approval conditions, and evidence history. The new execution instance needs a fresh, trusted binding, and the destination receives appropriate native authentication. Map provider-specific resources, actions, and evidence into the enterprise model while retaining their original meaning and provenance. A common policy vocabulary is insufficient: each environment must demonstrate the required enforcement. Resolve differences before admission; if a destination cannot enforce a required control, restrict the workflow or use another execution path.

Managed services need special attention. If a service continues execution after the initial invocation, its later tool calls must carry trustworthy task attribution and meet the required current-authorization checks. A check at entry alone does not govern every subsequent effect. When a platform cannot expose an adequate enforcement point, restrict the workflow or choose another execution path.

A CCOE can make this practical through a small conformance suite. Record the environment, component versions, policy, workload, fault injected, and observed result for each claim:

Inspection and testing provide evidence within a stated threat model and coverage; a clean scan alone cannot prove universal credential absence. Separate design requirements, documented provider capabilities, and measured deployment results. Record limitations, unsupported paths, and failed tests alongside successful ones. Signed logs authenticate recorded statements; provider records and independent observations strengthen evidence of actual effects.

Begin with one useful workflow. Establish its action semantics, custody boundary, approval and recovery behavior, then validate a second environment before claiming cross-cloud consistency. Expand the supported set only as the evidence supports it.

An enterprise should be able to explain every consequential agent action: who acted, whose authority supported it, where enforcement occurred, and what happened. An enterprise-owned control plane preserves those answers while allowing identity, model, and execution technologies to change.