An agent's permission is only the start of the decision

An agent can hold a valid credential and still propose the wrong action. Access control tells you which operations an identity may request. A consequential decision can also depend on the business purpose, the target, the amount, the timing, and the person responsible for the work.

This post walks through one hypothetical case and the questions that turn a permission into a decision.

What could the agent technically do, what did the task allow, and what did it actually do? Trace all three for one action.

A hypothetical cleanup

Imagine an agent that helps a support team maintain customer cases. It can update records because its job requires that permission. During a cleanup task, it proposes deleting an archive of attachments.

The credential may permit deletion. The team intended to correct a few labels. The permission was valid, and the proposed action still deserves a second look.

Five questions between a credential and an action

Each layer below asks a different question. A request that passes the first row can still need an answer to the next four.

Identify both sides of the delegation

Record the person or service that assigned the work and the agent that performed it. If an agent delegates again, preserve that relationship where the environment supports it.

A shared account name alone may not explain who authorized the task. When the record shows a named delegator and a distinct agent identity, a reviewer can answer who asked for the work and which agent carried it out.

Revocation gets easier too, because you can disable one agent without touching a person's access. See giving AI agents identities you can revoke for more.

Describe the action precisely

Which operation is requested, on which resource, with which relevant arguments? A policy can distinguish editing one label from removing a collection. It can also limit the set of records an agent may touch or require approval above a defined impact threshold.

Policies at this level need data to work with. Confirm that the enforcement point can see the target and the arguments. If it can see only the tool name, the policy cannot tell a label edit from a bulk delete.

Watch for sequences too. Several small refunds might each pass a per-request limit and together exceed the refundable balance of an order. When the business has a limit across actions, write that limit into the policy, and keep a stable request ID so a retry is recognized as the same action.

Make approval specific

The reviewer should see the proposed change and the context needed to decide. Bind the decision to that request, and define when it expires. If the target, the arguments, or the relevant permissions change, decide whether the approval must be requested again.

An approval request should show five things.

• Who and what. The delegating person, the agent, and the system it belongs to.
• The action. The operation, the resource, and the relevant arguments.
• The reason. The task the agent says it is performing.
• The impact. How many records or what value would change.
• The expiry. When the approval stops being valid.

An approval to delete one archive should not cover a later request to delete the whole collection. Test that case on purpose. Our MCP governance checklist includes the same changed-argument test for tool calls.

Avoid asking people to approve everything

Repeated low-value interruptions can obscure the decisions that need judgment. Define a supported class of routine actions, test that it proceeds correctly, and reserve escalation for the situations your organization has chosen to review.

For example, a team might allow label edits on cases it owns without approval and require a person's confirmation for deletions. The aim is a short queue where each item deserves attention. The glossary entry on human-in-the-loop covers the pattern.

Test the full path to the service

A policy applied to one tool route may not cover a direct API or another credential. Record that boundary explicitly. A successful authorization check at the beginning of a task does not prove that each later action received the same scrutiny.

Credential brokering narrows the number of paths, since the agent receives a scoped capability and never holds the raw key. It still deserves a test. Try the same action through each route in scope, and note which routes the policy covers.

How the cleanup case should end

Return to the hypothetical cleanup. A well-governed run looks like this.

1. The agent edits the labels it was asked to fix, and the routine edits proceed without interruption.
2. The agent proposes deleting the archive, and the request is held for approval.
3. The reviewer sees the target, the arguments, and the original task, and rejects the deletion.
4. The record shows the delegator, the agent, the held request, the rejection, and the policy version in force.

The agent finished the real job. The routine edits ran without interruption, and the one risky request got a human decision.

Preserve the decision

Keep the decision in a form another person can inspect. Record the actor, the request, the policy version, the approval, the execution result, and any missing context. Keep sensitive payload collection proportionate to the evidence you need.

Our post on what an AI audit log should contain lists the fields that make this record useful.

How Halo helps

Halo's policy engine supports tool-level checks, and human approval gates cover higher-impact actions. Halo keeps agent identity separate from user identity, credentials, tools, and action scope, and credential brokering keeps provider and app credentials bound at the gateway so agents receive scoped capabilities and never see raw keys. Decisions, approvals, and denials are recorded and export as CSV and JSON. Ask for a walkthrough that traces one action from delegation to evidence, or read about AI agent governance.