Intent
What task, instruction, or event caused the agent to act?
Back to AI Security
AI Agent Security Assessment
Review what your AI agent can access and change before launch.
Test one agent workflow: the data it can reach, the actions it can take, and the controls that should stop unauthorized behavior.
Why commission the review
An assistant can retrieve sensitive documents, change a ticket, draft a customer message or influence software delivery. The team needs to know which inputs can redirect those actions and which controls enforce the intended boundary.
Best fit: Engineering, security, product and AI platform leads preparing document assistants, support agents, internal tool users or coding workflows for broader access.
Scope
We follow one workflow through its model, memory, retrieval, tools and credentials. The review checks approvals, logs and downstream actions. Before testing, we confirm accounts, permitted actions, stop conditions and handling requirements in writing, using synthetic data and redacted materials first.
What you receive
Findings your team can test and fix.
You receive a workflow map, permission matrix, test records and prioritized findings. A launch memo explains what to restrict or fix before expanding access. Each recommendation identifies an owner and a check for confirming the change.
Timeline
We confirm the schedule once the workflow and test access are known. Added workflows or unavailable systems may change the delivery date.
Agent control path
Follow an agent action from request to result.
We trace the request, retrieved context, tool call and executing identity, then check where an operator can approve or stop the action.
Context
What memory, retrieval, or tool output influenced the decision?
Tool
Which tool, API, or workflow did the agent attempt to use?
Authority
Which identity, token, permission, and data boundary applied?
Operator
Where can a person approve, contain, roll back, or stop the action?
Common assessment scopes
Choose the review around the access you plan to grant. A coding agent, document assistant and customer-support agent expose different systems and need different tests.
The following examples help identify the right starting point.
AI-assisted CI/CD workflow review
Agents that read repository content, change code or influence build and release jobs.
Review focus
- Repository permissions, branch protection and merge approval
- Untrusted issues, comments and pull requests that influence generated changes
- Build and deployment triggers, credentials and commands
- Logs and artifacts needed to reconstruct a manipulated change
Use this before granting code, pull-request, build or deployment permissions.
MCP and tool-permission review
Agents connected to business systems through MCP, APIs or local tools.
Review focus
- Clients, servers, tool schemas and delegated credentials
- Read, write, delete, send, publish, approve, deploy and execute permissions
- Local-server exposure and malicious instructions in tool output
- Approval, logging, containment and stop controls
Use this before connecting an agent to tools or credentials that can change real systems.
RAG and retrieval-boundary review
Systems that retrieve documents, tickets, code or other material for a model to use.
Review focus
- Document, role and tenant permissions
- Prompt assembly and instructions embedded in retrieved material
- Source provenance, filtering and sensitive-data exposure
- Records of retrieved chunks, citations and generated answers
Use this before adding sensitive documents, new users or additional tenants.
Production-readiness Go/No-Go review
Teams deciding whether an agent can move beyond a limited pilot.
Review focus
- Data access, tool permissions and credential scope
- Human approvals and operator controls
- Abuse scenarios, deployment risks and monitoring
- Launch blockers, remaining risks and review owners
Use this to identify launch blockers, pilot restrictions and the controls to complete first.
For benchmark testing, see the AgentBoundary assessment. For an initial check of tool permissions, use the MCP checklist.
Assessment detail
The proposal identifies the systems and tests included. The report records findings, unavailable access and any checks that could not be completed.
Scope and required materials
Provide the intended workflow and decision deadline, a deployment and data-flow sketch, tool schemas, identity and connector scopes, data classes, approval rules and redacted trace examples. Initial contact needs a summary, not credentials or customer records.
Threat and control review
Map untrusted documents, messages and tool results to possible unauthorized reads or effects. Review current access checks, exact-action approvals, memory and cache boundaries, credential lifecycle, logging failures and containment. Record both allowed and denied cases.
Technical artifacts
The report records the inputs, versions, expected results, observed actions and downstream effects of each test. It also identifies systems we could not access and checks we could not perform.
Decision memo
The launch memo weighs a limited pilot, additional restrictions, a deferred rollout or further testing. It records the remaining risks and changes that would warrant another review. Your leadership team makes the launch decision.
Remediation and retest
Rank findings by reachable impact and affected authority. Agree separately on implementation support and a retest window; retest the changed control and nearby allowed and denied cases against an identified version.
Engagement limits
The report covers the tested workflow and conditions; it is not a certification or a guarantee against prompt injection. Production changes, destructive tests, social engineering, third-party systems and remediation require separate written authorization.
What the review covers
Test the controls around the agent's actions.
- Test cases cover both permitted actions and actions the system should reject.
- The report distinguishes vendor documentation, inspected settings and behavior observed during tests.
- A model, configuration or production change may require retesting; a staging result applies to the conditions tested.
When to use it
Before the agent gets more access.
Use this before adding write, send, execute or deployment authority; connecting a sensitive document source; expanding a pilot to another tenant; or approving a material change to the agent’s tools, memory or identity model.
Next step