Before asking whether an agent resists a persuasive attack, ask whether your application rejects an action it already knows is forbidden. That boundary can often be tested without a model at all.
Consider a publication assistant. An editor authorizes it to prepare an article in Publication A. It may read supporting material and save a draft. It may not publish, change another publication, or send the draft to an arbitrary address. This is an illustrative design scenario, not an account of a measured deployment.
The useful first deliverable is a small, inspectable permission matrix. It makes the intended behavior concrete enough that another engineer can disagree with it before you automate anything.
Write the policy before the prompts
List actors, resources, actions, and conditions. A role alone is insufficient: an editor for one publication is not an editor for every publication. A permitted action can also become invalid after ownership changes or a session expires.
| Authenticated actor | Target | Requested action | Expected decision |
|---|---|---|---|
| Reader of A | Article in A | Read | Allow |
| Reader of A | Article in A | Save draft | Deny |
| Editor of A | Article in A | Save draft | Allow |
| Editor of A | Article in B | Save draft | Deny |
| Editor of A | Article in A | Publish | Deny without publishing authority |
| Expired session | Any article | Any protected operation | Deny |
This is a starting policy for the scenario, not a universal role model. A real newsroom may need additional distinctions, including assigned sections, embargoed material, and separate approval authority.
OWASP recommends least privilege, denial by default, and checking permissions on every request. Those principles apply equally when a model chooses the request. OWASP authorization guidance
Put the decision where the effect happens
The executor should derive identity from the authenticated application session, resolve the actual target resource, and evaluate current permissions. A model-supplied field saying role: editor is an assertion from an untrusted caller, not proof of authority.
The same applies to account identifiers. If a request names Publication A but the article identifier resolves to Publication B, use the resolved resource ownership. Otherwise, the request can supply the answer to the authorization question it is supposed to undergo.
Check every route to the capability: direct tool calls, background workers, bulk operations, retries, and administrative endpoints exposed to the agent. A secure front door does little when a queued action reaches a different executor with broader credentials.
For delayed work, decide whether authority must be rechecked at execution time. In this scenario it should: removing an editor’s access ought to prevent a queued draft update from executing later. Record the original request and the later decision separately so the reason is visible.
Test the effect, not only the response
First exercise the executor with fixed requests and controlled dependencies. Verify both the returned decision and the resulting state. A response labeled “denied” is not evidence of enforcement if a write occurred first.
For the cross-publication case, record the target article version before the request, submit the forbidden update, and inspect the stored article afterward. Also inspect queued jobs and outbound requests. An immediate database check can miss a side effect scheduled for later.
A useful review checklist is:
- Does the allowed operation still succeed?
- Does the forbidden operation leave the target unchanged?
- Does denial prevent queued or downstream work?
- Is the decision linked to the authenticated actor and resolved resource?
- Can a retry reuse stale authority or execute an already rejected action?
- Does the user see the real reason for denial without exposing another account’s private data?
These checks concern application behavior. They do not establish model robustness, and they should not be presented that way.
Add the agent after the boundary is inspectable
Now run ordinary and adversarial tasks through the complete agent. Include normal articles, confusing instructions, and external documents that ask it to publish or transfer content. Keep ordinary work in the evaluation: blocking everything is not a useful publication assistant.
Record three different outcomes. Did the agent complete the authorized task? Did it attempt a forbidden action? Did a forbidden effect actually occur? A malicious instruction that triggers a blocked tool call reveals a model failure and a working executor control in the same run.
An agent that silently abandons the task may avoid an unauthorized effect while still failing the user. Preserve that distinction instead of folding every result into one “safety score.”
Review the weakest transition
Look closely at transitions between proposal, approval, and execution. Suppose an editor reviews a harmless draft update, but the target article changes before execution. The executor must either enforce the approved version or return for renewed review. An approval for one action should not become authority for a changed action.
For consequential writes, bind the decision to the resource, operation, relevant version, and approved arguments. The precise mechanism depends on the application. The design requirement is simpler: the executor must be able to establish that the action it performs is the action that was authorized.
Report narrow evidence clearly
Record policy version, tool definitions, credential scope, cases, observed effects, and known omissions. Describe failures individually. “The editor could not modify another publication in these cases” is useful; “the agent is safe” exceeds the evidence.
Revisit this matrix when tools, roles, or resource ownership change. Permission boundaries are product behavior, not a prompt that stays correct indefinitely.
Continue with retrieved content and authority and designing evaluations that support defensible claims.