The permission boundary belongs outside the AI prompt

An assistant can write a careful explanation and still make a dangerous change. The critical question is often outside the conversation: which identity called the tool, what that identity could access, and whether the requested action was checked against the user’s actual authority.

Consider an illustrative operations assistant that summarizes support requests. During a pilot, someone connects it with an administrator account because that removes setup friction. The assistant now has access to far more than the summary requires. A prompt asking it to behave responsibly does not reduce those permissions.

Security for an AI workflow begins with the same discipline as other software: identify the actor, limit authority, validate the target, record important actions, and make access removable. AI adds uncertainty about the action being proposed, which makes those external boundaries more valuable.

1. Separate identity, authority, and intent

Identity answers who is making the request. Authority answers what that actor may do to a particular resource. Intent describes what the person wants to accomplish. A model can help interpret intent, but the application must determine authority.

The identities in a workflow may include a person, an application, a background worker, and a downstream service account. Draw them separately. A person entitled to read one team’s requests should not gain organization-wide access because the integration uses a shared privileged account.

NIST’s Zero Trust Architecture publication explains that trust should not be granted solely because an account or asset is inside a network or owned by the organization. It distinguishes authentication and authorization and focuses protection on resources. Being an internal assistant is therefore not a sufficient access rule.

For each tool call, establish the requesting person or service, the resource, the action, and the relevant scope. Preserve that context across the handoff. Otherwise a narrowly authorized user can accidentally inherit the integration’s broader reach.

2. Start with a permission matrix

A tool inventory tells you what the assistant can call. A permission matrix explains what each call may do. Write it before connecting production systems, then compare the planned rules with the permissions the actual connection grants.

This matrix is an example design, not a universal policy. A different workflow may safely automate a narrow action under predefined limits. The point is that the allowed action and scope are explicit, enforceable, and reviewable.

3. Put enforcement outside the prompt

A system instruction can say that only authorized records should be used. It cannot replace a server-side check. The model may misunderstand a request, encounter misleading content, or produce an object identifier that exists outside the intended scope.

OWASP’s authorization guidance recommends least privilege, denial by default, and permission validation on every request. Apply those rules at the service that reads or changes the resource. Hiding an option in the interface does not enforce the rule.

Prefer a narrow operation such as create a draft for this authorized request over a general command that can modify any record. Validate fields, object ownership, destination, and allowed state transitions. A request to close a ticket should not accept arbitrary extra fields that also change its customer association.

Keep credentials out of model-visible context where possible. The application should hold and use the credential through the appropriate secure mechanism. The model needs to know what the tool does, not the secret that authorizes it.

If the downstream system cannot express the required scope, do not pretend that a prompt supplies the missing boundary. Add an enforcing service, narrow the workflow, or choose a different integration.

4. Walk through a high-impact action

In this illustrative example, a user asks the assistant to prepare a response explaining a service credit. The assistant retrieves an authorized request and drafts a reply. That is still preparation. Sending the reply is a separate action with a named recipient and customer consequence.

The approval view should show the actual destination and final content, plus any consequential attachment or account change. Approval of a plan to write a reply is not necessarily approval of the eventual text. Make the distinction understandable without forcing the user through confirmation for every harmless step.

Bind the approval to the specific action. If the recipient, amount, attachment, or material content changes, the previous approval should not silently cover it. The execution layer should verify that the approved action is the one being performed.

Record the outcome accurately. A timeout may mean the send failed, or that it succeeded before the response was lost. Repeating the action blindly could send twice. Use the downstream system’s supported identifiers and status checks to resolve uncertainty before retrying a consequential operation.

The human approval lesson helps identify which decisions need this boundary. The boundary should follow consequence and reversibility, not whether a feature has an AI label.

5. Treat retrieved content as evidence, not authority

A document, email, support request, or web page can contain instructions addressed to an assistant. That does not make those instructions authorized. The content may be irrelevant, malicious, outdated, or simply written for another audience.

Separate the user’s authorized request from the material being analyzed. A source document can inform a summary. It should not grant new access, change the destination of a message, or authorize a tool that the workflow otherwise forbids.

OWASP’s excessive-agency guidance identifies risks from overly broad functionality, permissions, and autonomy. It recommends narrow tool capabilities, minimum necessary permissions, and appropriate human approval for consequential actions. These controls limit the damage possible when the model proposes the wrong thing.

In a safe test environment, include documents containing irrelevant directions and verify that the system’s permissions remain unchanged. You do not need to publish an attack recipe to test the principle. Observe actual attempted operations and enforcement decisions, not merely whether the assistant says it ignored the text.

A useful security test demonstrates that an unauthorized action cannot occur even when the conversational layer requests it.

6. Design access removal before adding access

Every connection needs an owner, purpose, approved scope, review date, and removal path. A pilot account without an owner tends to outlive the pilot. Permissions accumulate because nothing forces a decision about whether they still serve a task.

Use identities appropriate to the system and avoid borrowing a person’s broad administrator access for routine automation. Review the actual permissions at the connected service, not just the integration’s friendly label. Read-only in one interface can still conceal broader rights on the credential underneath.

Plan for a person leaving a team, a service credential expiring, an integration changing owners, and a compromised connection. Determine which sessions, tokens, scheduled jobs, and downstream access must be disabled. Follow the provider’s supported revocation and credential-management mechanisms.

Test removal in a controlled environment. After access is revoked, a previously valid workflow should fail safely and explain the limitation. It should not fall back to a second, more privileged connection that happens to remain configured.

The AI vendor security questionnaire can help make these questions specific when another company operates part of the chain. Ask for evidence that matches the product and plan you will actually use.

7. Log the decision without copying the whole problem

An audit record should help answer who requested an action, what resource was involved, which rule allowed or denied it, whether approval was required, and what happened. Include a correlation identifier so a reviewer can connect application and downstream events.

Do not automatically store every secret, document, and message body in the audit system. That creates another sensitive repository. Choose the minimum evidence required for investigation, protect access to it, and set a retention period based on the operating need and applicable obligations.

Distinguish proposal, approval, attempt, and confirmed completion. A log that says sent when the application merely requested a send will mislead an incident review. Likewise, a denied operation should remain visible even if the assistant produces a polite answer afterward.

Assign someone to review meaningful exceptions. Repeated denied cross-scope requests, unexpected privilege changes, and uncertain consequential actions need an owner. A large log archive with no review or response path is not an effective control.

Make the user-facing state match the evidence: draft prepared, awaiting approval, action completed, or completion uncertain. Honest states support both trust and recovery.

8. Know when an agent should not act

If a task can be completed with a deterministic rule and a narrow form, that may be easier to secure and explain. An agent is not necessary just because the system has an API.

Keep the workflow advisory when it cannot establish object-level authorization, bind approval to the final action, or recover from an uncertain result. Do not compensate for missing controls with a more emphatic instruction to be careful.

Similarly, avoid giving a general-purpose agent broad authority merely to reduce setup time. The cost of defining a narrow action is often the work that makes automation acceptable in the first place. If nobody can articulate the allowed boundary, the workflow is not ready for autonomous operation.

Security review should also recognize low-impact work. Preparing a private draft from authorized material may need fewer interventions than sending it externally. Excessive confirmation can train people to click through without reading. Reserve attention for a meaningful change in consequence, scope, or authority.

9. Show the thing

Produce a permission matrix, identity flow, approval example, access-removal procedure, and a short record of boundary tests. Use synthetic accounts and safe records so the review demonstrates behavior without exposing real customer material.

Proposed acceptance criteria for the example are concrete: an authorized user can read the intended request; another account’s request is denied; an unapproved send is blocked; an approval cannot be reused for changed content; and revoking the connection stops subsequent access. Every attempted action should be traceable to an actor and outcome.

Have someone outside the implementation team walk through the evidence. They should be able to point to the component enforcing each rule. If the answer is only the prompt, revisit the design.

Learn the authority the task requires. Build boundaries that survive a mistaken proposal. Show that the assistant can do the useful work while the system retains control of what is allowed.

Source notes checked September 23, 2026. This is a defensive architecture guide; the illustrative matrix is not a certification or a substitute for review of a specific deployment.

Continue the field guides: The contract behind a useful AI integration or AI governance needs a decision record, not another slogan.

Try this

Pick one assistant or automation connected to a business system. List the identities involved and the exact operations each credential permits. Write a matrix covering read, draft, send, modify, delete, and permission changes. Mark the resource scope and approval rule for each allowed operation. In a safe test environment, verify an allowed action, a cross-account denial, an unapproved consequential action, and access after revocation. Record which component enforced each result. Remove permissions that the task does not require, and document any boundary the downstream system cannot enforce. Keep the workflow advisory until those gaps have an explicit resolution.