A security review for an AI agent maps who will use it, what information it handles, which systems it can reach, and how the team will respond to failure or misuse. Use the review to decide whether a bounded test can proceed and which issues must be resolved first; it is not a security certification.
Start with one supplier-document request
A procurement team asks an agent: “Compare this supplier packet with the approved onboarding requirements. Identify missing documents and prepare a request for review. Do not send a message or change the supplier record.” In a fictional access test, the agent reads the assigned packet and requirements. The send and update operations are denied, but the supplier-record scope has not been verified. A reviewer is responsible for any outgoing request.
The completed security intake records the verified test results and keeps expansion on hold:
Supplier-document review — security decision
- Information: Submitted packet and approved requirements; a named owner maintains each source.
- Identity and audience: Authorized procurement staff request and review the work; the public surface has no access to the packet.
- Capabilities: Read the two approved sources and prepare draft text. Sending and supplier-record changes are outside scope.
- Test result: Assigned packet and requirement were readable; send and update operations were denied. Supplier-record scope remains unverified.
- Decision: Hold expansion until the record scope and exception path are confirmed.
The sample separates what the workflow intends from what the connected systems must enforce. A written instruction is not evidence that a tool cannot perform a restricted action.
Use the resource-and-action matrix as one part of the wider security review.
Work through the security questions
Scroll horizontally to see all columns.
| Review area | Questions and evidence |
|---|---|
| Purpose, users, and data | What exact task is in scope? Which people use the agent, what data enters, and which output may affect a person, record, or process? Draw the path from source to model, tool, and recipient. |
| Identity and access | Which user, service, or application identity makes each request? Can the connected system limit that identity to the required records and operations? How are credentials protected, rotated, and revoked? |
| Tools and side effects | List each tool, operation, read/write scope, and consequential action. Can it send, publish, update, delete, or approve? Remove capabilities the job does not need and test that blocked actions are rejected by the connected system. |
| Untrusted input and output | Can a user, document, or retrieved page contain instructions that conflict with the job? Check how untrusted content is treated and whether generated output is validated before another system acts on it. |
| Dependencies and exposure | Identify model, connector, service, library, and data dependencies. Check where information is sent, what is returned, and which parties can access the stored records. |
| Testing and response | Try ordinary, malformed, conflicting, out-of-scope, and deliberately misleading inputs. Name the security contact, incident route, operator, records available for investigation, and condition for pausing the workflow. |
Choose review depth according to the data, audience, actions, and consequences. A pilot that only prepares a draft still needs boundaries, but an agent that reaches sensitive systems or can trigger external changes deserves closer security and privacy review.
Keep security approval separate from workflow quality
Security review asks whether the access paths, data handling, and controls are appropriate for the proposed deployment. Evaluation asks whether the agent produces useful and accurate results on representative work. Human review decides whether an individual result or action is acceptable. A successful test in one area does not settle the others.
For the supplier example, the reviewer can approve a limited pilot only after a test confirms that the agent can read the intended packet and requirements, cannot send or update, and leaves a clear handoff when a source is unavailable. Record the tested configuration and outstanding issues. If the actual permission behavior is unknown, keep the pilot on hold.
Revisit the review when users, data sources, model, tools, audience, or output actions change. For per-tool checks, see review an agent’s tools and data access; for outcome testing, see how to evaluate an AI agent. The broader permissions and boundaries guide covers the agent’s information and action limits.