Agentic AI security testing vs LLM application testing: which one your system needs
The choice between agentic AI security testing and LLM application testing follows from what the system can do, not from what it is called. A chat or retrieval application that mostly returns text needs testing centered on the LLM Top 10 risks, such as prompt injection and sensitive data exposure through its prompts and retrieval layer. A system that plans steps, calls tools and acts with delegated identity needs the OWASP Agentic Top 10 risks added to that scope, because a successful attack can change a record, send a message or run code rather than just produce a bad answer. Ask the owning team to list every tool the model can invoke, every credential or token those tools use, and whether any action runs without a human approval step. If the answer is none for all three, LLM application testing may cover most of the need. If any tool acts with the user's delegated access, plan for agentic testing.
Several Agentic Top 10 entries map directly to these checks. ASI02 Tool Misuse covers an agent using a legitimate tool in an unintended way, which a text-only application cannot do. ASI03 Identity and Privilege Abuse covers agents that inherit or hold more access than the task needs. ASI05 Unexpected Code Execution applies where an agent can run generated code, and ASI07 Insecure Inter-Agent Communication applies where agents pass instructions to each other. For systems that expose tools through the Model Context Protocol, the MCP authorization specification's rule against token passthrough is a concrete test case: confirm that each MCP server rejects tokens not issued for it. Confirm these details with the platform team, because the test plan depends on them and the reader's environment decides which checks apply.
Many organizations need both. A chat front end that also calls an agent with write access usually needs an LLM application test for its prompts, output handling and data layers, plus an agentic test for its tools and identities. Scope and duration grow with the number of tools, identities and agent-to-agent paths, so ask a provider to state how each one is covered in the written scope and whether the test uses a staging environment with realistic but non-production tool connections. Where the agent acts on production data, confirm the rules of engagement before testing starts, since a successful attack in the test could alter live records.
How the system's capabilities change the scope of a test
A chat application that mostly returns text has a narrow set of reachable components: the model endpoint, the prompt and system instructions, the application's web and API layers, and whatever session state the front end keeps. The main risks sit in how the application handles user input and output. The OWASP LLM Top 10 2026 is the natural scope driver here, because most of its items concern prompts, output handling and data exposure rather than actions taken on other systems. The attack surface changes little when the model is the only component that generates text.
- Reachable components: the model endpoint, system prompt, front end, and the application's own API, which is usually tested with conventional methods.
- Prompt-level risks: prompt injection and attempts to override instructions, judged by what the text output allows the user to see or do in the application.
- Output handling: whether generated text is rendered, executed or passed to downstream code without validation.
- Data exposure: whether system prompts, hidden context or training-derived content can be extracted, which the 2026 list addresses under Hidden Context Exposure at LLM08.
- Limited blast radius: a successful attack usually ends in a bad answer or a leaked string, so the test can often be bounded to one application.
Before scoping, confirm with the owner that the application truly has no tool access, plugins or write paths, because a single added connector changes this tab's assumptions.
A retrieval application pulls documents from a vector store, search index or internal knowledge base and places them into the model's context. The tester must reach the ingestion path, the retrieval service, the access controls applied at query time, and the data sources feeding them. The attack surface moves from the prompt into the data. Any document a user can influence may carry instructions that the model reads as part of its context, which makes indirect prompt injection a central test case.
- Reachable components: the vector store or index, the retrieval query path, document ingestion pipelines and the source systems that feed them.
- Authorization at retrieval: whether the retrieval layer enforces the requesting user's permissions, or returns documents the user could not open in the source system.
- Indirect injection: instructions hidden in ingested documents, web pages or tickets that alter model behavior once retrieved.
- Data poisoning paths: who can write to the corpus and whether those writes are reviewed.
- Hidden context: whether retrieved passages, metadata or system content appear in responses in ways the owner did not intend.
Confirm which identity the retrieval service uses to read sources, since a single service account with broad read access widens the test considerably.
An agent plans multi-step work, calls tools, holds credentials or delegated identities and can exchange messages with other agents. The tester must reach every tool connector, the credentials each one uses, the MCP servers or APIs behind them, and any other agent that sends or receives tasks. Excessive Agency, now LLM03 in the OWASP LLM Top 10 2026, becomes a primary scope driver, and the OWASP Agentic Top 10 adds Tool Misuse (ASI02), Identity and Privilege Abuse (ASI03), Unexpected Code Execution (ASI05) and Insecure Inter-Agent Communication (ASI07).
- Tool and connector reach: every tool the agent can invoke, with the permissions each tool grants in downstream systems.
- Identity and privilege: whether the agent acts with its own identity, the user's delegated token, or a shared service account, and whether privileges persist beyond a task.
- Code execution: sandboxes, interpreters and file writes the agent can trigger.
- Agent-to-agent traffic: messages between agents, including whether one agent can instruct another to take actions it would refuse.
- Wider blast radius: a single injected instruction can cause actions across several systems, so scope often covers the connected estate, not one application.
Ask the owner for a complete tool inventory and a list of identities before writing the statement of work, because the test cannot be bounded without them.
Goals, scope, method, duration and team skills side by side
This table compares how a test of an LLM chat or retrieval application differs from a test of an agent that plans, calls tools and acts under delegated identity, row by row across goal, scope, environment, risks, skills and reporting. Read each row as a question to put to your test provider, and use the duration row to scope the number of tools and identities before asking for a quote.
| Factor | LLM application testing | Agentic AI security testing |
|---|---|---|
| Primary goal | Find ways to make the application return unsafe output, leak data through its responses, or bypass its intended behavior | Find ways an agent can be steered into taking unauthorized actions with its tools, identities and data, and what those actions reach |
| What counts as the target | The prompt pipeline, model integration, retrieval layer, and the web and API surfaces around them | The agent loop, its planner and memory, every connected tool, MCP server, credential store, and any agent-to-agent channel |
| Unit of scope | Application features, user roles and data sources in the test plan | Each tool, delegated identity, permission scope and action the agent can execute, plus the workflows that chain them |
| Method at buyer level | Scenario-based and checklist-based probing of inputs and outputs, with web and API testing alongside | Scenario tests that follow multi-step action chains, with controlled tool calls and review of each action the agent takes |
| Environment needed | A staging copy of the application with representative data and a non-production model endpoint | An isolated copy with sandboxed tools, test accounts, and non-production credentials, so that actions cannot reach live systems. Confirm this with the provider before testing |
| Typical risks reached | Prompt injection, sensitive information disclosure, system prompt exposure and output handling flaws | Tool misuse, identity and privilege abuse, unexpected code execution, and insecure inter-agent communication under the OWASP Agentic Top 10 |
| Team skills | Application security, web and API testing, and prompt-level adversarial work | Adds agent workflow analysis, OAuth and token handling, MCP authorization, sandboxing, and safe handling of actions with side effects |
| Handling of tool actions and state | Mostly read-only or text-returning, so state is usually limited to the session | Actions may write data or trigger workflows, so the test needs rollback, logging of each call, and a plan for state left behind |
| Reporting | Findings tied to inputs, outputs and affected data, often mapped to the OWASP LLM Top 10 | Findings also record the agent's plan, each tool call, the identity used, and the permission boundary crossed, mapped to the OWASP Agentic Top 10 and MITRE ATLAS |
| Duration with more tools and identities | Mostly driven by features and data sources, so it grows with the size of the application | Grows with each tool, identity and action chain, since each combination needs its own scenarios. Ask the provider to show how it counts these in the written scope |
Why tool misuse and delegated identity change what the test must prove
An agent test has to prove what the agent can reach, not only what it says. A chat application that returns text can cause harm mainly through its output. An agent that calls tools and acts with a delegated identity can cause harm through its actions, so the test must verify the controls that bound those actions. Four risks in the OWASP Agentic Top 10 for 2026 drive most of that work. ASI02 Tool Misuse covers an agent using a tool it is allowed to call in a way the user did not intend. ASI03 Identity and Privilege Abuse covers an agent using a credential or permission beyond what the user delegated. ASI05 Unexpected Code Execution covers agent-generated or agent-triggered code running with more reach than intended. ASI07 Insecure Inter-Agent Communication covers messages between agents that are trusted without verification.
For each of these, the test should check whether the agent can be steered, through its inputs or the content it reads, into calling a tool or using a credential outside the user's intent. Start by inventorying each tool, its parameters, the identity it runs under and the side effects it can cause. Then verify that the tool layer enforces the user's scope itself, not only the model's instructions, and that high-impact actions require an explicit confirmation step. Ask the vendor or internal team for the tool allowlist, the policy that maps user consent to scopes, and logs that record which identity executed each call. The MCP authorization specification forbids token passthrough, so the test should confirm that an MCP server rejects any token not issued for it, as described in the MCP security best practices.
The evidence a buyer should expect is a traceable record, not a pass or fail score. Ask for a test plan that lists each tool and identity pair, the attempted out-of-intent use, the observed control response and the log entry that shows it. For code execution and local servers, confirm that sandboxing and minimal default privileges are in place and that the user sees the exact command before approval. Several items here depend on your platform and cannot be assumed from a vendor's general claims, so confirm them in your own environment, including how inter-agent messages are authenticated. Illustrative example: if a scheduling agent can read a calendar and send mail, the test should show whether a mail send can happen without a matching user request and whether the attempt is logged under the user's identity.
What each approach finds and what it misses
LLM application testing and agent testing overlap on the web, API and data layers, but they surface different failures. The cards below separate what each approach typically finds from what it leaves untested, so the scope of a test follows the system's actual capabilities.
Output handling and data exposure
LLM application tests mostly look at what the model's text does once it reaches the rest of the application. Testers check whether generated output is rendered unsafely in a browser, passed into a database query or shell, or returned with data the user should not see. Prompt injection in this setting usually changes the text the user reads or the content the app stores. Ask the tester to trace every path where model output leaves the application boundary.
Tool misuse and privilege abuse
Agent tests examine what the model can do with the tools it holds. A crafted input can steer an agent into calling a tool with arguments the user never intended, or into using a delegated identity beyond the task at hand. This maps to ASI02 Tool Misuse and ASI03 Identity and Privilege Abuse in the OWASP Agentic Top 10. Check each tool's permissions against the narrowest scope the task needs.
Unsafe code execution
Where an agent can write and run code, a text-only test will miss the execution path. Testers should confirm whether generated code runs in a sandbox with no access to the host, credentials or internal networks, and whether a prompt can reach that sandbox. This corresponds to ASI05 Unexpected Code Execution. Ask the tester to demonstrate the boundary, not only describe it.
Inter-agent trust and token passthrough
Agent-to-agent messages and MCP servers create trust decisions that a chat application never makes. ASI07 Insecure Inter-Agent Communication covers agents that accept instructions from peers without verification. The MCP authorization specification forbids token passthrough, so an MCP server must reject any token not explicitly issued for that server. Include a test that replays a token issued for another audience and confirms it is refused.
Local MCP one-click approval
For local MCP servers, the MCP guidance requires that clients offering one-click configuration display the exact command to be run and require explicit user approval. Local servers should also run sandboxed with minimal default privileges. An agent test should confirm that installation flows show the full command, that no step runs silently, and that the server cannot read files or credentials beyond its task.
What each approach misses
LLM application testing rarely exercises tool chains, delegated identities or the runtime environment an agent can reach, so those paths stay untested. Agent testing needs a sandboxed test environment with realistic but non-production tools and data, and it takes longer because each tool and identity adds states to explore. Confirm with any tester whether their scope includes agent runtime discovery, which MITRE ATLAS now covers as AML.T0133.
Building the test environment an agent needs
This sequence gives the testing team a defined copy of the agent's tools, identities and data, with logging in place and written rules for any action that could change a real system. Testing then reaches the agent's tool calls and delegated access without touching live business processes.
Inventory tools, connectors and identities
The agent owner and the security lead list every tool the agent can call, each MCP server or connector behind those tools, the credentials and delegated tokens each one uses, and the downstream systems they can write to. The output is a written inventory that marks each tool as read-only, write-capable or able to trigger code execution or another agent. Testers then know which paths carry side effects before any test is designed. Confirm the list with the platform team, because shadow connectors are the most common gap.
Build an isolated copy with test accounts
The platform team deploys the agent, its model gateway, MCP servers and connectors into a non-production environment that mirrors the production configuration as closely as the organization can document. Each identity in the inventory gets a dedicated test account with the same role scope as production, and the data is synthetic or masked. The check that closes this step is a comparison of configuration and permissions between the two environments, with every difference recorded and explained. Where the copy cannot match production, the gap becomes a documented limit on what the test can show.
Confirm tokens and sandboxing match the MCP guidance
Testers verify that each MCP server in the copy accepts only tokens issued for that server, which is the token passthrough rule in the MCP authorization specification. For local servers, they confirm that one-click installation shows the exact command and requires explicit user approval, and that servers run sandboxed with minimal default privileges. Testers record any server that accepts a token issued for another service. This check prevents a finding that is really an artifact of a loose test setup.
Instrument tool calls and logs
The team turns on logging for every prompt, model decision that selects a tool, tool invocation, parameter set, identity used and response returned, and sends these records to a store the testers can query separately from the agent. Logs must capture the delegated identity on each call so that privilege abuse can be traced. The step is complete when a scripted benign request produces a full chain of records that the test team can reconstruct from start to finish. Ask the platform owner which events the agent framework emits natively and which need custom instrumentation.
Set up kill switches and reset points
The team defines how to stop the agent, revoke its tokens and disable individual connectors during a test, and how to restore the copy to a known state after each scenario. Reset points, such as snapshots of the test data and configuration, let testers repeat a scenario and confirm that a finding reproduces. The step is done when the owner has performed one stop and one restore in the copy and recorded how long each took. Testers should not start the adversarial phase until this drill passes.
Agree rules of engagement for side effects
The client, the testing provider and the owners of each connected system sign rules of engagement that list permitted actions, prohibited actions, testing windows, named contacts and escalation steps. Any action with a real side effect, such as sending a message, moving money, changing a record or running code on a host, needs an explicit written allowance or must be replaced with a harmless stand-in. NIST SP 800-115 provides a rules of engagement template in Appendix B that teams can adapt. Production testing carries high risk, so the agreement should state that live systems are excluded unless the client approves a separate, narrower plan.
Dry-run the scenarios before adversarial testing
Testers run a set of benign scenarios that exercise each tool and identity in the inventory, then confirm that the logs, kill switches and reset points behave as documented. Any scenario that writes to a system outside the copy stops the run and returns to the rules of engagement. The output is a short record of what passed, what was changed and what the owners accepted. Adversarial scenarios such as tool misuse or identity abuse start only after this record is approved by the client and the owners of the connected systems.
How scope and duration change between the two
An agent test grows with the number of things the agent can reach and act through, not just with the number of prompts it accepts. The cards below list the drivers that move scope and effort, and what to confirm before you request a written scope.
Tools and connectors
Each tool, plugin or MCP connector is a separate action surface that the agent can invoke with its own parameters and side effects. Testers must map every callable tool, the data it reads and writes, and whether any tool can run code or reach the network. Ask the provider for a written inventory of tools per agent, and confirm which connectors are vendor-maintained and which are built in-house. Each tool adds its own misuse cases.
Identities and privilege levels
An agent that acts with delegated identity can hold several credentials, such as a service account, a user token and a workflow identity, each with different rights. Testing must check whether the agent can escalate from a low-privilege user context into a higher one, which is the core of ASI03 Identity and Privilege Abuse. Confirm how many identities each deployment uses, who approves them, and whether test accounts can mirror production roles.
Agent-to-agent paths
When one agent delegates work to another, the trust boundary moves from a single model call to a chain of calls, and an instruction can cross that chain without a human seeing it. Testers need to enumerate every inter-agent channel, the messages each accepts, and whether the receiving agent checks the sender. This is the scope item most likely to be missed in a single-application test, and it is covered by ASI07 Insecure Inter-Agent Communication. Ask which agents can message which.
Stateful memory
Persistent memory, vector stores and saved conversation context let content from one session influence later actions, possibly for other users. Testing has to cover what is written to memory, who can read it, how long it persists, and whether it can be poisoned by untrusted input. A stateless chat application usually needs a single session model, while a stateful agent needs time-separated test runs. Confirm retention settings and tenant isolation of the memory store before scoping.
Multi-step plans
An agent that plans and then executes several steps can take an action several turns after the risky input arrived, so a single prompt test misses the failure. Testers must follow plans end to end, record each step, and check whether approval gates appear where they should. Scope should count the planned workflows and the branches they can take, not only the number of user requests. Ask the provider for the workflows that include write, delete or payment actions.
Test environment build
Agents need a sandboxed copy of their tools, identities and data before they can be tested safely, because live actions can change production records. Building that environment with realistic but synthetic data, mock services and logging is often the largest up-front effort and a recurring cost when the agent changes. Confirm whether the provider can supply a staging tenant, who owns the mock services, and how quickly test data can be refreshed. This is also the point where your own infrastructure choices matter most.
Questions buyers ask before hiring outside help
What drives the cost of testing an agentic AI system?
The main cost drivers are the number of agents, the number of tools and identities each agent can use, and how many integrations sit in the test path. An agent that calls a dozen tools across three identity providers needs far more test cases, accounts and environment setup than a single chat assistant. Ask the provider to price the work from a written scope that lists each agent, each tool with its permissions, each identity or token type, and each agent-to-agent connection. Ask whether the quote covers test environment preparation, retesting after fixes, and reporting, since these are separate line items. DeployOpen works from a written, fixed scope agreed before work starts, so the quote follows from that scope and no standard price list applies.
How long does agentic AI security testing take?
Duration depends on the number of agents, tools, identities and environments in scope, and on how much of the test environment must be built before testing starts. Testing of tool misuse and identity abuse usually takes longer than prompt-level testing because each tool and permission path needs its own checks. No fixed duration is stated here because no researched figure supports one. Ask for a timeline that separates environment setup, test execution, retesting and reporting, and ask what the client must deliver before each phase starts.
What does the client need to provide for an agent test?
Agent testing needs more client input than a chat application test. Plan to provide:
- Test accounts with the same roles and delegated permissions that production agents use, plus accounts with lower privileges for comparison
- A tool inventory listing every tool, its endpoint, its scopes and whether it writes data or executes code
- A sandbox or staging environment with non-production data, where agents can call tools without touching live records
- Logs or traces from the agent runtime so testers can confirm what the agent did
Ask the provider which of these it expects, and who in your organization approves access to each.
Can our internal team run agentic AI security tests?
An internal team can run parts of this work if it has people who understand agent frameworks, identity flows and the tools the agent calls, and if it can build a safe test environment. The hardest parts are usually testing delegated identity, confirming that tokens are not reused across servers, and proving that a tool cannot be misused to act beyond its intended scope. Those checks need someone who can read the authorization design as well as the prompts. Ask yourself whether the team can produce repeatable test cases, record evidence and retest after fixes. An external provider can plan, implement and document the work in a fixed scope, and the results still depend on your own ownership of fixes.
Do the OWASP lists alone define the scope of an agent test?
No. The OWASP Top 10 for Agentic Applications for 2026 gives a useful starting checklist, including ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse, ASI05 Unexpected Code Execution and ASI07 Insecure Inter-Agent Communication. A list of risk categories does not describe your architecture, though. Scope should also cover the specific tools, identities, data stores, and any MCP servers your agents use, plus the authorization rules for each. The MCP security best practices add concrete requirements, such as servers refusing tokens not issued for them. Use the OWASP lists to structure the test, and use your own system inventory to decide what gets tested.
How does agent testing fit with our existing penetration testing?
Agent testing covers risks that a conventional penetration test of web and API endpoints may not reach, such as tool misuse and delegated identity. Conventional penetration testing still covers the APIs, web layers and infrastructure that agents depend on. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, so one engagement can include both. Ask the provider how it will scope one engagement for both areas, which findings go to which owner, and how retesting is handled. Scheduled penetration testing and an agent-specific test can share an environment and a rules of engagement document.
What should a quote for agent testing include?
A useful quote lists the scope in writing: agents, tools, identities, MCP servers, agent-to-agent paths and environments. It should name the deliverables, such as test cases, evidence, a findings report and retest results, and the dates or milestones each one depends on. Ask which costs are one-time, such as environment build, and which recur, such as retainers for continuous testing. Ask what the client must provide and what happens if access is delayed. Confirm the rules of engagement, data handling and who approves production-adjacent testing before work begins.
What drives cost and effort for each approach
Agentic AI testing and LLM application testing are both quoted from a written scope, so the cost gap comes from what the tester must build, access and verify. The cards below cover who is paid for what, which costs recur, what raises effort, and what to ask for before signing a fixed-scope agreement.
Who is paid for what
A fixed-scope test usually bundles tester time for planning, exploitation, validation and reporting, plus any environment build the tester performs. For an LLM application, most hours go to the web, API and retrieval layers. For an agent, add time to map each tool, identity and inter-agent channel. Ask the provider to split the quote by phase so you can see where agent-specific work sits.
One-time versus recurring costs
The first engagement carries setup costs: scope workshops, a test harness, test accounts and credentials, and sometimes a staging copy of the agent. Retesting after each change to prompts, tools or MCP servers recurs. An agent that changes often can shift spend from one large annual test toward smaller, repeated runs. Ask which costs are one-time and what a retest on a changed tool set is billed as.
Tool count and tool privilege
Every tool an agent can call adds a test path, a set of inputs to probe for misuse under OWASP ASI02 Tool Misuse, and a permission boundary to verify. Effort rises faster when tools write data, send messages or run code, because each action needs safe test data and a way to observe its effect. Ask how many tools and connectors are in scope and which ones can change state.
Identity model and delegated access
Agents often act with delegated identities, service accounts or user tokens, so testers must check each identity path against OWASP ASI03 Identity and Privilege Abuse. Effort increases with the number of identity providers, token exchanges and roles. Testers also need accounts with different privilege levels to test authorization properly. Ask who issues those test identities, how long they remain valid, and whether the client must provision them.
Test environment build
Agents need a test environment that mirrors production tools without touching live data, and that build is often the largest variable cost. It may involve sandboxed copies of connected systems, synthetic records and logging that captures every tool call. Ask whether the quote includes building this environment, who maintains it, and whether the client must supply licenses or seed data for third-party systems.
Quote checklist for fixed scope
A fixed-scope quote should name the agents, tools, identity providers, MCP servers and data stores in scope, along with the exclusions. It should state the test accounts, environment responsibilities, retest allowance and report format. Ask the provider to list the assumptions behind each line item, because changes to those assumptions are where scope creep usually starts.
When to run both and how the results feed each other
Run both when your system has a text and retrieval surface and also lets the model call tools under a real identity. An LLM application test covers prompts, retrieval sources, output handling and the web, API and data layers around the model. An agent test follows the agent's plan, its tool calls and the credentials those calls use. A chat assistant that only summarizes documents may need the first test alone. An agent that files tickets or changes records with a delegated token needs both, because a prompt injection found in the first test becomes much more serious when the second test shows what the agent can reach. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. That is the basis for combining the two, although no standard we are aware of requires agent testing specifically, so confirm the requirement with your regulator, customers and internal policy.
Run the LLM application test first when the retrieval index, system prompt and output rendering are still changing, because the agent test depends on knowing which untrusted inputs can reach the model. Map each finding to a list. Injection and sensitive data findings usually map to the OWASP LLM Top 10 2026, where Excessive Agency now sits at LLM03 and Hidden Context Exposure at LLM08. Findings about tool misuse, identity and privilege abuse, unexpected code execution and insecure inter-agent communication map to the OWASP Agentic Top 10 for 2026. Record the ATLAS technique IDs you used during testing too, including AML.T0133 for discovering agent runtime capabilities, so the report can be traced to a common technique catalog.
Feed the results into the MCP server review as well. Confirm that each MCP server rejects tokens not issued for it, because token passthrough is forbidden by the MCP authorization specification. For local servers, check that one-click configuration showed the exact command and required explicit approval, and that servers ran sandboxed with minimal default privileges. Give the agent test a single register of findings with owner, environment and retest date, and have the team that owns each tool fix its own items. Ask the testing provider to show in the scope document which of these checks are covered and which were left to your own review.
How DeployOpen scopes and delivers agent and LLM application testing
This sequence shows how a DeployOpen engagement moves from a written scope to a tested agent or LLM application, with a private test environment and clear evidence at each stage. Clients know what is tested, what they receive and how ongoing testing can continue after the first engagement.
Define the system boundary and inventory
DeployOpen and your team list every component in scope: the model endpoints, the agent or chat front end, retrieval sources, each tool and MCP server, the identities and tokens each component uses, and any agent-to-agent paths. Your team confirms which environments and data are in bounds. The step closes with a written inventory that both sides sign off, so later questions about coverage have a fixed reference.
Agree the written scope and rules of engagement
The scope document sets the test objectives, the OWASP Agentic Top 10 or LLM Top 10 risks to cover, the attack techniques allowed, any out-of-bounds actions such as writes to production systems, and the escalation contacts. Because most engagements are fixed-scope, deliverables and timelines are agreed in writing before work starts. Ask for a quote that itemizes these items. The step closes when the scope and rules of engagement are signed.
Provision the private test environment
DeployOpen works with your team to stand up a test environment inside your own cloud account, data center or network. It uses non-production data, test identities with minimal privileges, sandboxed tool endpoints and logging that captures agent tool calls and model traces. Your team confirms that no test action can reach live customer data or payment rails. The step closes when a smoke test shows the agent calls only the sandboxed tools and the logs record them.
Map agent identities, tools and token flows
Testers trace how each agent obtains credentials, which tools it can call with those credentials, and whether an MCP server accepts tokens issued for another service. This covers the token passthrough prohibition in the MCP authorization specification, confused deputy paths and the one-click configuration and approval steps for local servers. The output is a map of privileges and trust boundaries, which becomes the basis for the attack plan.
Execute scenario-based attacks on the agent
Testers run scenarios across tool misuse, identity and privilege abuse, unexpected code execution, insecure inter-agent communication and indirect prompt injection through retrieved content. Where the application is a chat or retrieval system, the same scenarios cover the LLM Top 10 items. Each attempt is recorded with inputs, tool calls, outputs and the authorization decision. Testers stop and report any action that would affect data outside the agreed boundary.
Test the surrounding web, API and data layers
Because an agent sits on top of ordinary services, testers also apply conventional application and API testing to the endpoints it calls and to the data stores it reads. This step checks authorization on each API, input handling, secrets exposure and logging of sensitive data. Findings are tagged by layer so the client can assign fixes to the right team. The step closes when every in-scope endpoint has a recorded result.
Deliver findings, retest and hand over evidence
DeployOpen delivers a written report that maps each finding to the agreed OWASP risk, shows reproduction steps and gives remediation guidance in the client's own terms. After fixes are made, testers retest the same scenarios and record the result. Clients receive the test evidence and configuration notes they need for their own assessors. DeployOpen prepares this evidence but does not issue audit reports or certifications. Retainers can extend retesting and continuous testing after the engagement closes.
