Why AI agent security testing is now a launch, audit or customer requirement
If you are shipping an agent that reads data, calls tools and acts on a user's behalf, expect someone to ask for evidence that it has been tested. That request may come from a launch review, a customer security questionnaire, an insurer, a due diligence team or a framework assessor. Agent security testing is an adversarial test of that agent's goals, tools, identities and memory, and the report it produces is evidence for the people asking, not a certificate. DeployOpen plans and runs these tests in a controlled environment and delivers a written report, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those decisions.
An agent is not a model alone. It combines a model, the tools it can call, the credentials those tools use, and whatever memory or retrieved context it carries between steps. Risk sits in the interactions between these parts: a goal that a malicious document can redirect, a tool call that uses broader permissions than the user holds, or a stored note that changes behavior in a later session. The OWASP Top 10 for Agentic Applications 2026 gives a useful frame for these interactions, running from ASI01 Agent Goal Hijack and ASI02 Tool Misuse through ASI03 Identity and Privilege Abuse, ASI05 Unexpected Code Execution and ASI06 Memory and Context Poisoning. Before scoping, ask which of these your agent exposes and which it does not.
Testing expectations are also taking shape in regulation and assurance. The EU AI Act's Article 15(5) requires high-risk AI systems to be resilient against attempts to exploit vulnerabilities, and Article 55(1) asks providers of general-purpose AI models with systemic risk to perform documented adversarial testing. HITRUST's CSF v11.9.0 added an Agentic AI selectable factor to its AI Security Certification and maps it to the OWASP agentic list. Confirm with your assessor or legal team which obligations apply to your system and which evidence they expect. A well-scoped test gives you findings, the conditions under which each was reproduced, and retest results you can attach to that evidence.
What can be in scope for an AI agent test
An agent test is only as useful as its boundary. Each component below is a separate decision about what the agent can reach, what it can change and who is accountable for it, so the scope should list every item with an owner, a test account and a reason for inclusion.
The agent and its model endpoint
Scope the agent runtime, its system prompt, its planning loop and the model endpoint it calls, whether hosted by a vendor or run in your own infrastructure. Testers look at how user input, retrieved content and tool outputs reach the model and whether the agent can be steered away from its assigned goal, which maps to ASI01 Agent Goal Hijack. Confirm who controls the model version, the prompt configuration and any logging of prompts and completions.
Each tool and connector
List every function, API or connector the agent can invoke, including email, ticketing, databases, file stores and payment or workflow actions. For each one, record what the tool does, which actions it permits and whether a call can be reversed. Tool misuse, covered as ASI02 Tool Misuse, is most often found where a tool accepts broader parameters than the agent's task needs.
Identities and OAuth grants
Record the service accounts, user delegations and OAuth grants the agent holds, along with their scopes and expiry. Check whether the agent acts with the requesting user's rights or with a broader service identity, since that gap drives identity and privilege abuse (ASI03). Ask for a test account with the same grants as production, not an administrator account that hides the real exposure.
Memory and retrieval stores
Include conversation memory, long-term notes, vector indexes and document sources that the agent reads or writes. Writable memory can carry injected instructions into later sessions, which is the memory and context poisoning risk in ASI06. Confirm who can write to each store, how entries are tagged by source, and whether tenants or users can see one another's retrieved content.
MCP servers and sandboxes
Scope each Model Context Protocol server the agent connects to, including whether it runs locally on a user's machine or remotely, and any code execution sandbox the agent uses to run generated code. The MCP security best practices cover token passthrough, confused deputy conditions and local server compromise, and a local server should run with minimal default privileges. Record the sandbox image, network egress and filesystem access so unexpected code execution (ASI05) can be tested against known limits.
Human approval steps and rules of engagement
Identify each point where a person must confirm an action, and test whether the approval shows the exact action being taken, since users can approve what they do not understand. The rules of engagement must state which actions may run against which systems, who can stop the test and how findings are escalated. Agents with write access to production should be tested in a controlled environment with mock or sandboxed data, not against live records.
How an AI agent security test runs, phase by phase
The sequence moves from an agreed scope and threat model to verified findings, a written report and confirmed fixes, so the client can show exactly which agent behaviors were tested, what failed and what was retested. Each phase closes with a defined output that the client and the testing team can check.
Scope the agent and its trust boundaries
The testing team and the client's owners document what the agent does, which tools and data sources it can reach, which identities it acts under, and which users and other agents can send it input. The output is a written scope that names the agent versions, environments, tools in scope, excluded actions and the test accounts to be used. Anything not written into scope stays out of testing, and changes to scope are agreed in writing before they take effect. Duration and effort follow from this scope, so the client should ask for the scope document to be part of any quote.
Build a threat model against ASI01 to ASI10
The team maps each agent workflow against the ten risks in the OWASP Top 10 for Agentic Applications for 2026, from goal hijack (ASI01) and tool misuse (ASI02) through identity and privilege abuse (ASI03), memory and context poisoning (ASI06) and unexpected code execution (ASI05), to rogue agents (ASI10). For each risk the model records the likely entry points, the assets at stake and the controls the client says are in place. The output is a threat model with a test priority for each category, reviewed with the client's architecture owner before testing starts.
Stand up a controlled test environment
The team builds a non-production copy of the agent's tools, permissions, connectors and retrieval sources, populated with synthetic or masked data so that no live customer records are exposed during testing. Logging, rate limits and kill switches are configured so that a test action can be observed and stopped. The output is a short environment record that lists the components, their versions and the data sets used, and that the client signs off before scenarios run. Whether the environment mirrors production closely enough is a question the client should confirm against their own architecture.
Execute scenarios by risk category
Testers run scenarios grouped by ASI category, starting with the highest-priority workflows from the threat model. Typical scenarios cover untrusted content from documents, web pages and tool outputs that tries to redirect the agent, attempts to use granted tools beyond their intended purpose, checks on whether the agent's identity can reach resources it should not, and tests of whether stored memory can carry instructions into later sessions. Each run records the input, the agent's tool calls and the resulting state changes. The output is an evidence log that ties every result to a scenario ID and a timestamp, so the outcome can be reproduced by the client's own team.
Map findings to MITRE ATLAS and NIST AI 100-2
Each confirmed behavior is labeled with the relevant MITRE ATLAS technique or sub-technique, such as the entries for indirect prompt injection (AML.T0051.001) and jailbreak (AML.T0054), and with the matching attack category in NIST AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. These references give the client, its engineers and its auditors a shared vocabulary for each finding. The team checks each mapping against the current ATLAS release the client is using, and records the mapping in the finding. Mappings are classifications for communication, not evidence of compliance.
Verify each finding with the system owner
Before a finding is written up, the testing team walks the owner of the affected agent or tool through the reproduction steps in the controlled environment and confirms the severity, the business impact and whether the behavior is a defect or an accepted design choice. Disputed results are either re-run or recorded as open questions. The output is a list of verified findings, each with an agreed owner and a confirmed reproduction, and any unverified observations are kept separate so they do not inflate the report.
Write the report and agree remediation
The report gives an executive summary, the scope and environment used, the threat model, each verified finding with its ATLAS and NIST mapping, evidence references and recommended fixes, such as narrowing tool permissions, separating identities, adding human approval for high-impact actions or validating memory writes. The client agrees a remediation owner and order for each finding. The output is a delivered report and a remediation list. The report describes what was tested and what was observed; it is not an audit opinion or certification.
Retest fixes and close findings
Once the client reports that fixes are in place, the team re-runs the original scenarios against the changed agent and records whether each behavior is now blocked, partly mitigated or still present. Fixes that change tool scopes or identities are checked for side effects on the remaining workflows. The output is a retest record that marks each finding as closed, open or accepted with a documented risk decision. Retest scope, timing and any repeat testing after major agent changes are set in the written scope, and ongoing testing can be arranged as a retainer.
Which agent weaknesses testers look for and why they matter
Each card maps to a category in the OWASP Top 10 for Agentic Applications 2026. The categories connect because an agent combines a language model that reads untrusted input, tools that act on systems, and credentials that decide what those actions can reach. A test checks whether a failure in one layer stays contained or spreads.
Goal hijack (ASI01)
An agent's objective can be redirected by content it reads, such as an email, a web page or a ticket, so it pursues the attacker's goal while still appearing to serve the user. The business impact is actions taken on behalf of a customer or employee that nobody asked for. Testers check whether the agent separates instructions from data, whether high-impact steps need confirmation outside the model, and whether goal changes are logged. Indirect prompt injection through tool outputs is covered in the prompt injection topic.
Tool misuse (ASI02)
An agent can call a legitimate tool in an unintended way, for example with arguments it should not be able to produce, or in a sequence that combines tools into an unsafe result. The impact is data changes, deletions or outbound transfers made through trusted integrations. Testers check whether tool arguments are validated against schemas and business rules by the tool itself, whether destructive actions require approval, and whether rate and volume limits exist for each tool.
Identity and privilege abuse (ASI03)
Agents often run with service accounts, inherited user tokens or broad OAuth scopes, so a compromised or manipulated agent can reach more than the person it serves. The impact is access to records, systems and tenants outside the intended task. Testers check whether each tool uses a credential issued for that agent and audience, whether the agent acts with the requesting user's permissions, and whether scopes are reduced to what each task needs.
Unexpected code execution (ASI05)
When an agent generates and runs code, scripts or shell commands, model output becomes an execution path on the host or in a sandbox. The impact ranges from data exposure to lateral movement if the runtime can reach internal networks or secrets. Testers check whether execution happens in an isolated environment with no default network or credential access, whether generated code is reviewed or constrained before running, and whether file system and process limits are enforced.
Memory and context poisoning (ASI06)
Agents that store long-term memory, summaries or retrieved notes can carry planted content into future sessions, which changes later decisions without any visible prompt. The impact is persistent misbehavior that outlasts the original input and may affect other users sharing the same store. Testers check who can write to memory, whether entries are tagged by source and user, whether memory is isolated per user or tenant, and whether operators can review and purge it.
Cascading failures and rogue behavior (ASI08 and ASI10)
One agent's error or compromise can propagate through chained agents, shared queues and automated approvals, and an agent can drift from its authorized purpose without a single obvious breach. The impact is a failure that spreads across systems faster than people can respond. Testers check whether actions are bounded by budgets and kill switches, whether agents report their own activity to a monitor, and whether a single failing component is isolated from the rest of the workflow.
What drives the cost and duration of AI agent testing
This table lists the factors that most change the effort, cost and calendar time of an agent security test, and how each one can be narrowed through scoping. Read it before requesting quotes, because the rows show which decisions you control and which ones the testing team needs to see in writing. The main takeaway is that a quote is only comparable to another when both cover the same tools, identities, environments and retest terms.
| Cost driver | Why it moves effort | How to keep it down through scoping |
|---|---|---|
| Number of tools and connectors | Each tool adds its own input path, permission model and failure modes, so every tool that can write, send or delete data needs its own test cases. | List tools by business impact and test write-capable tools in depth. Read-only tools can be covered by a sampled set of cases. |
| Identities and privilege levels | Each role the agent can act under (end user, service account, delegated token) changes what a successful goal hijack or privilege abuse would reach, so each needs its own test matrix. | Agree the roles in scope up front and name the ones that are out of scope with a reason, such as a role with no production access. |
| Multi-agent design or MCP servers | Agent-to-agent messages and MCP tool discovery add trust boundaries, including inter-agent communication (ASI07) and supply chain of tool definitions (ASI04), that must be mapped and tested. | Confirm which agents and MCP servers are internal, which are third party, and which the tester may only review as documentation. |
| Memory and retrieval complexity | Long-term memory stores and retrieval pipelines open memory and context poisoning (ASI06) paths that persist across sessions and users, which requires seeded and cleared test data. | Define which memory stores and indexes are in scope and whether test data may be written to them in a non-production copy. |
| Controlled test environment build | A safe place to run tests that can trigger real tool actions usually needs a staging copy of connected systems, sandboxed credentials and monitoring. This is typically a one-time build, though it may be reused. | Ask whether the client already has a staging environment that mirrors production tools. Confirm who provisions and pays for test accounts and data. |
| Depth of code execution testing | If the agent can run generated code or shell commands (ASI05), testing requires isolated runtimes and checks of sandbox escape paths, which adds setup and analysis time. | Limit code execution testing to the runtimes the agent actually uses, and state whether network egress from those runtimes is in scope. |
| Threat model and scenario design | A threat model maps goals, tools, identities and data flows to ASI01 to ASI10 categories. Building it is one-time work per agent architecture, and it sets the test case count. | Supply architecture diagrams, tool inventories and an agent purpose statement before the scoping call so the model is not built from scratch. |
| Retest rounds and continuous testing | Retests confirm fixes against the original findings and recur with each agent change, model swap or new tool. Continuous testing under a retainer is ongoing effort, not a single event. | Ask for retest terms in writing: how many rounds are included, the window for retesting, and what counts as a fix. Separate one-time testing from any retainer. |
What you receive and whether it satisfies an auditor or customer
A DeployOpen agent test ends in a set of documents that each answer a different reader. The cards below describe what each document contains and what it does not claim, so you can check the package against what your auditor or customer expects before testing starts.
Executive summary
A short document for leadership that states what was tested, the overall exposure, the highest-severity findings and the decisions they need to make, such as whether an agent can stay in production with a given tool scope. It names the agents in scope and the test window, and it refers the reader to the technical sections for evidence. Ask whether your board or customer expects a one-page or a longer summary.
Technical report per agent
Each agent gets its own section listing the scenarios tested, mapped to the relevant OWASP Top 10 for Agentic Applications 2026 entries such as goal hijack or tool misuse, with the outcome of each scenario. Agents that share tools or memory stores are reported separately so that a pass on one does not hide a failure on another. Confirm with your auditor how they want scenario coverage mapped to their control set.
Severity ratings and method
Every finding carries a severity rating and the document states the method used to assign it, so a reviewer can reproduce the rating logic. The method should cover the impact on the user, the data and the connected systems, and the conditions an attacker or faulty output would need. Ask for the method in writing before testing, because an auditor will often challenge a rating that has no stated basis.
Evidence records from the controlled environment
Evidence records capture what the agent did in the controlled environment: prompts and tool calls in order, the identities and scopes used, the outputs returned and the logs that recorded them. These records let your team and an independent auditor confirm that a finding happened and was not inferred. Confirm how long evidence is retained, who can access it and whether it can contain test data that your own policies treat as sensitive.
Retest report with finding status
After fixes are applied, the retest report records the status of each original finding, such as resolved, partially resolved or still open, with the evidence used to decide. Retesting shows whether a fix closed the path or only changed the wording of a prompt. Agree in advance whether retest is included in the fixed scope or quoted separately, since this affects how the final package reads to a customer.
Statement of scope and limitations
This statement names the agents, tools, identities, data sets and environments tested, and it lists what was excluded, such as model internals, third-party services and production data. It also states that the test is a point-in-time assessment and that DeployOpen does not issue audit reports, attestations or certifications. An independent auditor or certification body makes that determination, so ask your auditor which wording they will accept.
Frameworks and rules that expect AI agent testing
This table compares the frameworks and rules that point toward testing AI agents, what each one expects and what evidence a buyer should request. Read each row as a starting point for scoping, then confirm with counsel or your assessor whether it applies to your system. The main takeaway is that the OWASP agentic list gives the test baseline, while the regulatory and certification items decide which evidence you must hold.
| Framework or rule | What it expects | Evidence to ask for |
|---|---|---|
| OWASP Top 10 for Agentic Applications 2026 | Test baseline covering ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse, ASI05 Unexpected Code Execution and ASI06 Memory and Context Poisoning, among other categories | Test plan mapped to each ASI category, with the tested agent, tools and permissions named, and a finding for each category tested or a stated reason for exclusion |
| EU AI Act Article 15(5) | High-risk AI systems must be resilient against attempts to exploit vulnerabilities, including data poisoning, model poisoning, adversarial examples, model evasion and confidentiality attacks | Documented adversarial test results for the agent, retest records after fixes, and a description of the attack classes covered; confirm high-risk status with counsel |
| EU AI Act Article 55(1) | Providers of general-purpose AI models with systemic risk must perform and document adversarial testing, which applies to model providers rather than most agent deployers | Confirm with counsel whether your organization is the model provider or a deployer; if you are a deployer, request the provider's documentation rather than assuming it covers your agent |
| NIST AI 600-1, Generative AI Profile | Voluntary profile of risks specific to generative AI, offering actions for trustworthiness across design, development, use and evaluation | Mapping of agent risks to the profile's suggested actions, with test records showing which actions the testing addressed |
| HITRUST CSF v11.9.0, Agentic AI selectable factor | Selectable factor within the HITRUST AI Security Certification that maps controls to the OWASP Top 10 for Agentic Applications 2026 (HITRUST advisory HAA 2026-005) | Evidence that the agentic controls were tested, mapping from each control to test results, and confirmation of current scope with your HITRUST assessor |
| Customer security reviews | Contract or due diligence questionnaires often ask whether agents with tool access were tested, and for which risk categories | Executive summary and scope statement that name the agentic risk categories tested, plus dated retest confirmation |
How agent testing changes by architecture
A single agent with a few internal tools is the simplest pattern to scope, and it is where most teams start. The agent receives a user request, decides which tools to call, and returns a result. The main risks are goal hijack (ASI01), where instructions embedded in documents, tickets or tool outputs redirect the agent, and tool misuse (ASI02), where a legitimate tool is called with arguments the user never intended. Testing focuses on how the agent decides when to act, which tools it can reach, and whether its permissions match the task.
- Goal and tool inventory: List every tool, its parameters, its side effects and whether it reads or writes data. Testing is only as complete as this list.
- Least-privilege credentials: Check that each tool uses its own scoped identity rather than a broad service account shared across tools (ASI03).
- Human approval gates: Confirm which actions, such as payments, deletions or external messages, require explicit confirmation and whether the agent can bypass that step.
- Untrusted content paths: Trace where retrieved documents, emails and tool outputs enter the prompt, since these are the usual carriers of indirect injection.
- Limits and logging: Test whether runaway loops or repeated calls are capped and whether every tool call is logged with its arguments.
In the controlled environment, replicate the production tool set against non-production data, with seeded test records so that any unintended action is visible and reversible.
Multi-agent systems split work across several agents that pass messages to each other, often with an orchestrator delegating to specialists. Each handoff is a trust decision. The core risk category is insecure inter-agent communication (ASI07), where one agent accepts instructions or data from another without verifying origin, scope or content. Cascading failures (ASI08) are also more likely here, because one compromised or confused agent can propagate bad state to every agent downstream.
- Message trust model: Map which agents may send which instruction types to which recipients, and whether recipients authenticate the sender.
- Delegated authority: Check whether a specialist agent inherits the orchestrator's permissions or receives narrower, task-specific rights.
- Shared memory and context: Identify where agents write to shared stores, since a poisoned entry can influence every later reader (ASI06).
- Failure propagation: Test how an error or malformed response from one agent affects retries, fallbacks and the final action.
- Rogue behavior monitoring: Confirm that the platform can detect and halt an agent acting outside its assigned role (ASI10).
The controlled environment must run the full agent graph with realistic message flows, including the orchestrator, every specialist and the shared stores, because a test of one agent in isolation will not show the handoff weaknesses. Ask the provider how message injection will be simulated.
Agents using remote MCP servers reach tools hosted by a third party or by another internal team over the network. The key question is which token the MCP server accepts and for whom it was issued. The MCP security best practices (protocol version 2025-11-25) cover confused deputy attacks on proxy servers, token passthrough, server-side request forgery, session hijacking and scope minimization. The specification explicitly forbids token passthrough: an MCP server must not accept tokens that were not explicitly issued for that server. Testing therefore starts with token audience and authorization flow, not only with the tool calls themselves.
- Token audience checks: Verify that each remote server rejects tokens issued for other services, which is the failure that token passthrough creates.
- Confused deputy paths: Where a proxy server calls downstream APIs with its own credentials, test whether a user can make it act beyond that user's rights.
- OAuth discovery and URLs: Review how the client validates authorization URLs and whether metadata discovery can be steered toward internal addresses (SSRF).
- Session handling: Check session identifiers for unpredictability, binding to the user, and expiry.
- Scope design: Confirm that scopes map to individual tools and that the client does not request broad scopes by default.
The controlled environment should include a test authorization server, a staging remote MCP server and downstream services that record which token they receive. Ask the provider to confirm that token contents are logged so that passthrough is provable rather than assumed. The detailed method is covered in the MCP server security testing topic.
Agents running on workstations often launch local MCP servers as child processes with access to the user's files, shell and credentials. The risk shifts from network trust to local compromise: a server that is installed with one click, or that a user approves without reading, can run with the user's full privileges. The MCP guidance says that clients offering one-click configuration must show the exact command to be executed and require explicit user approval, and that local servers should run sandboxed with minimal default privileges. Testing covers both the client's approval experience and the server's actual reach.
- Install and approval flow: Check that the exact command, arguments and environment are shown before execution and that approval cannot be pre-granted silently.
- Sandbox boundaries: Confirm which file paths, network destinations and processes the server can reach by default.
- Credential exposure: Test whether local config files, environment variables or keychains hold tokens that a local server can read beyond its purpose.
- Update and provenance: Review how servers are obtained and whether updates re-prompt the user for changed commands.
- Fleet management: Ask whether endpoint controls can allow-list approved servers across managed devices.
The controlled environment should use managed test workstations with a known inventory of servers, a canary file set and network egress monitoring, so that over-reach is observable. Confirm with the provider which operating systems and client versions are in scope, because sandbox behavior differs between them.
What your team prepares before an agent test starts
Before any agent test starts, your team names a business owner for each agent in scope. That person decides what the agent is for, writes down the tasks it should perform and the actions it must never take, and is available to answer questions about tool behavior during the test. Alongside that description, supply test accounts that reflect the privilege levels you want checked, such as a standard user, a support role and a privileged administrator, so that testers can see whether the agent's own permissions or the user's permissions govern each tool call. Agree in writing which identities the agent acts under, because identity and privilege abuse testing depends on knowing which credentials and scopes the agent holds.
Provide non-production copies of the tools, data stores, mailboxes, ticketing systems and APIs the agent can reach, along with a test environment or sandbox that your security and platform owners have approved for executing agent actions. Confirm that the sandbox cannot send email to customers, move money, change production records or call third-party services with live keys. Give testers logging access to the agent's tool-call traces, model inputs and outputs, and downstream system audit logs, so that findings can be tied to specific steps. Name one point of contact with authority to pause or stop testing at any time, and ask your change management team to set a change freeze on the test systems for the test window, so that test results are not confused with unrelated changes.
Decide in advance what happens if a test triggers a real action, such as an agent sending a message to a live recipient, writing to a production system or calling an external API. Agree on who is notified, how quickly, what evidence is preserved, and whether the tester stops, rolls back or waits for your instruction. Confirm the approach with your incident response team and record it in the rules of engagement before work begins. Ask the testing provider to show how they will keep test traffic labeled and separate from production traffic, and treat any gap in that answer as a scoping item to resolve before the test is priced or scheduled.
Common questions about AI agent security testing
What drives the cost of testing an AI agent?
The main drivers are the number of tools and data sources the agent can reach, how many distinct user roles and identity paths exist, and how many agent-to-agent or MCP server connections are in scope. Each tool that writes data, moves money or executes code adds test cases and environment work. Ask any provider to price the scope as a written list of agents, tools, identities, data stores and environments, and to separate one-time test work from any recurring retesting or continuous testing. A fixed-scope quote should name what is excluded, such as model training pipelines or third-party SaaS tools the agent calls. Cost also rises when the test must build a controlled replica of the agent's tools and data, so ask who provisions that environment and who pays for it.
How long does an AI agent security test take?
Duration depends on the number of tools, the complexity of the permission model and how much of the test runs in a replica rather than in a shared environment. Agents with many tools, several identity providers or multi-agent workflows need more time to map trust boundaries before any attack scenario is built. Setup time for a controlled environment often runs in parallel with scoping, but it can delay the start if credentials, sample data or agent configurations are late. Ask the provider to state the duration in its written scope, list the milestones (scoping, environment readiness, testing, reporting, readout) and name the client dependencies that could move them. Treat any duration given without a stated scope as unverified.
What does the client need to provide for an agent test?
Testers need an accurate picture of the agent before they can test it. Typical inputs include a description of each tool and its permissions, the identity model (which service accounts, user tokens and scopes the agent uses), the system prompts and policy configuration, the data sources and memory stores, and the logs that show agent actions. A sandbox or staging copy with representative but non-production data is usually the safest starting point. The client should also name a technical contact who can approve tool calls that have real side effects, and agree in writing which actions the tester may trigger. Confirm early whether the agent's model provider permits the planned test traffic under its terms.
Can our internal team test AI agents without outside help?
Internal teams can run useful checks, especially on tool permissions, logging and configuration review, but agent testing needs skills that cross application security, identity and AI behavior. Ask whether your team has done adversarial testing against non-deterministic systems, can reproduce findings across repeated runs, and can judge whether a model's output represents a real control failure. Independence also matters if an auditor, customer or insurer will rely on the results. A common split is internal teams owning configuration hygiene and monitoring while an external team tests goal hijack, tool misuse and privilege abuse. Confirm what your team would produce as evidence and whether an external reviewer would accept it.
Does agent security testing need to run against production?
Usually not. Most agent tests run in a controlled environment because adversarial inputs can trigger real tool actions, such as sending messages, changing records or calling paid APIs. A non-production replica with mock or sandboxed tools lets testers exercise goal hijack and tool misuse scenarios without side effects. Some checks, such as confirming production authentication settings or reviewing configuration, may need read-only access to production or a production-equivalent setup. If you want any production testing, agree in writing on the allowed actions, time windows, rate limits, data handling and rollback steps, and confirm the platform owner's approval. Ask the provider how it keeps test data and test traffic separate from customer data.
How does an agent security test differ from prompt injection testing or AI red teaming?
An agent security test covers the whole agent: its goals, tools, identities, memory, code execution and how it hands work to other agents. Prompt injection testing is a focused engagement on how untrusted content changes the agent's instructions, and it is one part of agent testing. AI red teaming is objective-based adversarial testing against agreed harm scenarios, often using MITRE ATLAS techniques, and it can include social and human-trust scenarios. Ask a provider which of these it is delivering, what the scope excludes and how findings map to the OWASP Top 10 for Agentic Applications 2026. For a fuller explanation of red teaming and the EU AI Act's adversarial testing duties, see the AI red teaming topic.
How does retesting work after agent findings are fixed?
Retesting checks whether the fixes hold, and it should be written into the original scope or priced separately. Ask the provider whether retest effort is included, how many rounds it covers and what evidence closes a finding, such as a changed permission, a new approval step or a logged and blocked tool call. Because agent behavior varies between runs, a single clean pass does not prove a control works, so ask how many repetitions the retest uses and how results are reported. Also confirm whether the team will rerun the scenarios after each major model, prompt or tool change, since those changes can reopen risks. Recurring retesting or continuous testing is usually a separate retainer with its own scope.
How DeployOpen scopes, tests, reports and retests AI agents
DeployOpen runs AI agent security testing as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. Testing takes place in a controlled environment, and the written report is built so your security team and auditors can act on it.
How we scope
- Written scope lists each agent, its tools, data sources and the identities it acts under
- Scope records which OWASP Top 10 for Agentic Applications 2026 risks are in and out of testing
- Rules of engagement set permitted actions, test accounts, and which production systems stay untouched
How we build
- Testing runs in a controlled, non-production environment that mirrors the agent's tools and permissions
- Test scenarios cover goal hijack through documents, web content and tool outputs, without touching live customer data
- Each agent's tool permissions and token audiences are reviewed against the scope before any scenario runs
How we hand over
- Report maps each finding to ASI risk IDs and, where relevant, MITRE ATLAS techniques
- Each finding states the evidence, affected agent or tool, severity reasoning and a defensive remediation direction
- Deliverables include a retest plan and a summary your auditor or customer security reviewer can read
How we support
- Retesting confirms whether each fix holds, with results recorded against the original finding IDs
- Ongoing support and continuous testing are available as a retainer for agents that change frequently
- Confirm with us which retest window and support terms apply to your scope before you sign
