Capability isn't approval
An integration may be technically capable of reading every customer, modifying any order, or issuing an unrestricted refund. That doesn't mean the agent should inherit the full capability. Business authority is narrower than technical possibility. Define the smallest useful job first, then grant only the systems, record scopes, tools, actions, and thresholds required for that job. The target system should continue to enforce its own controls, while the governed agent path adds the workload-specific boundary and evidence.
Scope authority across six dimensions
Tool allowlists alone are not enough. The same tool can contain both harmless and consequential actions, and a permitted action can still be unsafe on the wrong record or at the wrong amount. Define authority across the target system, data or record scope, tool, action type, business threshold, and time or environment. Include whether the agent acts independently, on behalf of a person, or only after a defined review. These dimensions turn "may use the CRM" into a rule that can be tested.
- System: which application or environment may be reached
- Scope: which organisation, customer, record type, or data class may be used
- Tool: which interface or capability may be invoked
- Action: read, create, update, submit, approve, delete, or transfer
- Threshold: amount, risk tier, confidence, volume, or other business limit
- Context: the delegated person, purpose, location, time, and review state
Check authority when the action is requested
An agent can operate for minutes or hours while data, ownership, policy, and delegated access change. Do not assume that an earlier permission check remains valid for every later step. Re-evaluate consequential actions against the current identity, resource, policy version, arguments, and business state. Validate action parameters before execution. Record the decision and the reason. This is especially important for retries, queued work, long-running sessions, and multi-agent handoffs.
Design explicit allow, block, and review outcomes
A useful access-control model does more than return yes or no. It may allow an action, narrow its scope, remove protected fields, block it, or route it to review. The fallback must be defined before the run. For a refund above the agent's limit, the policy can block the payment action while allowing the agent to create a review ticket. The customer receives a normal processing message, while the internal record shows the attempted amount, applicable limit, policy result, and fallback.
Use delegated access without hiding the agent
Some agents act for a signed-in person. That person's permission is relevant, but it shouldn't erase the workload identity or automatically grant everything the person can do. The action should satisfy both the delegated context and the agent's approved job. Record who requested the work, which agent executed it, which authority applied, and which system accepted the change. This supports investigation and prevents a broadly privileged person from unintentionally turning a narrow agent into a general-purpose actor.
Review and revoke authority through the lifecycle
Permissions should change when the job, owner, model, tools, integrations, target systems, or risk profile change. Review standing access, unused permissions, exceptions, and repeated blocks. Make revocation effective across credentials, tokens, schedules, queues, tool registrations, and active sessions. A kill switch that changes a dashboard status but leaves usable credentials or running tasks is incomplete. Test revocation as part of production readiness and incident exercises.
Write permissions as a testable authority envelope
A useful permission can be executed as a test and explained to a business owner. For example: claims-intake agent may read documents for the claim bound to this run, attach a verified document reference, and request a missing document during the next 30 minutes. It may not change coverage, approve payment, deny a claim, access another customer, or reuse the credential after expiry. Test one allowed action and every adjacent prohibited action before production.
- Subject: agent identity, version, owner, and delegated principal
- Purpose: approved job and bound case or transaction
- Resource: organisation, customer, record, field, tool, and destination
- Action: operation plus validated arguments and thresholds
- Conditions: time, environment, business state, and review state
- Resolution: allow, narrow, transform, review, block, or stop
- Lifecycle: issue, expiry, revalidation, revocation, and evidence
Frequently asked questions
What permissions should an AI agent have?
Only the systems, records, tools, actions, thresholds, and duration required for its approved job, with an explicit fallback for work outside that boundary.
Can an AI agent inherit a person's permissions?
It may use delegated context from the person it acts for, but the action should still be limited by the agent's own approved job and the target system's controls.
Where should an AI agent permission check happen?
Consequential actions should be checked at the action boundary using current identity, resource, policy, arguments, and business context before the target system changes.
How do you revoke an AI agent?
Remove its authority across credentials, tokens, integrations, tools, schedules, queues, and active sessions, then verify that new and in-flight actions stop as intended.