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. Bigcircle sees that gap on client systems, where a shared credential cannot show who delegated the action. A useful approval states what can change, for whom, why, where, within which limits and until when. In a review, we call that contract an Agent Action Boundary.

Key facts

Definition

An Agent Action Boundary is Bigcircle's contract for one action: what can change, for whom, why, where, within which limits, and until when.

How Bigcircle does it

1. Bigcircle refuses an approval of the whole agent, because the models, tools, tasks, and paths are still changing.
2. Bigcircle binds one action to a principal, a task, a target, a policy, a credential, an approval, an expected state, and a recovery path.
3. A shared credential cannot show who delegated the action, so the boundary names the principal on that action.

Comparison

Approving the whole agent accepts consequences that are not defined yet, while an Agent Action Boundary is one action a reviewer can accept.

Key number

Bigcircle's worked permissions example keeps named approval valid for 15 minutes.

"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 carry different authority. Reading a customer record is not the same as changing it, preparing a refund is not the same as submitting it, and 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, because 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, so 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, and it is reviewable in a way that "allow the onboarding agent to manage cases" never can be.

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 of which hides several possible changes behind one word.

Define these fields:

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. In a production agent loop, that comparison sits outside the model.

Bind the action to a principal and task

Authentication answers who the agent is, authorization answers what it may do, and delegation answers why it may perform this action now. The delegating principal may be a person, a business role or an approved process, and the delegation must point to a purpose and a 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, which prevents a valid user request from becoming open-ended authority for every action an agent later decides is helpful. It also improves audit quality, because a shared service credential may prove which connection reached the API without proving who delegated the action or why the policy allowed it. When the next step is another agent, that chain is checked again, because the parent's message can carry text the parent only read. Stopping prompt injection from spreading between agents is the check at each hop.

Separate discovery, eligibility, and permission

Tool discovery answers which capabilities exist, without answering which of them belong in the current workflow. Eligibility answers which tools may be considered for this workflow, without approving 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, and approval and verification add two more gates when the consequence requires them.

This separation matters when a product supports dynamic tool discovery, because the agent can find a capability without loading every tool into each prompt. The production lesson is not that discovery should be restricted, it is that a larger capability catalogue needs a separate authorization gate. That gate is enforced on the live call by MCP tool access in production.

Keep permanent credentials away from the agent

An agent needs access to a capability, and it does not always need permanent possession of the credential behind that capability. The preferred pattern is task or session access:

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

We used this pattern in an anonymized desktop chief-of-staff build, where credentials were encrypted on the user’s device and the cloud agent never stored 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 a 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 rather than only on the agent’s plan, which may have been formed several steps and several minutes earlier. 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 and task completion is a verified business state, and a tool that returns 200 has not told you the business state changed. 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 and reconcile before it retries. That requirement links authority to reliability, because an action which cannot prove its final state cannot safely receive broad execution authority. The same gap between a tool result and a finished task is why agents report unfinished work as done.

Worked example: a customer-operations action

Consider a conditional onboarding workflow, where a customer submits required information and an agent reviews the case and prepares the next operational state. The broad request is "complete the onboarding case", and the reviewable action is narrower than that:

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 applies to a commerce adjustment, a contract status, a cloud deployment or an external message, and only the boundary fields change with the action. Whether that write should exist at all is the question in when your AI product needs write access.

What the architecture review should produce

An action review should end with a decision rather than a list of general concerns that nobody owns afterwards. The output should include:

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

That is enough for product, engineering, security and operations to challenge the same object rather than four different ones. It also creates implementation work that can be tested through evals and inspected through observability. Promotion to the next level uses the evidence in how to roll out agent autonomy.

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, it is to make every granted action explicit, inspectable, revocable, and verifiable.

Production takeaways

• Approve one action class, never the agent. An agent's tools, models and paths change most weeks; an action class does not.
• Start the boundary with a verb and a target. "Manage the account" hides several possible changes behind one word.
• Bind every run to a delegating principal and a purpose, because a shared service credential proves which connection reached the API and nothing else.
• Discovery, eligibility and permission are three different questions. A larger tool catalogue needs a separate authorization gate, not a longer prompt.
• Give the agent access to a capability without permanent possession of the credential behind it.
• Check evidence at execution time. The plan may have been formed several steps and several minutes earlier.
• Define the expected final state before the tool call. A 200 has not told you the business state changed.

Common questions

What is an Agent Action Boundary?#

An Agent Action Boundary is the approval for one action class, not for the whole agent. It states what can change, for whom, why, where, within which limits, and until when. A reviewable form names one status change on eligible cases, in one tenant, after a named approval, and inside a short window. Allowing an onboarding agent to manage cases is not that contract, because the tools and paths behind the agent keep changing.

Why is approving the whole agent the wrong control?#

Reading a record, preparing a refund, and sending that refund to a customer are different kinds of authority. The agent can also gain a new server, browser tool, model, or workflow, and that gain must not expand what it may do. Approval belongs on one action class, so reviewers accept a consequence that has already been defined. Product, engineering, security, and operations can then challenge the same object.

What should an AI agent permission include?#

Start with a verb and a target, then name the system, the record, and the state that permits the action. Also name the fields, the parameter range, the tenant, the volume, and what this path must never do. A narrow tool schema helps, and the application still compares the request with the principal, the task, the state, the approval, and the policy version. A phrase such as "manage the account" hides several changes behind one word.

Should an AI agent hold a permanent credential?#

Give the agent access to a capability without giving it the permanent credential behind that capability. Approve the action, expose only the needed capability, expire the access with the task, and revoke it without changing the prompt or the model. On one desktop build, credentials stayed encrypted on the user's device and the cloud agent never stored the permanent secret. If the platform cannot issue a short-lived token, isolate the secret behind a broker.

How do you know an agent action finished?#

A tool that returns 200 has not shown that the business state changed. Before the call, record the state you expect, the fields that may change, the facts that must stay true, and a separate source that can confirm the result. The agent should not be the only system that decides its own action worked. If the result cannot be confirmed, stop the run and reconcile it before any retry.

How is tool discovery different from permission?#

Discovery answers which capabilities exist, and eligibility answers which of them fit this workflow. Authorization answers whether this principal, this task, this target, and this state may use the tool now. Parameter policy then answers whether the exact values are allowed. A larger catalogue still needs that separate gate, because finding a tool does not approve the call.