# AI agent assurance

Test tool privileges, human approval and the stop path together.

SecNet.Work | 2026.10 | 2026-10-21

An agent can change system state through tools rather than merely produce text. Treat model output as potentially untrusted and enforce action authority separately from the model. ISO/IEC 42001:2023 addresses management systems; ISO/IEC 42005:2025 provides impact-assessment guidance. The NIST AI Agent Standards Initiative is evolving; it does not itself confer product conformity or agent certification.

## Work boundary
Enterprise support, document processing and action-taking agents. Use synthetic data and inert tools in tests.

## Process

### 1. Define action boundaries
List readable sources, writable systems and outbound data paths. Identify the business owner, identity and time limits for each tool. A system prompt is not an access control.

Expected evidence: Tool–permission–data map

### 2. Assess impact
Assess effects of incorrect actions on customers, data and operations. Define where human intervention is needed and what the reviewer can actually see. Do not default to sensitive personal data as test input.

Expected evidence: Impact record and human decision point

### 3. Test trust boundaries
Use a synthetic example to verify that external document instructions cannot expand tool authority. Enforce output validation, allowed destinations and action budgets in the application. One successful test is not a general security guarantee.

Expected evidence: Test input, expected and observed result

### 4. Exercise approval and stopping
Show the real destination, scope and consequence during approval. Require fresh approval if the approved action changes. Exercise emergency stopping with queued jobs, active sessions and rollback limits.

Expected evidence: Approval-bound action and stop record

### 5. Reassess after changes
Refresh test scope after model, tool, data-source or permission changes. Link version and incident records. Assign residual risk; do not leave the agent running indefinitely without monitoring.

Expected evidence: Version-bound evaluation and monitoring

## One control, three perspectives

### Operator
Which actions can the agent take?
Restrict tool identity and run negative tests.
Evidence: Tool policy and test trace

### Auditor
Is approval bound to the real action?
Test reapproval when a destination changes.
Evidence: Action summary and attributable decision trail

### Leader
Can an incorrect action be stopped?
Review impact and stopping limits with the owner.
Evidence: Impact and recovery record

## Evaluate evidence

**Claim:** Human approval constrains data transfer.

**Weak support:** The prompt says “ask first”.

**Stronger support:** Application approval binds destination and data scope; a changed destination is rejected, as shown by tests and logs.

**Rationale:** Model compliance and application authorization differ. Evidence must show the actual action boundary.

## Decision desk
A support agent reads an external PDF and can modify CRM records.
Start: start

### start
What do you inspect first?

- **Separate source content from tool authority and test synthetically** (good)
  You are looking for a boundary that prevents untrusted text from granting action permissions. Verify approval binding next.
  Next: verify

- **Only add “ignore malicious instructions” to the prompt** (risk)
  A prompt alone does not enforce authorization. Test tool-enforced permissions and destination limits.
  Next: repair

- **Close without a rationale** (incomplete)
  Deferring an open issue is not closure evidence. Record the uncertainty, owner and next verification step.
  Next: revise

### verify
After approval, the tool can write to a different destination.

- **Bind approval to the action summary and reject changed destinations** (good)
  The approved action and executed action must match. Negative tests for changes and reapproval are planned.
  Next: planned

- **Accept the claim without testing** (risk)
  The initial claim and observed result differ. Support closure with a repeatable check in the same scope, rather than a promise or ticket status.
  Next: revise

### repair
The agent started unexpected bulk changes.

- **Stop tool authority, inspect the queue and record impact** (good)
  Stopping is more than a UI button. Handle active jobs and identity privileges together.
  Next: planned

- **Delete the earlier record and close** (risk)
  Deleting the earlier decision undermines learning and accountability. Link the new action to the prior record and keep the rationale and residual risk visible.
  Next: revise

### supported
This decision is supported by the evidence in the example. Verify closure conditions in your own scope.

### revise
The decision lacks support. Record the rationale and required evidence, then reassess.

### planned
A remediation path is defined. Keep the matter open until implementation and verification are complete.

## Worked example
Entirely fictional.
- Agent: AI-001
- Tool / action: CRM write
- Data: Synthetic customer
- Permission owner: Support process owner
- Approval condition: Destination + fields approved
- Negative test: Destination change after approval
- Observation: Action must be rejected
- Action: Add to version tests

## Closure checklist
- [ ] Tool and data paths mapped.
- [ ] Authorization enforced by the application.
- [ ] Negative approval and stop tests exist.
- [ ] Version changes trigger reassessment.

## Official sources
- [NIST — AI Agent Standards Initiative](https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative)
- [ISO/IEC 42001 — AI management system overview](https://www.iso.org/standard/42001)
- [ISO/IEC 42005:2025 — AI impact assessment overview](https://committee.iso.org/standard/42005?browse=tc)

https://secnet.work/learn/toolkits/ai-agent-assurance