Your AI Agent Should Never Hold the Root API Key

An AI agent should receive permission for a specific operation, not possession of a credential that can authorize every operation. Keep the root API key—or any similarly broad, reusable credential—outside the model and execution environment, then broker narrow access only after each requested action passes policy.

This preserves delegated tool access without making the agent a superuser. The model proposes an action; trusted components authorize it, issue or inject limited credentials, execute it inside a constrained boundary and record the result. Identity, authorization, execution and credential brokering are separate controls, not features of one all-powerful agent process.

Draw the boundary around the credential

The threat is broader than a deliberately malicious model. Prompt injection in a file or webpage, poisoned tool output, model error or a compromised dependency can influence the next action. If the same environment holds a production-wide key, a planning failure can become an authenticated API call or disclosure of reusable authority.

Removing a key from the prompt does not remove it from the agent’s reach. A credential stored in a readable environment variable, configuration file, mounted home directory, process argument or debug log remains inside the compromised boundary. Store root credentials in a secrets service or broker that the model and its general-purpose tools cannot read or enumerate.

The resulting threat model has four boundaries:

• Untrusted planning: the model, retrieved content, tool responses and generated commands.
• Constrained runtime: schema validation, local limits and task state, with no root secrets.
• Trusted control plane: workload identity, policy decisions, approvals and credential brokering.
• Resource: the downstream API, which validates the presented grant and records the operation.

Separate identity, authorization, execution and brokering

Give each agent instance a workload identity and retain the identity of the human, service or workflow delegating the task. Authentication establishes who is acting; it must not create standing authority over every resource available to the delegator.

Evaluate authorization for each consequential tool call using the agent, delegator, task, requested capability, target resource and relevant limits. The policy component can allow, deny or require approval, but it should neither execute the operation nor disclose the upstream credential.

A separate executor should accept typed operations rather than arbitrary authenticated requests: “set this ticket to the approved status,” for example, rather than “send any HTTP request to the CRM.” The broker then supplies only the credential needed for that approved call. Auth0’s permission-model analysis likewise separates identity, per-operation authorization and execution, and describes a runtime that brokers credentials instead of exposing them to the LLM process.

This also explains why enterprise agent identities are necessary but insufficient: an identity makes attribution possible, while policy and execution controls determine what that identity can actually do.

Exchange authority for a task-scoped grant

A reference flow should expose every point where access can be denied:

1. The caller creates a task with an immutable ID, purpose, expiry and maximum permitted capabilities.
2. The model proposes a structured tool call without receiving a root key or refresh token.
3. The runtime validates the schema, arguments, target and current task state.
4. The policy service evaluates the exact operation and requests bound approval when its risk exceeds a defined threshold.
5. The broker issues or obtains a short-lived grant restricted to the approved audience, resource and scope.
6. The executor presents the grant to the downstream API and discards it after use.
7. Control-plane, executor and resource events are correlated by task and decision IDs.

Reference flow: caller grant → agent plan → runtime validation → policy decision → credential broker → constrained executor → tool API. Only the operation-specific grant enters the execution path; the reusable credential remains in the control plane.

OAuth 2.0 Token Exchange defines a standard protocol for exchanging subject and optional actor tokens and lets a client request a token for specified resources, audiences and scopes. It does not by itself provide task binding, one-time use, short expiry or automatic propagation of later revocation; those properties require deployment-specific policy and enforcement.

Constrain the filesystem and network

Credential brokering limits secret exposure, but it does not contain arbitrary code or data access. Run each task, tenant or risk domain in an isolation boundary appropriate to the threat model. Use a non-root account, remove unnecessary operating-system capabilities, limit processes and memory, and discard writable state when the task ends.

Mount only the inputs required for the job. Prefer read-only source mounts and a small task-specific writable area; exclude home directories, cloud configuration, SSH material, package-manager credentials, environment files and host sockets. Repository changes can be written to a disposable worktree and promoted through a separate review path.

Apply default-deny egress and route permitted traffic through a gateway that validates the destination, method and request shape. A domain allowlist alone may be insufficient when an allowed service can redirect traffic or initiate secondary requests.

Anthropic’s secure deployment guidance recommends security boundaries, least privilege, filesystem and network restrictions, and an external proxy that injects credentials and logs requests. The implementation examples are product-specific, but the underlying rule is vendor-neutral: secrets and request enforcement stay outside the environment that processes untrusted instructions.

Test failure, revocation and audit evidence

A short-lived token remains useful to an attacker during its valid window. Restrict it to one audience and the smallest practical capability, reject changed arguments at the executor, prevent replay of destructive operations and require a new decision when the plan changes. Where a downstream API accepts only a broad static key, expose a narrow gateway operation instead of arbitrary authenticated pass-through.

Fail closed if identity, policy, approval or audit dependencies are unavailable. Do not silently substitute a service superuser, reuse an allow decision outside its task or retry with broader scopes. Separate broker administration from runtime administration so control of the executor does not imply control of stored credentials.

Verification should cover denied and interrupted paths:

• Place a harmless instruction in test content asking for credentials or environment variables; confirm the agent cannot retrieve them.
• Change the approved resource, method or argument; confirm rejection at the runtime and again at the gateway or resource API.
• Revoke delegation during a multi-step task; confirm the next exchange fails and document the maximum period for which an already issued token can remain valid.
• Replay a completed operation or present its token from another task, executor or audience; confirm rejection.
• Trace one operation across identity, policy, approval, issuance, execution and resource records using stable correlation IDs.
• Confirm logs contain the actor, delegator, policy version, requested capability, target, decision and result—but no bearer token or root secret.

The architecture passes its central test when compromise of the model process yields neither a reusable credential nor an unrestricted route to a protected API. The agent can propose work, but effective privilege remains narrow, externally granted, independently enforced, short-lived and observable.

Also read:

• Hush Security Raises $30M to Give Every Enterprise AI Agent an Identity
• Why Should You Always Finish Reading Difficult Content?
• How Should SEO Form Part of Your Inbound Marketing Strategy?