AI agents fail differently than chatbots. A chatbot can say something wrong; an agent can do something wrong. The risk moves from text quality into permissions, tool execution, data access, workflow state, approval gates, and auditability. If your AI can search, write, send, buy, refund, update, delete, message, or schedule, the security question is no longer just “what does it answer?”
This assessment tests whether an agentic workflow can be steered into unsafe actions, excessive access, data leakage, or policy bypass.
Who it is for
You are building or selling an AI feature with tools attached: browser automation, CRM updates, support actions, ticket routing, refunds, file operations, database queries, email, Slack, calendar, code changes, billing, procurement, or internal operations. The agent may be customer-facing, employee-facing, or embedded behind another workflow. If it can take action, it needs a security review before a buyer or attacker writes the test for you.
What we test
Tool inventory and permissions
We map every tool the agent can reach, what each tool can do, which user or service identity it runs under, and which operations are destructive, privileged, external, financial, or cross-tenant. Over-broad tools are often the root cause of agent findings.
Prompt injection to tool abuse
We test whether direct user input, retrieved content, files, messages, emails, tickets, or web pages can cause the agent to call a tool it should not call. For multi-step agents, we test whether a poisoned early step changes a later action after the dangerous context is no longer visible.
Authorization and tenant boundaries
The model is not an authorization system. We verify that each tool enforces user, tenant, role, object, and business-policy checks outside the model. A refusal in the prompt is useful, but a server-side permission check is what matters.
Confirmation and human-in-the-loop gates
We test whether the agent can satisfy its own approval requirement, skip confirmation, compress a dangerous action into a benign-looking summary, or exploit ambiguous UI state. For state-changing actions, confirmation gates must be external to model text.
Memory and state
We inspect whether memory, scratchpads, summaries, and workflow state can carry poisoned instructions or sensitive data across users, tenants, sessions, or tasks. Agent memory can turn a one-time prompt injection into a persistent defect.
Logging and incident evidence
If an agent misbehaves, you need to reconstruct the path: user input, retrieved context, model output, tool call, tool result, and final user-facing response. We test whether that trace exists and whether sensitive content is handled appropriately.
What you get
- An agent system map: tools, scopes, identities, approval gates, memory, retrieval, and external integrations.
- Reproducible findings with model turns and tool-call traces.
- Severity mapped to real business impact: data exposure, unauthorized action, financial loss, operational damage, or procurement blocker.
- Framework mapping to OWASP LLM Top 10, OWASP Agentic Security Initiative, MITRE ATLAS, and NIST AI RMF where relevant.
- A prioritized fix plan and one retest pass.
Common fixes
Agent fixes usually involve architecture, not prompt polish:
- Split high-risk tools into narrow, typed, policy-checked operations.
- Enforce authorization inside the tool service, not in the model instruction.
- Require external confirmation for financial, destructive, or external-message actions.
- Treat retrieved and user-provided content as untrusted data.
- Store and replay tool-call traces for audit and retest.
- Add evals that fail when a prompt or model change reopens the same path.
Where this fits
If your agent is part of a broader AI product review, use the AI Product Readiness Assessment. If the agentic workflow is the risky surface, scope an agent assessment. The AI agent security guide explains the failure modes in more detail, the sample report shows the evidence format, and trust and data handling explains how scope, access, confidentiality, and retest are handled. The public verification profile collects the proof links a buyer can inspect before signing. The full test approach lives in our methodology.