AI agent security: the complete 2026 guide and checklist

The short answer: secure the action, not only the model

A secure AI agent has a defined job, a distinct identity, minimum permissions, trusted tools, protected data, deterministic policy checks, useful logs, and a tested stop path. The model may interpret information and propose an action. Code outside the model decides whether that action is allowed, whether a person must approve it, and what evidence is retained.^[1][4][5]

This distinction matters because an agent is more than a chatbot. It can retrieve records, call APIs, use Model Context Protocol servers, write to business systems, communicate externally, or execute code. Every added capability creates a new path from untrusted input to a real consequence. Security therefore has to cover the whole agent loop, not only prompts and responses.^[1][6]

• Know every agent, owner, data source, tool, destination, and credential.
• Separate reasoning from permission and permission from execution.
• Treat retrieved content and tool output as untrusted by default.
• Gate high impact actions and make every consequential action traceable.
• Test normal work, edge cases, attacks, failure, recovery, and shutdown.

Why AI agent security is different from chatbot security

A chatbot mainly creates content. An agent combines a model with memory, tools, credentials, workflow state, and some degree of autonomy. A wrong answer is still a quality problem, but a wrong tool call can disclose a file, alter a customer record, send a message, run code, or trigger a payment. The relevant measure is no longer only response accuracy. It is the possible blast radius of a mistaken or manipulated action.^[1][10][13]

Traditional application security still applies: secure code, patched infrastructure, strong authentication, encrypted transport, secret management, network controls, backups, and monitoring remain essential. Agent security adds a second layer for probabilistic decisions, instructions hidden in data, changing context, delegated authority, tool selection, persistent memory, and multi step behavior.^[5][14]

• Model risk: incorrect, manipulated, or policy violating output.
• Context risk: malicious or misleading instructions inside retrieved content.
• Authority risk: excessive credentials, scopes, tools, or destinations.
• Execution risk: an unsafe proposal reaches a real system without enforcement.
• Operational risk: loops, cost spikes, cascading errors, weak logging, or no recovery.

Use the OWASP Agentic Top 10 as a threat map

OWASP’s Top 10 for Agentic Applications for 2026 provides a useful map of the highest impact agent risks: agent goal hijack; tool misuse and exploitation; identity and privilege abuse; agentic supply chain vulnerabilities; unexpected code execution; memory and context poisoning; insecure inter agent communication; cascading failures; human agent trust exploitation; and rogue agents.^[1]

Do not turn the list into ten isolated checkboxes. One event can cross several categories. A malicious instruction inside a document may redirect an agent, cause it to misuse an approved tool, write poisoned memory, and persuade a reviewer to approve the result. Threat modelling should follow the full path from influence to consequence and identify the controls that interrupt it.^[1][2]

• Influence: who or what can place content in the agent context?
• Authority: which identities, scopes, tools, and systems can the agent use?
• Consequence: what can be read, changed, sent, executed, deleted, or purchased?
• Persistence: can poisoned context survive in memory, files, indexes, or configuration?
• Propagation: can one agent, tool, or bad result influence other workflows?

Start with an agent inventory and a risk tier

You cannot secure agents that nobody has recorded. Maintain a registry for production, experimental, vendor supplied, desktop, and embedded agents. Each entry should name a business owner and technical owner, purpose, environment, model, data classes, tools, credentials, user population, deployment location, autonomy level, and last review date. Discovery also needs to find shadow agents and unapproved MCP servers, not only systems built by the central team.^[4][8][12]

Assign risk from capability and consequence. A read only assistant using public information is not equivalent to an agent that can access payroll, change customer records, execute code, or communicate outside the company. Risk tiering determines the required review, testing depth, approval policy, monitoring, and incident readiness.^[5][6]

• Tier 1: public or low sensitivity data, no write access, no external action.
• Tier 2: internal data with bounded retrieval, drafting, or recommendations.
• Tier 3: approved write actions in business systems with limited consequence.
• Tier 4: sensitive data, code execution, finance, security, identity, or external authority.
• Increase the tier when several individually narrow permissions combine into broad power.

Map the architecture and its trust boundaries

Draw the actual path from the user request to the business outcome. Include the user interface, identity provider, orchestrator, system prompt, model endpoint, retrieval layer, vector store, memory, MCP clients and servers, ordinary APIs, queues, approval service, policy engine, execution service, logs, analytics, backups, and administrative access. Mark where data changes owner, environment, region, sensitivity, or trust level.^[5][12][14]

The strongest pattern is to separate interpretation from enforcement. The model can classify intent, extract fields, select from approved options, or prepare a proposed action. A deterministic control layer validates the user, agent, policy, tool, parameters, destination, data class, budget, and approval before execution. A system prompt can explain a boundary, but it should not be the boundary.^{[2][4][9][10]}

• Document inputs, outputs, stores, identities, network paths, and external providers.
• Label untrusted content before it reaches the model or another agent.
• Place policy checks immediately before sensitive tool calls.
• Use schemas, parameter validation, allowlists, and transaction limits.
• Design read only, dry run, and isolated test modes from the beginning.

Give every agent an identity and delegated authority

Every production agent or bounded workflow should have a distinct non human identity. Preserve the identity of the user who initiated the work and the identity of the agent that performed it. Avoid shared human logins and broad service accounts. They remove attribution, make revocation difficult, and allow one compromised workflow to inherit the authority of unrelated systems.^[7][8]

Authorization should follow the task, user, resource, action, and moment. Prefer short lived credentials, narrow scopes, just in time elevation, and separate permissions for reading, drafting, writing, sending, deleting, and administering. When an agent acts for a person, propagate that person’s permissions where appropriate instead of silently converting the request into a powerful backend identity.^{[7][8][12][15]}

• One identity per production agent, environment, and meaningful trust boundary.
• Named business owner, technical owner, purpose, expiry, and review schedule.
• No secrets in prompts, source code, long term memory, or ordinary logs.
• Immediate revocation for the agent without disabling unrelated workflows.
• Periodic access review and automatic removal of unused permissions.

Design for prompt injection and goal hijack

Prompt injection occurs when external content contains instructions intended to redirect the model. It may arrive through a webpage, document, email, database field, support ticket, image, tool response, or another agent. Direct injection comes from the user. Indirect injection is embedded in content the agent retrieves while doing legitimate work. The second form is especially dangerous because the content can look like ordinary business data.^[1][10][13]

There is no reliable single filter that makes prompt injection disappear. OpenAI describes the problem as closer to social engineering than simple string detection and recommends limiting the impact even if manipulation succeeds. Defences should combine instruction hierarchy, content labelling, model and classifier safeguards, source to sink analysis, least privilege, tool restrictions, destination controls, approval, sandboxing, monitoring, and continuous adversarial testing.^[9][10][13]

• Never let retrieved content grant itself new permissions or tools.
• Do not mix untrusted text with secrets the task does not require.
• Block silent transfer of sensitive data to new or unapproved destinations.
• Require confirmation for consequential actions with clear source evidence.
• Assume some attacks will bypass detection and constrain the resulting impact.

Secure tools, APIs, MCP, code, and the supply chain

Tools turn model output into capability. Keep the tool set small, separate low risk retrieval from high impact execution, and expose only the operations required for the current stage. Validate every argument outside the model. Treat tool descriptions, schemas, packages, skills, connectors, server updates, and tool responses as supply chain inputs that can be changed, spoofed, or poisoned.^[1][2][3]

For remote MCP, follow the current authorization specification rather than passing general bearer tokens through the chain. Bind tokens to the intended resource, validate audience and issuer, use protected resource and authorization server metadata, protect redirect flows, apply PKCE where required, store tokens securely, and use separate downstream credentials. A user approving one MCP server should not silently authorize unrelated services.^[3][11]

Code execution deserves its own boundary. Run it in a sandbox with a minimal file system, network egress allowlist, resource limits, isolated secrets, non privileged user, disposable state, and explicit timeouts. Treat generated commands, package installation, deserialization, and dynamic evaluation as hostile until validated.^[1][2][10]

• Allowlist tools and actions by workflow stage, not only by agent name.
• Pin and review dependencies, server owners, manifests, and version changes.
• Require stronger approval for send, publish, pay, delete, permission, and code actions.
• Apply rate, spend, recursion, concurrency, and transaction limits.
• Monitor new tools, changed descriptions, unusual scopes, and new destinations.

Protect data, retrieval, memory, and secrets

Map every copy of sensitive information: source records, prompts, model inputs, outputs, embeddings, vector indexes, caches, memory, traces, analytics, error reports, backups, and support access. Define the purpose, location, encryption, retention, deletion, and administrators for each store. A private interface is not a private architecture when logs or retrieval data leave the intended boundary.^[8][14]

Retrieval must enforce the same tenant, user, role, and document permissions as the source system. Filter before retrieval where possible, verify again before presenting or acting, and test for cross tenant leakage. Do not assume embeddings are harmless metadata. They can reveal relationships and may reproduce sensitive content through retrieval.^[8][14]

Memory is both useful and persistent attack surface. Separate task state from long term memory, record provenance, limit who can write, expire stale entries, and require review before untrusted content becomes durable policy or preference. Secrets belong in a managed vault and should be injected only at the execution boundary, never exposed to the model unless strictly necessary.^[1][14]

• Classify data and minimise what enters the model context.
• Redact or tokenise unnecessary personal and confidential information.
• Track provenance and integrity for documents, indexes, memory, and updates.
• Prevent one customer, workspace, or department from retrieving another’s context.
• Verify deletion across primary storage, indexes, caches, logs, and backups.

Enforce policy inside the runtime loop

Policy must sit in the path of execution. Inspect the request before the model, the proposed tool call before it runs, and the tool response before it returns to the agent or becomes memory. This lets the system block an unsafe action even when the model has been manipulated. OWASP’s 2026 Agent Control Standard similarly emphasises inspectable, traceable, and instrumentable agents with portable runtime controls.^[4][9]

Runtime decisions should use facts the model cannot redefine: verified identity, data classification, tool risk, destination, action type, transaction value, time, location, previous approvals, and rate. Start new controls in audit mode when appropriate, study false positives and missed cases, then enforce them for clearly defined high risk paths.^[4][9]

• Pre model: authenticate, classify, rate limit, and separate trusted instructions from data.
• Pre tool: validate permission, parameters, destination, policy, budget, and approval.
• Post tool: inspect returned content before reuse, display, storage, or memory.
• Post action: record outcome, detect anomalies, and verify expected state change.
• Independent controls must fail closed for high impact actions.

Put human approval at the consequence boundary

Human review is valuable when an action is difficult to reverse, affects rights or money, changes access, communicates externally, deletes data, executes code, or operates with low confidence. It is wasteful when applied to every harmless step. Let automation collect, classify, draft, and prepare evidence, then ask for approval at the point where consequence begins.^[1][13]

The approval experience must show the exact proposed action, affected object, destination, source data, reason, policy result, important uncertainty, and available alternatives. Generic approve buttons create automation bias and reviewer fatigue. Use expiry, separation of duties for the highest risks, and an edit or reject path. Never allow an agent to approve its own exception.^[1][2]

• Automatic: low risk, reversible, well tested actions inside a narrow scope.
• Confirm: sensitive communication, new destinations, purchases, deletion, or access changes.
• Dual review: material finance, security, legal, or identity consequences.
• Escalate: ambiguous requests, policy conflict, missing evidence, or unusual behavior.
• Expire approval when the underlying data, action, policy, or time window changes.

Make actions observable and auditable

A useful trace answers: who asked, which agent acted, which policy and version applied, what data and tools were used, what the model proposed, what was approved, what executed, what changed, and whether the result succeeded. Preserve correlation IDs across the user request, model call, retrieval, tool call, approval, and downstream API so an investigation can reconstruct one event without searching disconnected systems.^[4][7][8]

Logging must not become a second data breach. Minimise and redact sensitive content, restrict log access, encrypt it, protect integrity, set retention, and keep the agent from altering its own audit record. Alert on unusual destinations, denied actions, repeated retries, tool or scope changes, large exports, abnormal volumes, off hours access, rising cost, and deviations from the workflow baseline.^[8][9][14]

• Security metrics: denied actions, injection signals, privilege use, anomalies, and incidents.
• Reliability metrics: success, exception, retry, duplicate, timeout, and recovery rates.
• Human metrics: approval, rejection, edit, override, and reviewer response time.
• Business metrics: cycle time, quality, conversion, cost, and customer outcome.
• Version every prompt, policy, model, tool schema, and evaluation set.

Test the whole agent before production

Model evaluations are necessary but insufficient. Test the complete system with the real permission model, retrieval layer, tools, policy engine, approval path, network boundary, logging, and rollback. Build evaluation cases from normal work, historical failures, rare exceptions, ambiguous requests, malicious content, unavailable dependencies, slow responses, duplicate events, and partial execution.^[5][12][14]

Adversarial testing should cover direct and indirect prompt injection, data exfiltration, tool misuse, permission escalation, tool description changes, poisoned memory, cross tenant retrieval, insecure inter agent messages, infinite loops, resource exhaustion, unsafe code, manipulated approvals, and attempts to disable logging or the stop mechanism. Rerun the suite when the model, prompt, tools, memory policy, data sources, permissions, or workflow changes.^{[1][2][3][10]}

• Unit tests for deterministic validators, policies, and tool wrappers.
• Workflow tests for state transitions, retries, idempotency, and rollback.
• Security tests for each source to sink path and OWASP agentic risk.
• Human tests for clear approvals, warnings, escalation, and recovery.
• Production canaries and staged rollout before broader authority.

Deploy with change control and continuous assurance

Treat prompts, policies, tool schemas, MCP servers, models, retrieval sources, and memory behavior as production dependencies. Keep them versioned, reviewed, tested, and reversible. Separate development, test, and production identities. Use signed artifacts and provenance where possible, scan dependencies, protect the deployment pipeline, and require review for changes that expand data access or authority.^[1][5][14]

Release autonomy in stages. Begin with observation or read only work, then drafting, then bounded writes, and only then carefully selected independent actions. Compare each stage with a manual baseline and define an exit condition before expansion. A newer model or successful demo is not evidence that every connected action is safe.^[5][12]

• Record the approved purpose and prohibited outcomes before launch.
• Use feature flags for tools, destinations, memory, and autonomous actions.
• Canary releases with narrow users, data, volumes, and permissions.
• Require fresh tests for any change that affects behavior or authority.
• Maintain a manual path for critical work and rehearse restoration.

Prepare incident response and a real kill path

Before launch, define what counts as an agent security incident, who receives the alert, who can pause the system, which identity or tool can be revoked, how evidence is preserved, how affected data and systems are identified, and how stakeholders are informed. The fastest safe response may be to switch one workflow to read only or approval only, not shut down every automation.^[5][8][9]

A kill switch must operate outside the agent and be tested under failure. Containment options include disabling the agent identity, revoking tokens, blocking a tool or destination, freezing memory writes, isolating a queue, stopping code execution, lowering rate limits, or routing all actions to manual review. Recovery should verify clean configuration and data, rotate credentials, rerun security tests, and require explicit authorization before reconnecting production systems.^[1][4][8]

• Detect: alert on high impact anomalies and control failures.
• Contain: pause the smallest affected boundary and revoke its authority.
• Preserve: protect traces, approvals, versions, tokens, and downstream records.
• Recover: restore trusted state, test controls, and reintroduce access gradually.
• Learn: update the threat model, tests, policy, owners, and runbook.

Ask vendors questions that expose the real boundary

A vendor saying enterprise grade, private, compliant, or secure does not describe your architecture. Ask for specific data flows, subprocessors, regions, retention, training use, administrator access, encryption, tenant isolation, identity integration, audit events, model and tool changes, testing evidence, incident notification, deletion, export, backup, and service exit procedures.^[5][12][14]

For agents, add questions about tool permissions, MCP servers, credential handling, prompt injection controls, memory, human approval, policy enforcement, observability, kill mechanisms, and who is accountable for third party actions. Verify answers in contracts, technical settings, logs, and tests. A policy page cannot compensate for a control that is absent from execution.^[3][4][8]

• Can our data be used for training, evaluation, abuse monitoring, or product improvement?
• Which people, systems, regions, and subprocessors can access each data class?
• Can we restrict tools, scopes, destinations, retention, and model versions?
• Can we export a complete trace and revoke one agent immediately?
• How are security changes, incidents, deletions, and service termination verified?

The practical AI agent security checklist

Use this as a release gate, not a promise that risk has disappeared. Mark each control as implemented, tested, evidenced, owned, and scheduled for review. Any item that affects a high impact action should have technical proof rather than a statement of intent.^[1][2][5]

• Purpose: the job, owner, users, prohibited outcomes, and success metric are written down.
• Inventory: model, data, tools, MCP servers, credentials, stores, providers, and versions are recorded.
• Identity: the user and agent are attributable; credentials are narrow, short lived, and revocable.
• Architecture: trust boundaries and source to sink paths are mapped; enforcement sits outside the model.
• Prompt injection: retrieved content is untrusted; sensitive actions remain constrained if detection fails.
• Tools: actions and parameters are allowlisted, validated, rate limited, monitored, and isolated by risk.
• MCP: tokens are audience bound, issuer validated, never passed through, and scoped to the resource.
• Data: classification, minimisation, tenant isolation, encryption, provenance, retention, and deletion are tested.
• Memory: write access, provenance, scope, expiry, review, and poisoning recovery are defined.
• Approval: consequential actions show clear evidence and cannot be self approved by the agent.
• Runtime: pre tool policy checks can block unsafe execution and fail closed where consequence is high.
• Observability: one trace connects request, model, retrieval, policy, approval, tool, and outcome.
• Testing: normal, edge, adversarial, failure, rollback, and stop cases run after every material change.
• Incident response: alerts, owners, revocation, isolation, evidence, recovery, and communication are rehearsed.
• Lifecycle: permissions, vendors, tools, prompts, models, data, and business purpose are reviewed continuously.