How to secure an AI agent

These systems act at different points in the path from a person or organisation to an external service. Identity is established before the work begins, credentials and tool access are granted when the agent connects, sandboxes constrain the environment in which it runs, and runtime controls assess the request as it reaches the system the agent is trying to use. A decision made at one point does not automatically follow the request through the rest of the path.

Most deployments will use more than one of these systems, but the right place to start depends on the problem in front of you. Managing agent accounts is a different job from keeping OAuth tokens out of a model, while deciding whether a database write is within scope requires control at the point of action.

Most teams will keep their identity provider and the environment in which the agent runs, because those systems remain responsible for account lifecycle and local execution. STACK takes the identity and authority established upstream and carries them through the work the agent was approved to do, tying the credential it uses, the request it makes, the decision to allow or refuse it, the record of what happened and any later revocation back to that authority. The sandbox still constrains the local process and the external service still applies its own permissions, while STACK governs the action as it crosses between them. Requests that bypass STACK remain outside that boundary.

An identity provider is enough when the main problem is account access: signing people and workloads in, issuing tokens, removing access and applying organisation-wide policies. It can tell another system who is making a request, but that identity may still carry permissions far broader than the work an agent was given.

For an agent that performs one narrow task in one internal system, those permissions may be sufficient. Once the agent can choose between tools, use stored credentials or make consequential changes, each action also needs to be checked against its approved work. In these more complex flows, identity alone makes it difficult to show that an agent acting under a particular identity made a specific request under a particular authority, and that the result which followed came from that action. STACK keeps those parts connected by applying the narrower authority given to the agent as the request reaches another system, then recording the decision and result as part of the same chain.

Current work on agent identity draws the same boundary. The OpenID Foundation separates the user who delegates authority from the agent acting on their behalf, then follows that authority through narrower permissions and multi-agent delegation so the final action can be traced back to its origin. NIST has since made the operational problem more explicit: giving an agent an identity does not prevent broad permissions, shared credentials or authorization context from being lost as work crosses systems. These problems remain after identity has been established. OpenID Foundation report · NIST analysis

A credential broker keeps long-lived OAuth tokens and API keys out of the agent’s model context and local files, then injects or exchanges them when the agent connects to an approved service. Some brokers also execute the action and apply policy at the same point, giving the organisation one place to manage service access without handing reusable credentials to the agent.

The remaining question is what the broker authorises. If its policy stops at the service, tool or OAuth scope, a request can be technically permitted even when it does not match the work the agent was given. A token may legitimately allow deletion, for example, without establishing that this agent was authorised to delete this record as part of this task.

Credential brokering is one function inside STACK’s runtime boundary. For a request routed through STACK, the agent’s Passport, the controls configured for the action and the relevant runtime checks are evaluated before the credential is injected. STACK then records the credential use, its decision and the outcome in the same audit chain, while the authority used for subsequent calls can be revoked.

The MCP specification describes its authorization capability as transport-level: it establishes how a client obtains and presents a token to a protected MCP server. That protects the connection, but a valid token does not establish that a particular tool call, its parameters or the sequence it belongs to matches the work the agent was given. MCP authorization specification

An MCP gateway can add more control. Depending on the product, it may restrict available tools, inspect arguments, manage downstream credentials or apply policies before execution. The important question is therefore where its decisions stop: at the server, at the tool, or at the individual action and the authority under which it was requested.

An MCP connection can establish which client has signed into a server, but that does not by itself prove which agent made a later request or whether the request remains within its authority. STACK separates those questions. The MCP client signs in through OAuth, while an enrolled agent can authenticate with its own Ed25519 keypair: the private key remains on the machine, STACK stores the public key, and each API request carries a fresh signed token that expires after 60 seconds. STACK then checks the agent’s Passport and runtime controls before allowing the action, records the decision and its outcome, and can revoke the authority used for later calls.

When an MCP call is routed through STACK, MCP authentication establishes access to STACK while the agent’s Passport and the configured runtime controls determine whether STACK will carry out the requested action. The credential is injected after that decision, and the call, result and any intervention remain connected through the audit and revocation path.

A sandbox limits what an agent can do inside its execution environment, including which files, processes and network destinations it can reach. This is important when the agent runs untrusted code or operates a browser, but a sandbox loses sight of the request once it reaches an allowed external service. If the agent has access to a broad credential, the sandbox cannot tell whether a particular action was authorised, who authorised it or how that authority should change when the agent delegates work.

STACK sits between the agent and those external services. Before releasing a credential or forwarding a request, it checks the identity and authority attached to the agent, the controls set for that action and any relevant runtime signals, then records the decision alongside the resulting activity. A sandbox contains the agent’s execution; STACK governs what the agent can do beyond it.

Identity and permissions establish which agent is acting and which tools or services it may use, but they cannot anticipate every request the agent will produce. An action can use a permitted tool and a valid credential while still departing from the assigned work, perhaps because the agent followed a hostile instruction, delegated beyond its authority or gradually drifted from its original task. Runtime controls compare what the agent is doing with what it was authorised to do while the work is underway.

Current standards work is reaching the same conclusion. NIST’s 2026 agent-security programme considers identification, authorisation, auditing, non-repudiation and protection against prompt injection as connected parts of agent security, while OWASP treats goal hijacking, tool misuse, identity abuse and rogue-agent behaviour as distinct risks that have to be controlled while the system is running. NIST agent identity project · OWASP crosswalk

STACK evaluates each protected action against the agent’s Passport, declared intent and current activity. Depending on the configured mode, a critical signal can block the request, remove sensitive output or revoke the authority used for later calls, while patterns that only become clear across a longer run are recorded for review. Because these decisions share the same identity, credential and audit state, a suspicious action can be traced back through the authority that enabled it.

Ordinary application logs record separate technical events, which is useful for debugging but often insufficient for understanding an agent’s work. A useful audit trail connects the action to the agent that performed it, the person or organisation whose authority it used, the task it was given, the credential and service involved, the decision made by any security control and the resulting response. When one agent delegates to another, that relationship must remain visible so the later action can be traced back through the chain rather than reconstructed from timestamps across several systems.

STACK records protected activity against the same operator, agent and Passport, using trace relationships to connect steps across a run. Credential access, forwarded requests, detector findings, checkpoints and revocations enter the operator’s append-only, hash-chained audit log with their outcomes. This does not reveal a model’s private reasoning, but it shows what the system observed, which authority was active and how one recorded action led to the next.

The same requirements are appearing in standards and regulation. NIST’s 2026 work on agent identity asks how identification, authorisation, auditing, non-repudiation and protection against prompt injection should work together, while Article 12 of the EU AI Act requires high-risk AI systems to record events automatically so their operation can be traced and monitored. NIST agent identity project · EU AI Act

For a mission, session, incident or defined period, STACK can export the relevant signed claims and audit-chain proofs as a self-contained Evidence Pack. The file carries the verification keys and content-hashed schemas needed to check it offline, so a customer, auditor, investigator or insurer can examine the recorded activity without access to the operator’s STACK account. It verifies the signatures, records and relationships inside the pack; it does not claim to reveal the model’s private reasoning or certify the wider system.

Stopping one process may leave active sessions, delegated agents and previously issued authority behind. A useful kill switch must identify the affected authority, prevent it from being used again and invalidate any delegated authority that depends on it, while preserving the records needed to understand what happened before the stop.

STACK lets an operator revoke one Passport, every Passport held by an agent, a session or all active authority across the account. The revocation is written to the live verification path, so the next request checked by STACK is rejected, and revoking a parent also invalidates its delegated children. In a 200-sample test of the Redis-backed path, the median time from revocation to a rejected verification was about 10 milliseconds; production adds the network time between the agent and STACK.

Article 14 of the EU AI Act says that people overseeing a high-risk AI system must be able to intervene in its operation or interrupt it through a stop button or similar procedure that brings it to a safe state. STACK provides the revocation part for activity governed through its runtime boundary. The deployer must still stop the wider agent process and deal safely with any actions that do not pass through STACK. EU AI Act, Article 14

This protection applies wherever STACK performs the verification. A service that verifies a Passport only from its signature must also check STACK’s online verification endpoint or subscribe to revocation events; otherwise it will continue accepting the Passport until its short expiry.

Yes. A team can combine its existing identity provider, secrets manager, MCP gateway, sandbox, policy engine and logging system. Each product can perform its own job well, but the team still has to carry the same account of the agent’s authority through every handoff. The agent identity must survive each step, delegated permissions must only narrow, credential use must remain tied to the task that justified it, and the resulting action must be connected to the decision that allowed it.

These requirements come directly from current work on agent security. NIST’s 2026 concept paper asks how an agent can prove its authority for a specific action, communicate its intent, delegate on someone’s behalf, respond to changing context and bind its actions back to human authorisation through verifiable records. It also treats key revocation and tamper-resistant auditing as parts of the same problem. The OpenID Foundation’s agent-identity report recommends a central enforcement point that interprets delegated credentials, distinguishes the person granting authority from the agent using it, translates that authority for existing services and closes the auditability gap. It says that de-provisioning must propagate across every integrated system rather than stopping at the identity provider. NIST concept paper · OpenID Foundation report

STACK implements that model as one runtime boundary. The agent, its Passport, credential use, runtime decisions and resulting activity share identifiers and one audit chain, while the identity provider, sandbox and other existing infrastructure continue doing their own jobs. The value is greatest once agents can change external systems, work for long periods or delegate to other agents; a simple read-only assistant may not need the full arrangement.