What Is AI Agent Security? A Practical Guide

AI agent security starts where chatbot security stops

AI agent security is the practice of controlling autonomous software that can plan, call tools and APIs, spend money, retain context, and act without a person approving every step. A chatbot can produce a harmful answer. An agent can turn a harmful or mistaken answer into an external action, which makes identity, authorization, credentials and operational limits part of the security boundary.

Prompt injection remains important, but it is only one failure mode. OWASP also calls out tool abuse, privilege escalation, data exfiltration, memory poisoning, excessive autonomy, cascading failures and denial of wallet. Several of those risks cannot be solved by inspecting prompts. A filter cannot revoke a leaked API key, prove which agent made a call, or stop a request whose cost exceeds a budget unless an enforcement layer sits on the path.

The useful question is not “Which single product secures an agent?” It is “Which layer enforces each control, and what evidence proves it worked?”

Two control planes, with different jobs

A practical architecture separates behavior controls from infrastructure controls. Behavior controls govern what the model reads, decides and emits. They include prompt-injection defenses, memory isolation, tool-argument validation, output filtering, sandboxing and human approval for dangerous actions. These controls need context about the payload and the task.

Infrastructure controls govern what the agent is allowed to reach. They authenticate the caller, resolve its owner and policy, restrict providers, models and endpoints, keep upstream credentials outside the runtime, enforce rate and cost limits, revoke access, and record the decision. These controls should not depend on the model honestly describing its intent. Authorization belongs in deterministic code outside the model loop.

The two planes complement one another. A perfectly authenticated agent can still be manipulated by an indirect prompt injection. A perfectly filtered prompt can still be attached to an overpowered shared credential. Treating either plane as the whole answer creates a blind spot exactly where the other plane begins.

• Behavior plane: prompts, memory, tool selection, outputs and approval workflows.
• Infrastructure plane: identity, scopes, credentials, budgets, revocation and audit evidence.
• Execution boundary: sandboxing, network egress and operating-system permissions.

The minimum control set for a production agent

Start with a named identity for every agent installation. A shared API key tells you that some process possessed a secret; it does not tell you which agent acted. The identity should have an owner, a lifecycle state and an authentication method that is recorded honestly. A long-lived bearer credential and a cryptographic signing key are different assurance levels and should never be presented as equivalent.

Apply least privilege at the destination boundary. Scope access by provider, model and endpoint or tool, not by a broad label such as “AI access.” Enforce the scope before retrieving the upstream credential. Add token, cost, rate, retry and chain-depth limits so a loop or hostile input cannot turn into unlimited spend. OWASP explicitly recommends cost controls and circuit breakers for recursive agent workflows.

Keep provider and service credentials out of prompts, repositories and agent environments. A traditional vault improves storage, but if the agent retrieves the secret it still becomes capable of leaking it. A credential gateway can instead inject the upstream key only after the current request passes identity, revocation, scope and budget checks. The agent receives the result, not the provider credential.

• Unique agent identity and a named human or team owner.
• Explicit provider, model, endpoint and tool scopes.
• Server-side credential use rather than secret delivery to the agent.
• Token, cost, rate, retry and recursion limits.
• Immediate per-agent suspension and credential revocation.
• Structured audit records that identify the real authentication method.

Put enforcement on the request path

Policies that live only in a dashboard or document do not constrain a running agent. The decision point must sit between the agent and the capability it wants to use. For a model gateway, the safe order is authenticate the agent, check kill and suspension state, validate the requested scope, reserve budget atomically, resolve the provider credential, inject it server-side, forward the request, and record the outcome.

Order matters. Retrieving a provider key before authorization increases the number of code paths that can expose it. Charging budget after the provider call lets concurrent requests overspend. Caching a revocable bearer credential without a revocation strategy creates a window where a dead key still works. Security claims should be traceable to these concrete ordering properties, not to a feature list.

A deny decision should terminate before the provider sees traffic. An allow decision should be attributable to one agent and one authentication method. If the system produces a signed receipt, a third party can verify the decision record without needing database access or trusting a screenshot from the operator dashboard.

Authenticate → revoke/suspend → scope → reserve budget → resolve credential → inject → forward → record.

Know what an identity gateway does not solve

An identity and credential gateway is not a prompt-injection detector. It does not know whether a model was socially engineered, whether retrieved text poisoned memory, or whether a tool argument is semantically wise. Those are behavior and execution controls. The gateway limits the blast radius by deciding which capabilities the authenticated agent may reach and by stopping access when policy, budget or revocation says no.

The gateway also sees provider traffic in plaintext while it forwards the request and injects authentication. Any product making this architectural choice should say so. The meaningful privacy promises are narrower: provider keys stay out of the agent runtime, prompts and responses are not written into audit logs, retention is minimized, and self-hosting places the gateway inside infrastructure the operator controls.

Compliance labels are not substitutes for these properties. Encryption at rest, row-level isolation and audit exports matter, but they do not prove that authorization precedes key retrieval or that one agent can be stopped without rotating a fleet-wide secret. Evaluate the enforcement path and failure modes directly.

A deployment checklist you can verify

Before a real agent receives useful access, write down its owner, purpose, authentication method, allowed destinations, budget, review date and off-switch. Test the denial paths, not only the happy path. A security control that has never refused a request is an assumption rather than evidence.

Run a controlled call, then test an out-of-scope model, an exhausted budget, a suspended agent and a revoked credential. Confirm the provider never receives denied traffic. Inspect the audit record and verify that it names the actual agent and authentication method. If receipts are signed, verify one independently using the published key rather than trusting the service that issued it.

PassControl covers the infrastructure portion of this checklist: per-agent identity, scoped model access, pre-flight budget reservation, server-side provider-key injection, layered revocation, audit records and independently verifiable receipts. It does not claim to replace prompt-injection defense, tool sandboxing or human approval for irreversible actions. A production deployment needs both halves.

• Can one agent be suspended without rotating a shared provider key?
• Does an out-of-scope endpoint fail before any credential is resolved?
• Can concurrent calls exceed the stated budget?
• Do logs exclude provider keys, prompts and model responses?
• Can an outsider verify the evidence without dashboard access?