How to Scope AI Agent Permissions

An agent is not one permission. It is a changing set of models, tools, tasks, targets, parameters, policies, and execution paths.

Approving the whole agent asks reviewers to accept consequences that have not been defined.

A useful approval applies to one action class. It states what can change, for whom, why, where, within which limits, and until when.

We call that contract an Agent Action Boundary.

“Approve the agent” is the wrong unit of control

An AI agent can read data, select a tool, prepare a change, request approval, perform the change, verify the result, and decide what to do next.

Those steps do not carry the same authority.

Reading a customer record is not the same as changing it. Preparing a refund is not the same as submitting it. Sending a draft to an approver is not the same as sending it to a customer.

The agent may also gain new capabilities over time. A new MCP server, browser tool, model, or workflow path can expand what the product can attempt.

That expansion must not silently expand what the agent may do.

Approval should attach to an action class such as:

Update the status field on eligible onboarding cases from verified to ready_for_provisioning in the EU production tenant, after named approval, within 15 minutes.

That sentence is still incomplete, but it is reviewable. “Allow the onboarding agent to manage cases” is not.

Start with the exact state change

An action boundary begins with a verb and a target.

Avoid phrases such as “manage the account,” “handle the ticket,” “process the claim,” or “update the CRM.” Each phrase hides several possible changes.

Define these fields:

Boundary field	Question
Action verb	What exact operation can occur?
Target system	Which system receives the write?
Record or resource	Which object can change?
Eligible state	Which current states permit the action?
Allowed fields	Which properties may change?
Parameter range	Which values, amounts, or options are valid?
Tenant and environment	Where may it run?
Volume and frequency	How much may it change?
Denied actions	What must never occur through this path?

A narrow tool schema helps, but the schema is not the complete policy.

The application must still compare the requested action with the current principal, task, state, environment, approval, and policy version.

Bind the action to a principal and task

Authentication answers who the agent is. Authorization answers what it may do. Delegation answers why it may perform this action now.

The delegating principal may be a person, a business role, or an approved process. The delegation must point to a purpose and request or case identifier.

The execution record should preserve:

the delegating principal;
the principal role;
the business purpose;
the request or case ID;
the agent identity and version;
the policy version;
the tenant and environment;
the start, expiry, and early-revocation condition.

This creates a run-bound authority chain.

It prevents a valid user request from becoming open-ended authority for every action that an agent later decides is helpful.

It also improves audit quality. A shared service credential may prove which connection reached the API. It does not prove who delegated the action or why the policy allowed it.

Separate discovery, eligibility, and permission

Tool discovery answers which capabilities exist. It does not answer which capabilities belong in the current workflow.

Eligibility answers which tools may be considered for this workflow. It does not approve their use in the current task.

Task authorization answers whether this principal, task, target, and state may use the eligible tool now.

Parameter policy answers whether the exact requested values are permitted.

Approval and verification add two more gates when the consequence requires them.

This separation matters when a product supports dynamic tool discovery.

The agent can find a capability without loading every tool into each prompt. The production lesson is not that discovery should be restricted. A larger capability catalogue needs a separate authorization gate.

Keep permanent credentials away from the agent

An agent needs access to a capability. It does not always need permanent possession of the credential behind that capability.

The preferred pattern is task or session access:

The policy approves the action.
The credential layer exposes only the needed capability.
The access expires with the task or session.
Revocation does not require a prompt or model change.

BigCircle used this pattern in an anonymized desktop chief-of-staff build.

Credentials were encrypted on the user’s device. The cloud agent did not store the permanent credential. The approved session could use the private tool, and access could be revoked outside the reasoning layer.

This proof does not establish a certification or universal security outcome. It shows an architecture pattern that separates agent reasoning from permanent credential custody.

When the platform supports newly issued short-lived tokens, use them. When it does not, isolate the permanent secret behind a controlled broker and expose a narrower session capability.

Require fresh evidence before execution

Permission should depend on current evidence, not only on the agent’s plan.

An evidence gate can require:

a current record version;
source provenance;
a valid workflow state;
required business fields;
a rule or confidence threshold;
a fresh policy decision;
an unexpired approval;
an unexpired credential.

The missing-evidence behavior must be explicit: stop, ask, or escalate.

Do not let the agent convert missing evidence into an assumption because the task looks routine.

An approval view should show the exact action, target, parameters, current state, evidence, expected result, worst credible failure, recovery path, and expiry.

If the target or parameters change after approval, the action needs a new decision.

Define completion before the tool call

Tool success is an interface result. Task completion is a verified business state.

Before execution, define an expected-state contract:

the state before the action;
the expected state after the action;
the fields or resources allowed to change;
the invariants that must remain true;
the expected downstream effects;
the independent verification source;
the verification deadline.

The agent should not be the only system that decides whether its own action worked.

If the result cannot be confirmed, the run must enter an unknown state. It must reconcile before it retries.

This requirement links authority to reliability. An action that cannot prove its final state cannot safely receive broad execution authority.

Worked example: a customer-operations action

Consider a conditional onboarding workflow. A customer submits required information. An agent reviews the case and prepares the next operational state.

The broad request is: “Complete the onboarding case.”

The reviewable action is narrower:

Change one eligible case from verified to ready_for_provisioning after approval, without changing identity, payment, or compliance fields.

The boundary can include:

Principal: the onboarding operations role;
Purpose: advance one approved case;
Target: one case in the production tenant;
Precondition: current status is verified and the record version matches;
Allowed change: status and status_reason only;
Approval: named operator, valid for 15 minutes;
Credential: session capability for the case-update tool;
Expected state: case status changed and provisioning event created;
Verification: read the case and event store through a separate query path;
Unknown state: stop and reconcile by case ID and operation ID;
Recovery: route to operations if the case changed but the event did not exist.

This does not approve the whole onboarding agent. It approves one action class with an inspectable consequence.

The same method can apply to a commerce adjustment, a contract status, a cloud deployment, or an external message. The boundary fields change with the action.

What the architecture review should produce

An action review should end with a decision, not a list of general concerns.

The output should include:

the exact action class;
its current authority level;
the principal and delegation contract;
eligible tools and denied tools;
target and parameter policy;
credential source, scope, expiry, and revocation;
evidence and approval gates;
expected-state and verification contracts;
idempotency, retry, and recovery rules;
audit fields and containment controls;
evidence required for the next promotion.

This is enough for product, engineering, security, and operations to challenge the same object.

It also creates implementation work that can be tested through evals and inspected through observability.

Complete the Agent Action Boundary Canvas

Use the full Agent Action Boundary Canvas to define one action class in detail.

Use the one-page decision sheet when the team needs to compare several candidate actions before it completes the full contract.

The aim is not to make every action autonomous. The aim is to make every granted action explicit, inspectable, revocable, and verifiable.