# Before giving an agent write access
Check that allowed changes, approvals, logging, reversal and ownership are explicit before an agent can affect business data.
## Scope and authority
- [ ] The exact systems the agent may change are named.
- [ ] The allowed record types and fields are named.
- [ ] Allowed actions are separate from technically possible actions.
- [ ] Prohibited actions are explicit.
- [ ] Limits such as amount, region, customer type or working hours are explicit.
## Approval
- [ ] Actions requiring approval are observable and testable.
- [ ] The approver has enough context to judge the action.
- [ ] Approval is recorded before execution.
- [ ] The executed change is exactly the change that was approved.
- [ ] Rejection and escalation paths are defined.
## Failure and recovery
- [ ] Failed actions are detectable.
- [ ] Partial completion cannot remain hidden.
- [ ] Duplicate actions are prevented or safely handled.
- [ ] A person can correct or reverse an incorrect result.
- [ ] The fallback path works when the target system is unavailable.
## Evidence and operations
- [ ] Every write action is logged with time, target and outcome.
- [ ] Important source information or decision evidence is retained.
- [ ] Edge cases and prohibited cases have been tested.
- [ ] One person owns the workflow after launch.
- [ ] There is a clear way to pause write access.
In 30 seconds
Write access changes the risk profile because the system can affect real business data. Define the exact changes it may make, when a person must approve and how incorrect actions can be detected and reversed.
Scope and authority
The exact systems the agent may change are named.
The allowed record types and fields are named.
Allowed actions are separate from technically possible actions.
Prohibited actions are explicit.
Limits such as amount, region, customer type or working hours are explicit.
Approval
Actions requiring approval are observable and testable.
The approver has enough context to judge the action.
Approval is recorded before execution.
The executed change is exactly the change that was approved.
Rejection and escalation paths are defined.
Failure and recovery
Failed actions are detectable.
Partial completion cannot remain hidden.
Duplicate actions are prevented or safely handled.
A person can correct or reverse an incorrect result.
The fallback path works when the target system is unavailable.
Evidence and operations
Every write action is logged with time, target and outcome.
Important source information or decision evidence is retained.
Edge cases and prohibited cases have been tested.
One person owns the workflow after launch.
There is a clear way to pause write access.
What this checklist does not prove
Completing the checklist does not prove that an agent is safe or ready for production. The actual permissions, implementation, test results and operational controls still need review in their real environment.
