An AI agent security audit should do more than review a policy document or run a handful of prompt injection examples. A production agent can retrieve data, call tools, act through a browser, remember prior interactions, and create side effects in systems that were designed for human operators. The audit therefore has to test the whole decision-and-action path.
This guide defines a practical AI agent security audit scope for product teams, security reviewers, and buyers. It explains what to include, which tests produce useful evidence, and what a credible final report should deliver. The goal is not to promise that an agent can never fail. The goal is to show that important failure modes are understood, tested, constrained, observable, and owned.
Define the operating boundary first
Start by writing down the exact production scope. Name the users, data classes, tools, destinations, actions, models, retrieval sources, approval points, and deployment environments. Also state what the agent is not allowed to do.
A support agent, for example, may search approved knowledge, summarize tickets, and draft replies while being prohibited from sending messages, changing account permissions, issuing refunds, or exporting customer records. That boundary turns an abstract security review into a testable claim.
The auditor should record assumptions and exclusions. If browser automation, long-term memory, or a planned integration is outside the current review, the report should say so. An exclusion must not quietly become production scope later without a new review.
1. Architecture and trust boundaries
Map the complete request path: user interface, orchestration layer, model providers, retrieval systems, memory, tools, approval service, logging pipeline, and external destinations. Mark where instructions and data cross trust boundaries.
The audit should distinguish system instructions, developer instructions, user input, retrieved content, tool output, and external webpages. These inputs do not deserve equal authority. Tests should verify that untrusted content cannot silently redefine the agent’s objective or policy.
Evidence should include an architecture diagram, component inventory, data-flow map, deployment boundary, and named owners. Generic boxes such as “AI layer” are not enough when they hide permissions or data movement.
Determine whose identity the agent uses for each action. A shared service account with broad permissions can turn a small model error into a large incident. Prefer short-lived credentials, user-scoped authorization, tenant isolation, and narrowly defined service roles.
Test horizontal and vertical access boundaries. Can one tenant retrieve another tenant’s documents? Can a normal user cause an admin-only tool call? Can the agent reuse a browser session or object identifier belonging to someone else? Can authorization be bypassed through indirect tool arguments?
The report should show successful and denied requests, including the policy decision and identity context used at enforcement time.
3. Tool inventory and action controls
Every tool should have a documented purpose, read/write classification, permission scope, parameter restrictions, destination rules, approval requirement, rate limit, logging behavior, and owner. Review the implementation, not only the tool description shown to the model.
Test malformed arguments, hidden high-impact parameters, chained tool calls, retries, duplicate execution, and attempts to call tools outside the intended workflow. Write-capable operations should be idempotent where possible and should fail safely when the model produces incomplete input.
High-impact actions need a deterministic control outside the model. Examples include allowlists, transaction limits, schema validation, policy engines, approval gates, and isolated execution environments.
4. Prompt injection and instruction hierarchy
Test direct attacks from users and indirect attacks embedded in documents, emails, tickets, webpages, tool results, file metadata, and retrieved chunks. Include realistic attacks that combine a legitimate task with a malicious instruction.
Do not score only whether the agent says “no.” Depending on the workflow, the correct behavior may be to ignore untrusted instructions, continue with safe data, ask for clarification, redact a secret, request approval, or stop and escalate.
Each test should record the fixture, expected outcome, actual trace, affected control, severity, and reproducibility. A screenshot without the underlying trace is weak audit evidence.
5. Sensitive data and data egress
Identify the sensitive data the agent can see: personal data, credentials, internal documents, customer records, regulated data, source code, financial information, and model or application secrets. Then map every place that information can leave.
Test exfiltration through normal responses, tool arguments, URLs, webhooks, email, browser forms, files, logs, analytics, memory, and third-party model calls. Include encoded, fragmented, transformed, and multi-step attempts rather than testing only plain-text leakage.
Useful evidence includes destination allowlists, redaction examples, retention rules, provider settings, deletion behavior, and blocked egress traces.
6. Retrieval, memory, and knowledge integrity
Review who can add or change knowledge, how sources are authenticated, how tenant boundaries are preserved, and whether the agent can cite the evidence behind an answer. Retrieval systems should treat content as data, not trusted policy.
Test poisoned documents, conflicting sources, stale policies, access-controlled documents, malicious metadata, and citations that do not support the answer. For memory, test unauthorized recall, cross-user contamination, sensitive-value persistence, deletion, and instructions planted in earlier conversations.
The report should separate answer-quality defects from security defects while showing where one can cause the other.
7. Human approval and meaningful control
An approval click is not automatically a security control. The approver must see the action, target, important parameters, destination, data being disclosed, and reason for escalation. Approval must be bound to that exact action so the agent cannot change the payload afterward.
Test approval bypass, stale approvals, replay, payload modification, bulk-action ambiguity, and deceptive summaries. Also test rejection and timeout behavior. The system should stop cleanly and preserve an audit record.
8. Sandboxing, browser automation, and external effects
Agents that execute code, manipulate files, or control browsers need strong isolation. Review network access, filesystem access, secret exposure, process limits, download handling, domain restrictions, session isolation, and cleanup.
Browser tests should include hostile pages, misleading buttons, pop-ups, downloads, cross-domain navigation, authenticated sessions, and instructions that attempt to make the agent disclose data or confirm a transaction. A model-level instruction is not a substitute for browser and network enforcement.
9. Logging, monitoring, and incident reconstruction
Confirm that the team can reconstruct an important event without storing unnecessary secrets. Useful fields include request identity, model and prompt version, retrieved source IDs, trust labels, tool calls, validated arguments, policy decisions, approvals, final effects, and error states.
Test whether alerts fire for denied high-risk actions, unusual export volume, repeated injection attempts, permission failures, and sudden changes in tool behavior. Logs should be protected from ordinary users and have an appropriate retention policy.
A practical audit exercise is to select one failed scenario and ask the team to explain what happened, who was affected, what stopped it, and what should change.
10. Change management and regression testing
Models, prompts, retrieval indexes, tools, permissions, and user interfaces all change agent behavior. Review the release process and identify which changes trigger security regression tests or a new risk review.
The minimum regression suite should cover prompt injection, tool permissions, data egress, tenant isolation, approval binding, logging, and known critical failures. Results should be tied to a release identifier and an accountable owner.
How to prioritize findings
Severity should consider impact, exploitability, required access, blast radius, detectability, and recovery. A prompt injection that changes harmless formatting is not equivalent to one that exports customer data through a write-capable tool.
For each finding, record the affected workflow, evidence, reproduction steps, business impact, recommended control, owner, target date, and retest status. Separate confirmed findings from design concerns and improvement opportunities.
What the final audit should deliver
- Executive summary with a clear readiness decision and major conditions.
- Defined scope, exclusions, assumptions, architecture, and data flows.
- Threat model linked to real users, tools, data, and external systems.
- Test plan, fixtures, expected outcomes, actual results, and traces.
- Prioritized findings with owners and remediation guidance.
- Evidence appendix with sensitive values removed.
- Retest results and residual-risk decisions.
A useful report should support a decision: approve the current scope, approve it with conditions, restrict it, or delay production. A list of generic best practices cannot make that decision.
Related resources
- AI Agent Security Audit Checklist
- AI Agent Security Review Packet
- AI Agent Guardrail Testing Examples
- Sample AI Agent Readiness Audit Report
- AI Agent Readiness Audit
To identify the highest-priority gaps before commissioning a full audit, run the AI Agent Readiness Self-Assessment. For an independent review of a production scope, request an AI Agent Readiness Audit.