A practical permission model for AI agents starts with default denial and grants narrow capabilities for a named workflow. Each grant specifies the data, operation, object scope, time boundary, approval condition, and evidence required after execution. The model should distinguish reading, proposing, and committing a change. It should also support immediate revocation. An agent never receives broad access merely because its job description sounds broad.
Inventory verbs before assigning roles
Begin with the tools and actions in the workflow. Read a customer record, search an order, draft a refund proposal, submit the proposal for review, and issue a refund are separate capabilities. A label such as customer-service agent hides these differences. Permission design becomes concrete only when every verb is attached to an object, condition, and owner.
Use a refund assistant as the working example. It may read the customer message and the matching order, then calculate a proposal from current policy. It may not browse unrelated accounts, alter the policy, or issue money without the required approval. The analysis of AI infrastructure constraints supplies relevant operational context: availability and dependency failures must be handled explicitly, so a missing control service cannot silently widen permission.
Map permissions from the system of record outward. Identify the human or service that owns each capability, the smallest data fields needed, and the destination that will contain the result. Avoid sharing a general credential across agent tasks. A scoped identity makes logs meaningful and lets operators revoke one route without disabling the whole workflow.
Use permission modes that match consequence
Not every action needs the same mode. Reading a limited order record may be automatic after identity checks. Drafting a refund can be automatic because it is reversible. Submitting a proposal may require a policy check. Issuing money should require a current approval or a tightly bounded rule owned by finance. The agent should receive a capability token only after those conditions hold, and the token should expire when the task ends.
- Observe: read approved fields from named sources without changing state.
- Propose: prepare a reversible output that another role must accept.
- Execute with approval: use a specific tool after a current decision is recorded.
- Execute within a bound: act automatically only inside an explicit policy envelope.
- Deny and escalate: preserve the case when identity, scope, evidence, or control is missing.
Context does not change the mode. Company memory may tell the agent how a similar case was handled, but it cannot expand the live grant. The company memory guide supports this design by separating useful retrieval from authority. Policy, approval, and tool identity remain the sources that permit execution.
Enforce, test, and revoke the grant
Permissions must be enforced outside the prompt. The tool gateway checks the agent identity, operation, object, scope, and approval reference before doing work. The destination system produces a receipt. An independent checker compares that receipt with the request and policy. If the agent asks for a different operation, changes the object, or presents an expired approval, the gateway rejects the call before state changes.
Test the model with hostile and accidental cases: a request for another customer, a prompt that asks to ignore policy, an approval copied from an old ticket, a tool retry after success, and a control service outage. The correct result is a refusal with a useful record. The checklist for confident AI failures provides a contextual review of why plausible explanations must not override missing evidence.
Revocation needs the same precision as granting. Disable the agent identity, capability, object scope, or approval route independently. Keep emergency access human-owned and time-limited. When the workflow changes, remove unused capabilities before adding new ones. Permission accumulation is a design failure, even if every grant was reasonable when created.
The acceptance test confirms both positive and negative behaviour. Valid requests produce the intended state and receipt. Requests outside scope fail without partial changes. Uncertain identity enters review. Repeated denied attempts suspend the route and alert its owner. This gives the business a permission model it can inspect instead of a list of assurances inside a prompt.
Frequently Asked Questions
Define the identity, operation, data, object scope, time boundary, approval condition, destination, and required receipt.
A proposal is reversible and reviewable, while execution changes business state and therefore needs stronger current authority.
Enforce them at the tool or service boundary outside the prompt, using a scoped agent identity and live policy decision.
The action should stop or enter review; service failure must never be interpreted as a broader permission.
For an agent that needs access to real systems, explore AI4SALE support for scoped agent delivery. This canonical service page appears only as the closing CTA. Any implementation should retain default denial, independent enforcement, a reproducible acceptance test, and a failure path that never treats missing authority as permission.