In short
- Separate reading, proposing and changing records.
- Enforce permissions in the system that executes the action.
- Bind approval to the exact proposal and current record.
- Resolve uncertain outcomes before retrying a write.
An assistant can summarise a customer request convincingly, so the team wants it to update the CRM, issue a refund and notify the customer. These actions carry different consequences. Fluent text is not evidence that the system should be allowed to perform all of them independently.
Separate reading, proposing and acting
List the tools available to the agent and classify them by effect. Reading a public help article, drafting an internal note and changing a financial record are different permissions. Start with the narrowest workflow that solves a real problem. Keep the final authority in deterministic server controls rather than relying on an instruction that asks the model to behave. A prompt is not an access-control boundary.
Make approval specific
An approver should see the proposed action, the affected record, relevant evidence and the expected consequence. Approval of a summary should not silently authorise a different transaction. Check that the underlying record has not changed between approval and execution. Keep a clear expiry or revalidation rule for stale proposals. Use synthetic scenarios to test missing evidence, conflicting instructions and attempts to obtain another customer's information.
Plan recovery and evaluation
Record the action outcome and the version of the workflow used, without logging secrets unnecessarily. Define a stop switch and the process for reviewing failures. Evaluate useful task completion, incorrect actions, unnecessary escalations and recovery effort together. A system that avoids every error by refusing every task is not useful; one that completes tasks by exceeding permission is not acceptable.
NIST provides a risk-management framework for AI systems. Use it as a governance reference while designing concrete controls and evaluation for the specific workflow. NIST AI risk-management framework.
Controls to define before an agent can write
- Inventory tools by read and write impact.
- Require meaningful approval for sensitive actions.
- Revalidate records before execution.
- Test refusal, escalation and recovery paths.
Approve a refund separately from a draft reply
An agent might propose a CRM classification and draft a reply while requiring a human to approve a refund. This is an illustrative scope choice; the actual boundary depends on policy, risk and the available controls.
Write an approval record that the server can enforce
For each proposed write, show the system and record, the current value, the requested change, its source evidence and the person authorised to approve it. Bind approval to that exact proposal and record version. If the amount, recipient, record or evidence changes, evaluate the new proposal rather than reusing the old approval.
| Illustrative action | Boundary to define | Evidence before execution |
|---|---|---|
| Read an assigned customer record | Access limited to records the user may view | User, tenant and record permissions pass |
| Change a lead stage | Only permitted transitions and approved fields | Current stage and supporting evidence match the proposal |
| Issue a refund | A separate authorised financial approval | Record, amount and currency still match the approved request |
These are example boundaries to agree for a specific system, not a claim that every tool supports them. OWASP guidance on excessive agency recommends restricted capabilities, approval of consequential actions and authorisation enforced by downstream systems.
Handle an unknown outcome without repeating the action
If a connection fails after a write, the system may have accepted it even though the agent did not receive confirmation. Record an operation reference and inspect the authoritative result before retrying. If the outcome remains uncertain, send the case to an assigned person instead of allowing an unbounded retry loop. Some actions cannot simply be undone, so document the recovery path for each tool.
For the wider sales workflow, see AI-powered CRM automation. Bring one proposed workflow, its tools, permitted record changes and existing approval rules to an initial scoping call.
Design an agent’s authority before its tools
Begin with a permission map, a reviewable approval interface and evaluation cases tied to each action’s consequences. The Night Marketer can help scope this work through our AI agent development.
Frequently asked questions
The workflow can allow bounded low-impact actions under a defined policy, while consequential actions require the agreed review. Make that distinction explicit in tool permissions and server checks. Do not let a broad approval to draft a response silently permit a different write or financial action.
Revalidate the proposal against the current record and approval scope. If a relevant field, recipient, amount or evidence has changed, request the approval required for the revised action. A stale approval should not authorise a new transaction.
Bring one workflow, the systems and tools it needs, the records it may read or change, current user permissions and the approval rules. Include examples of missing evidence, failed requests and exceptions so evaluation covers the actual operating conditions.
