An agent should not receive access because its goal sounds useful. “Manage supplier onboarding” leaves open whether it may read identity documents, change a vendor record, approve payment details, contact a supplier or override a failed check.
The direct answer is to define permitted tasks, approval thresholds, escalation conditions and recovery before the agent receives consequential access.
A goal is not an authority specification
A useful goal explains the outcome. An authority specification explains the limits of action. It names the task, allowed inputs, tools, records that may change, conditions requiring review, conditions requiring escalation and the route back to a safe state.
NIST's AI RMF asks organisations to define tasks and methods, establish accountability and document human oversight. That external guidance supports the need for explicit governance. The matrix below is netlinkE's practical framework for applying it to an agent.
The agent authority matrix
| Dimension | ACT | REVIEW | ESCALATE | RECOVER |
|---|---|---|---|---|
| Task | Complete the declared, low-consequence task | Prepare a consequential action for approval | Stop when the request exceeds scope | Cancel or reverse incomplete work |
| Data | Read approved fields for the task | Request access to restricted or ambiguous data | Report missing provenance or policy conflict | Remove temporary data and restore access state |
| Tools | Use allow-listed operations with bounded parameters | Present a proposed irreversible or external action | Refuse unavailable or undeclared tools | Revoke token/session and reconcile side effects |
| Business record | Make reversible, attributable updates | Queue material state changes for an owner | Halt on conflicting source-of-truth records | Restore prior version or create corrective transaction |
| Communication | Draft or send low-risk, pre-authorised messages | Require review for commitments or sensitive content | Route complaints, threats or exceptions | Recall where possible and notify the owner |
| Money/legal effect | No independent authority unless explicitly bounded | Named human approval | Always escalate outside threshold | Freeze, reverse where possible, preserve evidence |
Each cell needs an operational rule, not a colour. “Human in the loop” is incomplete unless the reviewer, response time, evidence shown and default behaviour on timeout are known.
Define permission at the operation level
Do not grant “CRM access” when the task requires reading three fields and adding a draft note. Specify resource, operation, scope, duration and environment. Separate read from create, update, delete, send, approve and administer. Use the narrowest credentials the system supports, and assume platform permission models can change.
This is a change-sensitive area. Verify actual provider documentation, account settings and tool behaviour immediately before deployment and after material platform changes. A design document is not proof of the permission currently enforced.
Make context inspectable
An agent needs more than information; it needs a way to distinguish instruction from evidence. Record where context came from, when it was retrieved, which version was used and which constraints applied. Treat user content, retrieved documents and tool output as inputs with different authority, not as one undifferentiated prompt.
For a consequential proposed action, preserve the decision context that a reviewer needs: task identifier, sources used, relevant rules, proposed change, confidence or uncertainty where meaningful, and the reason for review.
Design the failure states first
List foreseeable failures before the happy path: missing data, contradictory records, unavailable tools, duplicate requests, partial writes, approval timeout, policy conflict and an external system accepting an action while the agent believes it failed.
For each failure, choose one response: retry safely, return to review, escalate, compensate, or stop. Retries require idempotency; rollback requires a verified mechanism; compensation must acknowledge when a true reversal is impossible.
Expand authority only after evidence
Broader authority should require evidence from representative work, not confidence in a demonstration. Review outcome quality, false actions, missed escalations, recovery success, reviewer burden and changes in the operating environment. Expansion is justified only when the new action is bounded, observable and recoverable in proportion to its consequence.
The strongest agent design is not the one with the most access. It is the one whose useful authority can be explained before an action, observed during it and reconstructed afterwards.
Sources and scope
NIST AI RMF and Playbook materials provide external governance context. The ACT–REVIEW–ESCALATE–RECOVER matrix and authority expansion test are original netlinkE framework and recommendation. Platform-specific permissions are intentionally not asserted here because they must be verified against current official documentation at deployment.
