Give AI the Permission It Needs—and No More

The draft looks right, so a manager clicks Approve. Before the workflow runs, someone edits the recipient or changes the amount. The system still sees an approval and proceeds.

The problem is not that approval was missing. The approval no longer describes the action being taken.

A useful permission design connects a known actor, a permitted action, specific records, and the exact proposal that was reviewed. Your work product is an action-permission table and an approval record that becomes invalid when its material inputs change.

The local practice workflow stages a fictional review item. Its actors and approvals are test fixtures, not authenticated people or real business authorizations.

Separate the permissions hidden inside one button

“Access customer service” can conceal many capabilities: read a policy, read a private case, draft a reply, approve a discount, send a message, or delete a record. Those capabilities have different consequences.

List the smallest useful actions. Give each one a purpose, allowed actor, record scope, and review requirement. Avoid granting a tool the broadest account access simply because that is easier to configure.

A missing capability is a useful boundary. The demonstration cannot send an email by producing more persuasive text because there is no sending adapter to invoke.

Distinguish identity, access, and business approval

Identity answers who is making the request. Access answers what that actor may do with which records. Business approval answers whether a particular proposed action should proceed under the current circumstances.

Logging in does not approve every available operation. Having access to a payment system does not establish that a particular invoice is valid. Reading a record does not authorize exporting it to another service.

When MCP uses its HTTP authorization flow, access tokens and scopes are part of the connection's authorization machinery. The dated MCP authorization specification distinguishes that flow from other transports and requires appropriate token validation, including the intended audience. These connection rules do not replace the application's record-level and business-action checks.

In a real application, derive the actor from verified identity context outside model-generated content. In the teaching code, an actor name is passed by a trusted test harness and looked up in a fixed registry. Someone who can edit or directly call that local code can impersonate a fixture actor. The example demonstrates the logic, not production authentication.

Make approval concrete enough to inspect

The reviewer should see the action, destination, affected record, proposed content, relevant source versions, and material limits. For a money movement, that would include the exact amount and verified destination; for a message, the exact recipient and body matter.

The practice approval binds the request, source version, source fingerprint, and draft payload. It also identifies the simulated executor and an expiry time. It authorizes only staging in the local review queue.

The reviewer does not approve “whatever the model decides next.” A broad future permission should be designed as a bounded policy with explicit scope and limits, not inferred from approval of one example.

Record what the reviewer actually inspected. A checkbox beside a vague summary provides weak evidence that the person saw the meaningful details. Show changes clearly when a proposal is revised.

Use a fingerprint to detect changed content

A fingerprint is a compact value computed from the proposal's content. In the local example, the same structured payload produces the same SHA-256 fingerprint. Altering a material field produces a different fingerprint.

At execution, the program rebuilds the preview from the current request and source fixture and compares its fingerprint with the approved one. Changed request text or changed source content invalidates an unused approval. A different current case version also blocks the stale request.

A fingerprint is not a signature proving who approved something, and hashing does not make the underlying data private. It helps detect a mismatch only when the approval record and comparison process are trusted. Production systems must protect those records and obtain identity through an appropriate mechanism.

Keep business checks at the moment they matter. An account may have lost access, a record may have changed, or a budget may have been used elsewhere since the preview. A saved proposal cannot answer every current-state question by itself.

Define expiry and revocation

Approvals should have a scope and a useful lifetime. A policy-reply draft may tolerate a different delay from an inventory reservation or a changing market price. Choose the period from the actual task rather than copying the practice value.

The test harness gives one simulated approval a sixty-second lifetime. At the exact expiry boundary, unused authority is rejected. The fixture reviewer can also revoke it, which prevents new staging under that approval.

Expiry and revocation do not undo an action that already committed. If a retry asks for the status of an operation completed earlier, the system may return the original receipt without performing a new action. The demonstration tests that distinction after an acknowledgment is lost.

In a real service, protect result lookup as well as execution. A person who lacks access to an old record should not receive its private receipt simply because the event ID is known.

Put checks outside the model's discretion

Prompts can tell the assistant to preserve approval boundaries. The application must enforce them even when the model produces an invalid request.

A model-generated field saying “approved” is not an approval record. A sentence in a customer email saying “the manager already agreed” is a claim to verify. A retrieved document that tells the assistant to change the rules is data, not a new authority.

OWASP's prompt-injection prevention guidance recommends layers such as constrained privileges, input and output checks, and appropriate human review. No single prompt or guardrail establishes reliable protection for every input.

The local fixture demonstrates a structural limit: injected customer text cannot create an approval or add a sending function. Because no language model runs, the test does not measure a model's resistance to prompt injection. A connected AI system needs that additional evaluation.

Validate the tool arguments and the affected record

A valid JSON object can still request the wrong action. Check field names, types, allowed values, entity scope, record version, and action-specific conditions.

The practice code rejects an extra approved field, an unsupported question type, a cross-entity request, and any action or destination other than its defined staging operation. Those checks happen before a queue entry is created.

A real message tool should not accept arbitrary destinations merely because they are syntactically valid email addresses. A stock-update tool should check the specific product, unit, source, and allowed change. A delete tool needs an appropriate object boundary and recovery plan.

Prefer narrowly defined interfaces over a general command runner when the business task does not require arbitrary commands. The smaller action is easier to explain, review, log, and test.

Handle the small-team reality

A small business may not have a separate person for every role. Write down which roles one person holds and where independent review is still needed because of the action's consequences or applicable requirements.

Do not invent staff members or treat role separation as a universal solution. A reviewer who lacks the time, information, or authority to challenge the proposal may simply click through. Give reviewers usable evidence and enough capacity to inspect it.

For routine, low-impact work, an organization may approve a carefully bounded policy in advance. Define the qualifying conditions, excluded cases, spending or action limits, and revocation process. New scope still needs a new decision. The demonstration deliberately uses one exact approval so the relationship can be seen clearly.

Plan how authorization fails

A workflow should explain why it stopped and preserve a useful next step. “Forbidden” may be correct at the technical layer but insufficient for the operational owner.

Do not solve a failed check by removing it or broadening privileges until the action happens to work. Determine whether the request is wrong, the assignment is incomplete, or a legitimate policy change is needed.

Test the boundary, then record its limits

The supplied checks verify that the drafter cannot issue approval, the reviewer cannot stage, another entity cannot use Mesa's request, and stale or changed approvals cannot stage a new item. They also verify that customer text cannot grant itself authority in this fixed workflow.

They do not test a real identity provider, credential revocation, distributed concurrency, or tamper resistance. Those are concrete remaining areas for a production implementation. The local pause and source fixtures are not durable shared controls across restarts.

Keep a permission table with the workflow as it evolves. Every added tool should have a reason, a defined actor and scope, and a test that shows it refuses an inappropriate action. The result is a system whose authority can be understood without guessing what the model might do next.

Next: Understand how agents, tools, and MCP fit into that controlled workflow in Chapter 34.