Most AI agent security guidance assumes an enterprise chose, procured, and deployed the agent in question. That assumption holds less often than it used to. This analysis looks at how agents actually enter the estate, which controls can still see them, where they execute, and what that means for identity, runtime, and incident response. It addresses agents that act on enterprise systems through tools and connectors; purely conversational assistants with no write path raise a narrower set of concerns.
What is AI agent security?
AI agent security governs autonomous software actors, their identity, runtime, permissions, and data reach, once they can take action on enterprise systems without a human approving each step. It begins with the inventory, which is usually where the first problem shows up.
Inventory gap in a 5,000-person enterprise
The figures below describe an illustrative mid-size enterprise profile, not a measured population. Treat them as a modeling exercise and substitute your own discovery output; the ratios matter more than the absolute counts.
- SaaS footprint: A discovery pass returns roughly 1,280 third-party products with embedded AI features.
- SSO coverage: About 282 of them authenticate through single sign-on. The other 998 do not.
- Identity mix: Identity holds around 3,400 human accounts and 11,000 non-human identities.
- Review cadence: The architecture review board meets monthly, twelve review cycles a year against a population that changes daily.
- Token scope: In a sample of 500 service tokens issued to agent runtimes, a majority carry write scope to at least one production repository or data warehouse, with median token lifetime measured in months.
The ordering is the point: non-human identities outnumber human ones, most AI-bearing SaaS sits outside federated authentication, and review capacity is periodic while change is continuous.
Why control reach sets the limit
The mechanism is unglamorous. An identity control plane can only govern what authenticates through it. A gateway can only inspect what routes through it. A scanner can only scan what is available to scan.
AI agent security is therefore bounded less by control quality than by control reach, and reach is set largely by how the agent arrived. Three arrival patterns dominate, and they are not equally visible.
Key risks and vulnerabilities in AI agents
Visibility determines which of those arrival patterns a security team can reason about at all, so the risk catalog below applies unevenly across them. The first-party model ran through selection, procurement, deployment, review, and named ownership.
Agents frequently skip those steps. They are inherited inside tools the enterprise already bought, or stood up by a developer in an afternoon, and the vulnerability classes arrive with them.
Prompt injection and indirect prompt injection
Direct prompt injection is a user instructing an agent to ignore its constraints. Indirect prompt injection is more consequential because it needs no cooperating user. Content retrieved by the agent, such as a ticket description, a vendor PDF, or a README in a cloned repository, carries instructions the agent treats as task context.
The agent reads the shared context, writes the code, and opens the pull request. The injected instruction is not a payload a gateway recognizes by signature; it is ordinary text that becomes consequential once an autonomous actor with tool access reads it. No current technique reliably separates instruction from data inside a single context window, which is why injection is treated as a design constraint rather than a solved detection problem.
Detection at the prompt boundary assumes a boundary exists, a point the OWASP agent cheat sheet makes repeatedly in its treatment of untrusted content.
Tool misuse, data leakage, and excessive permissions
Permissions are where agent risk converts into business impact, because an agent with a connector does not request data; it retrieves it.
Common permission failure modes
- Over-scoped connectors: An agent granted workspace-wide read access retrieves documents its requesting user could technically open but never would, then summarizes them into a channel with different membership.
- Tool chaining: A read tool feeds a write tool feeds a messaging tool, producing an exfiltration path no single permission grant describes.
- Memory persistence: Context stored for continuity retains credentials, customer records, and internal plans beyond the session that justified access.
- Standing credentials: Long-lived tokens let an agent act at 3 a.m. with the same authority it held during a supervised demonstration.
Model manipulation and supply chain risks
Model manipulation covers weight tampering, poisoned fine-tuning data, and backdoored adapters pulled from public repositories. The supply chain extends past the model to orchestration libraries, connector packages, and the container images that host the runtime.
Model scanning assumes a model was selected. In the inherited pattern, the vendor selected it, may swap it at the next release, and typically discloses the change in a changelog rather than through a contractual notice. The supply chain is real, the procurement record is not, and the same gap reappears across the full attack surface.
The AI agent attack surface
Mapping that surface requires setting aside the question of origin. Agents reach the enterprise through three launch vectors. Embedded agents ship inside purchased SaaS and often inherit the session of the user who clicked enable. Built agents are assembled internally from a framework, a model endpoint, and a handful of connectors. Inherited agents arrive through platform defaults, where an existing vendor activates agentic features across tenants.
Conventional controls tend to see the built ones reliably, the embedded ones partially, and the inherited ones least of all. Three launch vectors, one destination: all of them execute in a runtime, hold a token, reach a data store, and act on a system of record.
User inputs, prompts, and memory
The input surface is larger than the chat box. System prompts, retrieved documents, tool outputs, and persisted memory all enter the same context window with no inherent trust separation. An agent that read a poisoned document on Tuesday may act on it Thursday, because memory outlives the session.
Treat memory as a storage system with classification requirements, not as a convenience feature. What an agent remembers is data the enterprise now holds, in a location the data map usually omits.
Connected tools, APIs, and third-party services
Connectors turn context into action, and vendor marketing is often explicit about it. The recurring claim, paraphrased across several product launches, is that agents work with the permissions a user already has, so nothing new needs configuring. Read operationally, that framing describes an autonomous actor with reach into the repository, the ticketing system, and the warehouse, provisioned without a request, a ticket, or an owner.
In that path, nobody approved a deployment and nobody filed an exception. An acceptable-use policy assumes there was an adoption decision to govern. There was little to instrument, because nothing was formally adopted.
Agent-to-agent communication and runtime environments
Multi-agent systems compound this by making one agent's output another agent's instruction. A production chain is typically short and consequential.
Multi-agent execution chain
- Trigger: A webhook or scheduled job wakes a planner agent inside a container with a mounted service token.
- Delegation: The planner dispatches subtasks to specialist agents over an internal protocol, which in many default configurations lacks mutual authentication.
- Retrieval: A specialist queries the warehouse and returns rows into shared context.
- Action: A second specialist writes to the repository and opens a pull request under a bot identity.
- Persistence: The result is cached as memory and reused on the next invocation.
Each hop is individually legitimate. The composite is an unreviewed privileged workflow, which is what the following practices are meant to constrain.
AI agent security best practices to implement
Constraining that workflow is where AI agent security best practices earn their keep, provided they target the runtime rather than a procurement record that may not exist. Prevent where the action is irreversible; detect where prevention would break legitimate work. Controls that only produce findings about an agent that already wrote to production are describing history.
Apply secure-by-design principles and threat modeling
Threat modeling for agents differs from application modeling in one respect: the attacker's entry point is often content rather than traffic. Model the agent as an identity with goals, not as a service with endpoints.
Agent threat modeling steps
- Capability inventory: Enumerate every tool, connector, and credential the agent can invoke, including transitive reach through other agents.
- Intent definition: Record creator intent in machine-readable form, stating the tasks, data domains, and systems the agent is authorized to touch.
- Abuse path tracing: Walk each capability chain to its worst legitimate outcome, assuming untrusted content enters context.
- Blast radius sizing: Quantify what a single compromised invocation can read, write, or delete before any human notices.
- Enforcement placement: Decide where in the runtime the chain can be stopped, not merely logged.
Limit agent autonomy with guardrails and human approval
Grade autonomy by consequence rather than by model confidence scores, which are poor proxies for correctness. Read-only retrieval in a non-sensitive domain can reasonably run unattended. Writes to systems of record, financial movements, permission changes, and external communications warrant an approval step that a person actually sees in their normal workflow.
Approval fatigue is the predictable failure mode. If every action prompts, operators approve reflexively and the control becomes theater. Set thresholds on irreversibility and reach, then enforce them in the runtime so an agent cannot route around the gate by choosing a different tool.
Validate inputs, outputs, and tool calls
Validation belongs at three points in the execution path, each asking a different question. None of the three is individually sufficient against a determined injection; they are layered to reduce the chance that one bypass reaches a write.
Three validation checkpoints
- Input provenance: Tag retrieved content by source trust level and strip or quarantine instruction-like text arriving from external documents, tickets, and web pages.
- Output constraint: Check generated content against data classification before it leaves the boundary, including summaries that compress restricted records into unrestricted channels.
- Tool call authorization: Evaluate each invocation against declared intent, so a call that is syntactically valid but outside the agent's stated purpose is refused at execution.
The third check depends entirely on whether the agent has a verifiable identity, which is the next structural problem.
Authentication, authorization, and access controls
Verifiable identity is what makes tool call authorization enforceable rather than advisory. In the first-party model, identity was assigned during deployment. Agents do not reliably arrive that way. They frequently operate under a human's session, a shared bot account, or a service principal created by a framework with defaults nobody reviewed.
Use strong identity verification for users and agents
An agent acting under a user's session is difficult to distinguish from the user in downstream logs. That design choice erodes attribution, and attribution is the precondition for both access control and investigation.
Give each agent a distinct non-human identity with its own lifecycle: issued at creation, bound to a workload, and revoked when the agent is retired. Workload identity standards such as SPIFFE exist for the binding problem, though coverage across SaaS-embedded agents remains limited. Preserve the human principal separately as the accountable owner, so the record shows which person authorized an autonomous actor and which actor performed the write.
Enforce least privilege and scoped credentials
Least privilege for agents means scoping to the task, not to the role of the person who launched it.
Scoping controls for agent credentials
- Task-scoped grants: Issue permissions for a specific dataset, repository, or queue rather than for a workspace or project.
- Time-bound tokens: Replace multi-month service tokens with short-lived credentials tied to a single invocation window.
- Separated read and write paths: Keep retrieval identities distinct from action identities so a poisoned context cannot escalate directly into a commit.
- Default deny on new tools: Treat connector addition as a privilege change requiring explicit grant, not as configuration.
How far these can be applied depends on the platform; several SaaS products expose only coarse, tenant-level permission models for their embedded agents.
Protect secrets, tokens, and API keys
Secrets reach agents through environment variables, mounted files, and context windows, and the last of these is the novel exposure. A key placed in a system prompt is a key in memory, in logs, and potentially in a model provider's retention window, depending on the provider's stated data handling terms.
Keep credentials out of context entirely. Broker access through a runtime component that holds the secret, performs the call, and returns only the result. The agent gets the capability without ever holding the material, which also makes revocation immediate and observable.
Monitoring, incident response, and compliance
Immediate and observable revocation only matters if someone can see the action that justified it. Agent telemetry is thinner than application telemetry by default, because the interesting event is a decision, and decisions are not emitted unless the runtime is instrumented to capture them.
Runtime observation fills part of that gap by watching execution rather than relying on intent declarations. Vendors working in or adjacent to this space include Sweet Security, Aqua Security, HiddenLayer, Lakera, Prompt Security, Protect AI, and Noma; the list is not exhaustive, capabilities differ substantially, and the category is young enough that independent comparative evaluation is scarce.
Log agent decisions, actions, and tool invocations
A usable agent record captures the invoking principal, the agent identity, the prompt and retrieved context, every tool call with parameters, the credential used, and the downstream effect. Without the context, an investigator sees a legitimate API call and no reason for it. Logging prompts and retrieved content also creates a new sensitive data store, so retention and access limits belong in the design.
Behavioral drift detection sits on top of this record, comparing observed action sequences against the agent's declared purpose. Drift signals that an agent is doing something its creator never described, sometimes compromise and sometimes scope creep, and the two are hard to separate without the owner's input.
Build an AI agent incident response plan
Agent incidents can progress faster than human-driven ones and leave different evidence.
Agent incident response sequence
- Containment: Revoke the agent identity and its tokens, which stops action without requiring the runtime to be located first.
- Scoping: Replay the invocation log to determine which data was read and which systems were written.
- Context forensics: Identify the injected content, including the document, ticket, or repository that introduced it.
- Memory purge: Clear persisted context so the agent does not resume the poisoned task after restoration.
- Owner notification: Reach the accountable human recorded at creation, not the generic platform team.
Steps two through four assume the logging described above is already in place; without it, scoping reduces to reconstructing intent from downstream system records.
Map AI agent security controls to compliance requirements
Compliance frameworks already demand access control, logging, change management, and data classification. Agents mostly add new subjects to those existing obligations, and auditors increasingly ask who approved a non-human identity with warehouse write access. The EU AI Act and the NIST AI Risk Management Framework add governance expectations on top, with applicability depending on jurisdiction, use case, and risk tier.
Map each agent control to the obligation it satisfies: identity issuance to access management, intent declarations to change management, invocation logs to audit evidence.
The underlying architectural fact is simpler than the frameworks. Many enterprises now run an execution layer with no fixed edges, where systems nobody formally selected hold credentials nobody deliberately issued and act on data nobody classified for that purpose.
