AckuityRequest assessment AI AGENT SECURITY / PRACTICAL CHECKLIST
Put agent security to the test.
Twelve checks for the actions your agents take. Define the boundary, test it safely and keep evidence your team can review.
START WITH ONE WORKFLOW
An action. A decision. A result.
An AI agent security evaluation checks whether agents stay within authorized access and action boundaries across tools, data and other agents. Verify what reaches the target, including when the agent is mistaken or manipulated.
Open the checklistFOLLOW THE ACTION
01 / PROPOSAL
Who wants to do what?
02 / DECISION
Which policy permits it?
03 / TARGET
What actually changed?
A verdict alone is not outcome evidence.
BEFORE YOU TEST
Set the scope. Keep it controlled.
Use an isolated environment, synthetic data and approved test identities. Record the agent, tool and integration versions, policy, target, expected behavior and acceptance criteria. Run destructive or failure tests only with the environment owner’s authorization.
This worksheet is Ackuity’s practical evaluation method, informed by the sources below. It is not a complete audit, certification or evidence of completed Ackuity tests. An untested or excluded path remains outside the demonstrated coverage.
THE EVALUATION WORKSHEET
Twelve checks. Bring the evidence.
Open a check for the test and evidence to collect. Record your result when you have it.
Selections stay in this tab and reset on reload. Download to keep a record. Keep secrets and personal data out of notes. Download a blank CSV.
What can the agent reach?
01Identity and least privilegeCan you connect the action to the user, agent and credentials that authorize it?Not tested
TEST TO RUN
Use synthetic records. Give a test agent access to one collection, then request a record outside that scope. Check the target system’s own authorization as well as the agent policy.
EVIDENCE TO KEEP
Initiating identity, effective permissions, credential scope and the target’s access record.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
02Action-path coverageWhich paths can observe an action, and which can stop it before execution?Not tested
TEST TO RUN
Map API, MCP, shell, database and delegated routes that actually exist in your environment. Identify the enforcement point for each. Mark an untested route as unknown.
EVIDENCE TO KEEP
A route map naming the tool, destination, observation source, enforcement point and uncovered paths.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
03Untrusted tools, inputs and memoryCan external content change the agent’s authority or contaminate another session?Not tested
TEST TO RUN
In a sandbox, add an instruction to a test document, change a tool description and seed a separate session’s memory. Evaluate each attempt independently and inspect any resulting tool use.
EVIDENCE TO KEEP
Input origin, tool version, session boundary and the actions attempted after each change.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
What makes this action permitted?
04Hard policy boundariesDoes a prohibited action stay prohibited when the agent argues for an exception?Not tested
TEST TO RUN
Define a test policy that forbids a specific operation. Ask for it directly and through a claimed exception. Confirm that a reviewer cannot silently grant authority the policy forbids.
EVIDENCE TO KEEP
Policy version, proposed operation, authorization result and target outcome.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
05Context across actionsCan the evaluation distinguish a permitted task from a risky sequence using the same tool?Not tested
TEST TO RUN
Compare a permitted synthetic workflow with one that changes the target, data scope or purpose across steps. Review the relevant context and each decision instead of relying on tool names alone.
EVIDENCE TO KEEP
Task scope, ordered actions, changed context and the reason for each decision.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
06Approval scope and replayDoes approval cover the exact action, once, while it is still valid?Not tested
TEST TO RUN
Use an authorized operation that requires review. After approval, change its target or parameters, let it expire, and attempt concurrent reuse. Verify each variation needs the appropriate new decision.
EVIDENCE TO KEEP
Exact approved action, reviewer authority, expiry, consumption record and execution-time recheck.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
Can another path bypass it?
07Allowed and denied actionsCan legitimate work complete while a prohibited action leaves the target unchanged?Not tested
TEST TO RUN
Run one permitted write and one prohibited write against an isolated target. Match each control decision to the target’s audit record and final state.
EVIDENCE TO KEEP
Paired action IDs, expected result, actual target change and any mismatch.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
08Bypass and delegationDo alternate connections and child agents retain the intended access limits?Not tested
TEST TO RUN
Repeat a prohibited test through an available alternate tool, direct route, queued job and delegated agent. Record whether the same authority and enforcement boundary apply.
EVIDENCE TO KEEP
Parent and child identities, route, inherited scope and target-system outcome for each attempt.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
09Failure and in-flight workWhat happens when the control times out or an action is already queued?Not tested
TEST TO RUN
In a controlled environment, interrupt the decision service and inspect configured fail-open or fail-closed behavior. Check pending work, retries and duplicate execution before resuming.
EVIDENCE TO KEEP
Failure policy, timing, queued-action state and any target changes during the interruption.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
What happened in the target?
10Independent downstream evidenceDoes the target confirm what the dashboard says happened?Not tested
TEST TO RUN
Reconcile decision records with independently collected target logs or state. Treat a missing or ambiguous outcome as unknown. Protect the records from modification by the tested agent.
EVIDENCE TO KEEP
Correlated decision and target records, timestamps, protected storage and unresolved discrepancies.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
11Containment and recoveryCan you contain a rogue agent without assuming earlier effects disappear?Not tested
TEST TO RUN
Exercise selective blocking and, where supported, whole-agent termination. Check child jobs and delegated access. Reconcile completed effects before recovery from a known trusted state.
EVIDENCE TO KEEP
Containment scope, surviving activity or credentials, completed effects and recovery steps.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
12Performance and mistaken blocksWhat does the control cost legitimate work in this environment?Not tested
TEST TO RUN
Use a labelled set of legitimate and prohibited actions. Measure decision time separately from end-to-end overhead, review mistaken blocks and missed actions, and repeat after policy or integration changes.
EVIDENCE TO KEEP
Test-set definition, versions, latency distribution, denominators and reviewed error cases.
Evidence captured does not mean passed. Review the result against your acceptance criteria.
READ THE RESULT
Test the path you will use.
Evidence applies to the route, version and configuration you tested. A successful MCP test does not establish coverage for shell commands, a direct SQL connection or a hosted Copilot Studio action.
Ask what happens before execution.
Monitoring can reveal a risky action after it happens. Enforcement needs a supported control point before the target changes. Keep those results separate.
Keep useful work in the test set.
Compare permitted and prohibited operations. A control that blocks everything does not demonstrate usable action security.
AI security vs AI agent securityWHERE ACKUITY FITS
Evaluate the control switch, too.
Ackuity is the Agent Execution Control Switch. It assesses proposed actions using the Agent Security Context Graph, rules and small language models. Its response ladder is Allow, Constrain, Human in the loop, Block and Terminate.
Apply these same checks to the integration you plan to use. A Kubernetes sidecar and the Copilot Studio API integration have different connection paths. Event pull is observation. The checklist does not claim that every deployment implements every control described here.
METHOD & SOURCES
Built on guidance you can inspect.
Sources checked October 24, 2026. Test scenarios and worksheet structure are Ackuity’s synthesis. These references do not endorse Ackuity or certify the checklist.
- OWASP AI Agent Security Cheat Sheet
Agent access, input and memory protection, monitoring and adversarial testing.
- OWASP Excessive Agency
Limiting tool capabilities, permissions and autonomy.
- OWASP Transaction Authorization Cheat Sheet
Binding approval to the transaction and checking it again before execution.
- MCP Security Best Practices
MCP authorization, token handling and protocol-specific threats.
- OWASP Top 10 for Agentic Applications 2026
A broader agentic risk framework to use alongside this focused worksheet.
YOUR QUESTIONS, ANSWERED
Before you take the next step.
What should an AI agent security evaluation include?
Evaluate identity and permissions, action-path coverage, untrusted inputs and memory, policy and approval decisions, enforcement, failure behavior, downstream evidence and recovery. Test legitimate work as well as prohibited actions, and record the exact environment and integration tested.
Does completing the checklist certify a product or deployment?
No. This is an evaluation worksheet, not certification, a comprehensive audit or a completed Ackuity benchmark. Evidence captured means you recorded a result, not that the control passed. Your team must review gaps, scope exclusions and acceptance criteria.
How is this different from an Agent Exposure Assessment?
The checklist helps you plan and record controlled tests. Ackuity’s 30-day Agent Exposure Assessment reviews agreed telemetry to map exposure and prioritize findings. Observation alone does not establish that an action can be blocked.
NEXT STEP
Start with your agent exposure.
The 30-day Agent Exposure Assessment reviews agreed telemetry and gives your team findings and priorities. Inline control tests are a separate evaluation.