Production AI agents need enforceable permission boundaries

The risky part of an AI agent is not the sentence it produces. It is the action that follows. A wrong answer in a draft can be corrected. A wrong refund, database update, customer email, or funds transfer creates a consequence outside the chat window. That distinction changes the design job. Prompt quality still matters, but production safety depends on limits the model cannot rewrite, ignore, or talk its way around.

Capability belongs outside the prompt

A system prompt is useful for intent. It can tell an agent which task it owns, what a good result looks like, and when it should stop. It is a poor place to enforce authority. The prompt lives in the same decision environment as retrieved documents, user messages, tool descriptions, and model output. Those inputs may be incomplete, contradictory, or malicious.

The OWASP guidance on excessive agency separates the problem into excessive functionality, excessive permissions, and excessive autonomy. That separation is valuable because each failure needs a different control. Removing an unused tool reduces functionality. Scoping a credential reduces permission. Requiring approval for a high-impact action reduces autonomy. Repeating a warning in the prompt does none of the three.

The durable rule is simple: describe the boundary in the prompt, but enforce it in the system that owns the resource. A database role decides which rows can be read. A payment provider enforces a transaction ceiling. A deployment credential is limited to one environment. The agent may request an action, but a separate component decides whether that request is allowed.

Start with an action inventory

Teams often begin by listing tools: search, email, CRM, billing, calendar. That is too broad to expose risk. The useful unit is an action. Reading an invoice is different from editing it. Drafting an email is different from sending it. Preparing a refund is different from approving one.

For every proposed action, write down five properties:

• the data it can read
• the state it can change
• the financial or operational exposure
• whether the result can be reversed
• the person or service responsible for an exception

This inventory turns an abstract agent into a set of reviewable decisions. Low-impact, reversible actions can often run automatically. Actions involving sensitive data, money, deletion, publication, or legal commitments deserve narrower credentials or an approval step. If the team cannot describe the consequence of a tool call, the tool is not ready to be delegated.

The inventory also prevents accidental privilege growth. A general CRM token may allow contact export, billing changes, and user deletion even if the agent only needs to add a note. Building a narrow server-side operation such as add_account_note takes more effort than exposing a generic request tool, but it gives the product a stable contract and a much smaller failure surface.

Give the agent its own identity

An agent should not borrow a human administrator's identity. Shared credentials make normal operations easier at first and investigations harder forever. When every action appears to come from the same service account, the audit trail cannot distinguish a user decision, a scheduled job, and a model-initiated change.

Issue a dedicated identity for each agent or agent class. Give it only the scopes required for the current task, short expiry where practical, and a clear owner. The Model Context Protocol security guidance recommends least-privilege scopes and progressive elevation rather than broad standing access. The same pattern applies even when MCP is not part of the stack.

Progressive elevation is especially useful for mixed-risk workflows. An agent can research, classify, and prepare a change with a read-oriented credential. When the user approves, a separate service performs the write with a short-lived, narrowly scoped token. The model never needs permanent access to the stronger credential.

Approval needs product design

Adding a confirmation dialog is not enough. A useful approval experience shows the proposed action, the evidence behind it, the affected records, the expected consequence, and the available alternatives. The reviewer should be able to change or reject the action without reconstructing the agent's reasoning from a transcript.

Approval also needs a timeout and a default. If nobody responds, does the request expire, pause, or proceed? For consequential actions, silence should not become permission. For low-risk and reversible changes, automatic execution with a visible undo window may be better than interrupting a person each time.

This is where product and security work meet. Too many prompts create approval fatigue and turn review into a reflex. Too few prompts hide meaningful decisions. Group related low-risk items, interrupt for the irreversible ones, and preserve enough context that a reviewer can make a quick, informed choice.

Autopilot makes the boundary visible

Autopilot, an Alfcode product currently in development on Solana devnet, demonstrates a strong version of this separation. Its master key remains in a hardware enclave. The agent receives an ephemeral session key, while an on-chain program applies the spending rules. A model can propose a transaction, but it cannot grant itself the master key or change the program's constraints through conversation.

Most products do not need a blockchain or hardware enclave. The transferable idea is architectural independence. The enforcement layer should not share the agent's prompt, memory, or discretion. Cloud identity policies, provider-side spending caps, database permissions, and separate approval services can create the same kind of hard edge in conventional systems.

The boundary must also fail closed. If a permission service is unavailable, a consequential action should wait rather than quietly fall back to a broader path. Convenience during an outage should not erase the exact control the architecture was built to provide.

A gate the whole team can inspect

Before launch, review the action inventory with product, engineering, security, and the people who operate the workflow. Confirm that every high-impact action has a narrow identity, a hard limit, an owner, a record, and a recovery path. Test the denial cases, not only the happy path. Try an expired token, a request above the spending cap, access to another tenant, and an approval that arrives too late.

The NIST AI Risk Management Framework treats mapping and measuring risk as ongoing work rather than a launch-day form. Agent permissions deserve the same treatment. Usage changes, tools expand, and exceptions become routine. Revisit the inventory when any of those conditions move.

A prompt tells the agent what the team expects. A permission boundary tells the rest of the system what the agent is actually allowed to do. Production software needs both, but only one of them still holds when the model is confidently wrong.