Agent Security Framework: A Practical Enterprise Guide

Most enterprises don't have a model security problem first. They have an identity problem. A 2025 survey reported that 94.4% of state-of-the-art LLM agents were vulnerable to prompt injection, while 100% were vulnerable to inter-agent trust exploits (agentic AI security survey). An agent that can read private data, call APIs, use OAuth tokens, and hand work to another agent behaves less like a chatbot and more like a non-human employee with delegated authority.

That changes the security design. Prompt filtering matters, but it won't protect an agent whose credentials are over-scoped, whose tool calls aren't independently authorized, or whose runtime activity can't be attributed to a responsible owner. A practical agent security framework must control identity, delegated action, data access, runtime behavior, deployment, monitoring, and response from launch through retirement.

Why Agent Security Needs Its Own Framework

Agent security is first an identity problem, then a governance problem. Traditional AppSec secures code, services, and APIs. LLM security addresses model behavior, prompt handling, and output risks. Identity governance manages users, applications, and permissions. An autonomous agent crosses all three domains, then adds the ability to interpret changing context and take multi-step action without a human approving every step.

That combination creates control gaps with direct business consequences. An agent may receive broad tool access because the permission model was not built for dynamic workflows. Malicious instructions hidden in retrieved content can redirect it toward an attacker-selected action. Credentials, customer records, or internal instructions can also leak through generated output even when the underlying API is protected.

Practical rule: Treat every agent as a non-human identity with an owner, a declared purpose, a capability boundary, and a revocation path.

Runtime authorization must sit at the center of the design. Governance documents can define acceptable use, but only runtime controls can verify which identity is acting, which delegated action is requested, and whether that action remains within scope.

The OWASP GenAI Security Project reached a major milestone in late 2025 with the release of the OWASP Top 10 for Agentic Applications. The peer-reviewed framework defines 10 risk categories, ASI01 through ASI10, for autonomous and agentic AI systems, building on work covering threats and mitigations, threat modeling, secure development, governance, and the agentic security product ecosystem. It recognizes agent security as a distinct discipline rather than a small extension of application or LLM security.

An enterprise program should answer seven questions:

What can go wrong in an autonomous workflow?
Which identity is acting?
Which action is authorized right now?
What data can enter and leave the workflow?
Where does the agent run, and what artifacts does it execute?
What evidence shows normal or abnormal behavior?
How quickly can the organization contain and recover from failure?

These questions turn governance into runtime control over delegated action.

What an Agent Security Framework Actually Covers

An agent security framework is the operating control set for an agent's identity, authorized actions, data access, accountability, and lifecycle. It starts before deployment with ownership and threat modeling, then continues at runtime with session-level authorization, tool boundaries, action logging, and emergency revocation. It also defines what happens when an agent changes, gains new capabilities, hands off work, or reaches retirement.

Traditional AppSec is still necessary. It should secure the code, APIs, dependencies, infrastructure, and deployment pipeline around the agent. LLM security also remains necessary because prompt injection, unsafe outputs, retrieval poisoning, and sensitive-data disclosure can influence the agent's decisions. Neither discipline, however, owns the complete chain from model reasoning to delegated external action.

Use a building analogy. AppSec is the foundation, because it protects the software and infrastructure. LLM safety is the structure and walls, because it constrains inputs, outputs, and model behavior. The agent security framework is the wiring, access panel, and locks that determine who can activate which function, with what authority, under what conditions.

The defining feature is runtime awareness. A policy that says an agent may access a billing system isn't enough. The enforcement layer should evaluate the specific agent, session, tool, target resource, requested operation, data classification, and current risk context before allowing the call.

Every tool call needs a decision

Treat a tool invocation as a distinct authorization event, not as an automatic consequence of the agent's original login. The decision should be logged with the agent identity, session, purpose, tool, requested action, target, policy result, and resulting output.

NIST's AI Risk Management Framework supplies the governance loop around this design. Govern establishes ownership and policy. Map inventories models, tools, connectors, secrets, and delegated privileges. Measure tracks exposure such as identity hygiene and privilege scope. Manage reduces risk through actions including credential rotation, revocation, and permission minimization.

That framework becomes useful only when each governance requirement produces runtime evidence. An inventory should show what the agent can reach. A least-privilege policy should block an unauthorized call. An incident plan should revoke the identity, not merely record that the policy was violated.

The Seven Control Pillars of an Agent Security Framework

A serious program needs more than a review checklist. It needs controls that operate across the agent lifecycle and make delegated action observable and enforceable.

Pillar	Primary Risk	Required Runtime Control
Autonomous threat modeling	Prompt injection, retrieval poisoning, unsafe planning, and cascading actions	Model threats across the agent, memory, tools, data, orchestration, and human handoffs
Non-human identity	Unattributed actions, credential theft, and unclear ownership	Bind each agent to a workload identity, owner, purpose, and short-lived credential
Least-privilege authorization	Over-broad tools and privilege escalation	Evaluate every tool call against resource, operation, session, and policy context
Data protection	Sensitive input, retrieval poisoning, and exfiltration through output	Validate inbound content, classify data, restrict egress, and inspect generated output
Secure deployment	Compromised dependencies, unsafe code execution, and artifact tampering	Isolate runtimes and verify signed model, prompt, connector, and dependency artifacts
Continuous monitoring	Silent drift, abnormal action sequences, and inter-agent abuse	Log actions and outputs, establish behavioral baselines, and alert on deviations
Incident response	Runaway automation and excessive blast radius	Provide circuit breakers, credential revocation, session termination, rollback, and agent-specific playbooks

Threat modeling comes first because an agent's risk depends on what it can do, not only on the model it uses. Map its planning loop, retrieval sources, memory, tool connectors, external communications, and handoff paths. Test how an attacker could move from untrusted content to a privileged action.

Identity must be cryptographic and attributable. Give each deployed agent a stable identity tied to a named owner and workload. Use short-lived credentials rather than reusable secrets, and rotate or revoke them when the agent changes state or an incident begins.

Authorization should be narrower than the tool itself. A billing tool might support reading, drafting, approving, refunding, and deleting, but a support agent may need only read access and a bounded draft operation. Enforce that distinction outside the model.

Data protection covers more than training data. It includes retrieval content, memory, prompt payloads, tool responses, and final output. Validate sources, classify sensitive fields, prevent unsafe cross-domain transfers, and inspect output before it reaches a customer or external system.

Secure deployment requires isolation and provenance. An agent that can execute generated code or load a new connector must do so in a constrained runtime, using artifacts whose origin and integrity can be verified.

Monitoring should capture what the agent did, not just whether the model returned a response. Record tool sequences, unusual targets, repeated failures, data movement, handoffs, and policy denials. Incident response then turns those signals into containment actions.

The Runtime Gap Most Frameworks Miss

Agent security is first a non-human identity problem, then a governance problem. Many programs look complete at design review, yet lose control at the first live tool call. The running agent may still use long-lived API keys, broad OAuth grants, or inherited trust between agents. A policy document cannot enforce delegated action once execution begins.

Agent context changes in runtime. Prompt injection can redirect the requested objective. Retrieved content can insert instructions the developer never approved. A handoff can move work to an agent with a different data boundary. Each event requires a fresh decision about identity, scope, target, and data, not a one-time approval.

Prioritize three controls.

Verify the acting identity continuously

The security layer should confirm which workload is making the request, which session initiated it, and whether the request still matches the agent's declared purpose. Visibility remains poor across deployed agents. A 2025 survey found that only 21% of enterprises had visibility into their AI agents, and 60% hadn't conducted a formal agentic or AI security risk assessment in the previous 12 months (survey findings on agent security visibility). Deny requests from an unknown workload, even when the syntax looks valid.

Identity checks must run at the point of action. Bind the request to the workload, session, approved task, and current credential state before a tool can execute.

Authorize every delegated action

A successful login grants authentication, not unlimited authority. Place a policy decision point before high-risk tools and evaluate every operation against the identity, target, data, and current task. Require explicit approval for sensitive actions, and make denials visible to the response team.

Track behavior separately from authorization. A useful model for agent performance metrics can show failure rates and task outcomes, but those measures do not prove that an action was permitted.

Revalidate inter-agent trust

An agent-to-agent handoff creates a new trust event. The receiving agent must verify the sender, task scope, data classification, and permitted next action. It should receive only the authority required for that handoff, not everything the sending agent could access.

A recent Cloud Security Alliance research note reported that 92% of surveyed large-enterprise CISOs and CIOs lacked full visibility into AI agent identities, while 95% doubted they could detect or contain a compromised agent. The control priority is clear: establish runtime identity, per-action authorization, and handoff validation before expanding autonomy.

A 90-Day Rollout Plan for Enterprise Teams

Don't launch every control at once. Sequence the work so that each wave creates the evidence and enforcement needed by the next one.

Days 1 through 30 focus on inventory and identity

Start with discovery across production and staging. Enumerate agents, owners, models, prompts, tools, APIs, connectors, data sources, credentials, handoff paths, and retirement conditions. Shadow agents count too. If a team can deploy one outside the central inventory, it belongs in the first discovery exercise.

Assign each agent a non-human identity and document its purpose. Bind that identity to an accountable human owner, an operating team, and a defined autonomy tier. Replace shared credentials with workload-specific credentials where possible, then record the permissions that remain.

The deliverables for this wave should include:

Agent register: A current list of deployed and pre-production agents.
Capability map: The tools, operations, data sources, and outbound destinations available to each identity.
Ownership record: A named technical owner and business owner for every agent.
Retirement path: Conditions and procedures for disabling the agent and revoking its access.

Days 31 through 60 add runtime enforcement

Now place policy decision points in front of high-risk tools. Issue scoped, short-lived credentials per tool or session, and make the policy engine evaluate every delegated action. Begin with irreversible actions, sensitive data stores, external communications, and privilege-changing operations.

Capture prompt-injection attempts, suspicious retrieval content, denied tool calls, unusual egress, and suspected data-exfiltration paths. Logging should preserve enough context to reconstruct the decision without storing more sensitive prompt content than the investigation requires.

Days 61 through 90 operationalize response

Add behavioral monitoring, alert routing, incident runbooks, and a compact audit pack. Test credential revocation, session termination, tool blocking, rollback, and owner notification as operational procedures, not theoretical capabilities.

The audit pack should include the inventory record, identity ownership, authorization policies, runtime logs, test results, incident procedures, and approval history. Parallelizing all three waves usually produces incomplete identity records and brittle policy code. Sequencing is itself a security control, because enforcement can't be reliable when the organization doesn't know what exists or who owns it.

Watch on YouTube

Responding When an Agent Goes Wrong

Consider a customer-support agent with access to a retrieval index, account context, and a controlled communications tool. An attacker poisons a retrieved document with instructions that cause the agent to generate a malicious refund link. The link attempts to send a session token to an external destination.

The first signal isn't necessarily a model alert. Identity analytics may detect that the agent has started calling a communication tool in an unusual sequence. The runtime policy engine should then block the off-domain redirect, while output inspection and DLP should detect the token in the outbound payload.

A containment sequence should be explicit:

Block the action: Deny the redirect and prevent further communication through the affected tool.
Revoke the identity: Invalidate the agent's active credentials and sessions.
Preserve evidence: Retain the relevant prompts, retrieved content, tool calls, policy decisions, and outputs.
Quarantine the source: Remove the poisoned retrieval item and prevent its reintroduction.
Notify the owner: Escalate to the named technical and business owners through the incident path.

Response principle: Stop delegated authority first. Investigate the model's reasoning after the identity and tool boundary are contained.

The post-incident work determines whether the organization learns. Revoke and rotate every credential the compromised identity touched, including credentials used during indirect handoffs. Replay the affected transcripts through a red-team harness, test the same poisoning pattern against related agents, and push a revised tool-allowlist rule across the environment.

Update the runbook with the exact detection signal, the policy decision that blocked or missed the action, the data classification involved, and the owner responsible for each recovery step. Teams building AI agent workflow automation should treat these playbooks as part of the workflow design, not as an attachment added by the SOC later.

The threat surface also includes the frameworks used to build agents. In August 2026, a disclosure identified 11 flaws across six major agent frameworks, including insecure deserialization, SSRF, path traversal, and use-after-free issues (coverage of the agent framework flaws). That means response plans must cover supply-chain components and framework updates as well as prompts and model behavior.

Checklist Before You Approve an Agent for Production

Production approval should require evidence, not assurances. A reviewer should be able to retrieve each artifact quickly and determine whether the agent's authority is bounded, observable, and reversible.

Identity

Unique workload identity: The agent has its own identity rather than a shared user or service credential.
Named ownership: A technical owner and business owner accept responsibility for operation and escalation.
Credential lifecycle: Credentials are short-lived where practical, scoped to purpose, and revocable without redeploying the agent.
Autonomy classification: The approval record states what the agent may observe, recommend, or execute.

Tool access

Per-tool scope: Each tool has an explicit resource and operation allowlist.
Runtime decision point: High-risk calls pass through policy enforcement at execution time.
Egress controls: External destinations are restricted, and redirects or data transfers are inspected.
Break-glass authority: A named human can approve or deny exceptional access, with the decision logged.

Data flow

Input validation: Retrieved content, uploaded material, and tool responses are checked before entering the reasoning loop.
Prompt-injection testing: The test record shows how the agent responds to malicious or conflicting instructions.
Output controls: Sensitive fields, tokens, and prohibited destinations are blocked before delivery.
Provenance: The organization can trace important outputs back to their source data and tool interactions.

Auditability and response

Structured action logs: Every tool call identifies the agent, session, requested operation, policy result, and outcome.
Detection coverage: Monitoring identifies abnormal sequences, unusual destinations, repeated failures, and inter-agent trust violations.
Kill switch: Operators can terminate sessions and revoke credentials without waiting for a code release.
Runbook ownership: The response procedure names the people who investigate, contain, communicate, and restore service.
Retirement evidence: Decommissioning removes credentials, connectors, scheduled tasks, and residual access.

The checklist should evolve with the system. As agents gain autonomy, organizations will need continuous authorization, stronger agent-to-agent trust evaluation, policy-as-code for tool selection, and provenance for every delegated action. Guidance on context engineering for agents can improve the quality of the agent's working context, but security approval still depends on enforceable identity and action controls.

Review the gate on a recurring basis and after any material change to the model, tools, data sources, prompts, or handoff design. A previously safe agent can become a different security principal when its delegated authority changes.

Head of Agents provides Agent Readiness Audits, leadership matching, and hiring support for organizations that need accountable ownership of agent programs. Visit Head of Agents to assess your current governance gaps, define the role responsible for runtime security, and build a practical rollout plan.