AI Agent Governance: Permissions, Approvals and Audit Trails

Draw the boundary before connecting tools

Most agent risk begins with an ambiguous tool boundary. “Can use the CRM” is not a permission: it says nothing about which records may be read, which fields may be changed or how much money an action may commit. A useful permission names the principal, resource, operation, scope and expiry.

For example, an agent may read aggregated invoice aging for one workspace, but may not export individual customer records or send messages. A separate action request can ask to contact a defined cohort. The system that owns the action evaluates that request; the model does not grant itself access.

A safe path from prompt to action

Keep reasoning, authorization and execution in different steps. The agent receives only the business context it needs, returns a structured proposal and never receives a direct production write credential.

• Identify the agent and the human or service on whose behalf it acts.
• Validate the proposal schema and resolve every referenced metric to a trusted, versioned definition.
• Run deterministic checks for scope, sensitivity, budget, rate limits and duplicate requests.
• Ask a person to approve when the policy or business impact requires it; show the expected effect and exact action.
• Execute with an idempotency key and capture the result, including failure and compensation paths.

What an audit trail must answer

An audit event should make a later review possible without replaying a chat transcript. Record the actor, delegated identity, tool and policy version, input data references, proposed action, decision, approver, timestamp, execution result and outcome link. Sensitive values can be referenced or redacted; the evidence chain still needs to be intact.

A rejected action is part of the trail too. It explains whether a model asked for an operation outside its scope, a data quality gate failed or a human declined. Those are different signals and lead to different fixes.

Example: a collection agent

Suppose an agent proposes sending reminders to 40 overdue accounts. Its proposal contains the cohort definition, message template and estimated total balance. The policy service removes disputed accounts, checks contact preferences and identifies the five high-value accounts that require approval. Only the approved subset reaches the sending service. The ledger records both the sent and withheld groups, with reasons.

This pattern works even if the agent changes models. Governance belongs to the business system, where permissions and evidence can remain stable across model upgrades.