Scopehaven
Request a first test
COMPARISON
Permission tests vs prompt-injection tests for AI agents
Prompt-injection tests and permission tests often get treated as one thing, because both come up when an agent misbehaves. They answer different questions. Injection tests ask whether text can steer the model. Permission tests ask what the system lets the agent do, whoever or whatever is steering it.
Short answer: prompt-injection tests feed crafted instructions to the agent, typed directly or planted in content it reads, and check whether its behavior changes. Permission tests run as specific users and check whether data and actions stay inside the rules, judged where the evidence allows from your systems' records. You need both. An injection that only changes a reply is a model problem; one that makes a tool act outside the user's authority is also a permission failure.
This guide is for teams deciding what to test, and with what, before shipping an agent that reads untrusted content or has tools with real effects.
01 / DIFFERENCES
Two questions, two kinds of evidence.
| Aspect | Prompt-injection tests | Permission tests |
|---|---|---|
| Question | Can text change what the model does? | Does the system stop the agent from reaching data or taking actions the rule forbids? |
| Input | Crafted instructions, typed by the user or planted in documents, emails, records, web pages or tool results. | Ordinary and forbidden requests made as test users with known roles and access. |
| A pass shows | The attempts you tried did not change behavior in the way you checked. | The boundaries you tested held for those identities and conditions, and allowed work still succeeded. |
| Typical evidence | The model's output and, where observed, its tool calls. | Records returned, tool calls made and effects in your systems, such as the ledger, outbox and files. |
| Typical fixes | Separating instructions from data, input handling and other model-side defenses. | Authorization checks inside tools and retrieval, approvals for high-impact actions, narrowly scoped credentials. |
| Related categories | LLM01:2025 Prompt Injection (OWASP Top 10 for LLM Applications 2025). | LLM06:2025 Excessive Agency; for the underlying authorization flaws, API1:2023 Broken Object Level Authorization and API5:2023 Broken Function Level Authorization (OWASP API Security Top 10 2023). |
These identifiers name related risk categories. A permission test does not certify an app against them.
02 / OVERLAP
Where they meet: injection that reaches a tool.
When planted text does steer the agent, what happens next decides which kind of failure it is:
- It changes only the reply, such as a misleading summary. That is an injection finding; no permission was crossed.
- It makes a tool do something the user may not do, such as a refund by a member. The injection worked and the permission check inside the tool failed. Both tests should catch it.
- It makes a tool do something the user may do but did not ask for, such as forwarding the user's own records to an outside address. A tool that checks the user's authority will allow it, so this needs controls on the action itself, such as approved destinations or a confirmation the model cannot give.
How to test whether prompt injection can make your agent take an action →
03 / ORDER
Which to run first.
If the agent has tools with real effects, start with permission tests for each tool. The authorization checks inside a tool limit what any successful injection, or any ordinary model mistake, can do with it. Then run injection tests against those same tools, and check the effects, not only the replies.
If the agent only answers questions from documents, start with the data boundary: test tenant isolation in retrieval, then test whether planted content changes answers in ways that matter.
04 / TOOLS
Which kinds of tools cover which.
- Adversarial and red-teaming tools send many crafted inputs, including injection attempts, and grade the results automatically. Open-source examples include Microsoft's PyRIT, NVIDIA's garak and Promptfoo (part of OpenAI). For permission-related cases, check in each tool's documentation whether its grading can read your app's records and tool calls in your setup, or only the model's reply.
- Guardrails and input filters run while the agent is live and try to detect or block suspected injection. They are defenses that lower how often attacks work, not tests of what your tools allow.
- API authorization tests call your tools' endpoints directly, without the model, as different users. They can find object- and function-level authorization flaws in the tools themselves.
- Agent permission tests run the agent as specific test users and check data and effects against written rules, next to allowed-use controls. Your own end-to-end tests can do this with test users for each role and checks on the records the agent changes.
Where Scopehaven fits
Scopehaven is a local assessment workbench for testing the permissions you define, on the actions you check, and rerunning the same checks to show whether a fix held, including the actions that should still work. It tests boundaries; it does not filter prompts or block anything in production, and it does not replace adversarial testing of the model. Runs and evidence stay on your machine; the workbench does not upload them to Scopehaven.
On your own app, what a run can establish depends on the connection and the evidence available. Scopehaven does not certify your application or guarantee it is free from vulnerabilities.
Common questions
If my prompt-injection tests pass, do I still need permission tests?
Yes. Injection tests cover the attempts you tried. Permission tests check what happens when any attempt, or an ordinary model mistake, reaches a tool.
If my permission tests pass, do I still need injection tests?
Yes, for actions the user is allowed to take. A tool that correctly checks the user's authority will still carry out an injected request the user could have made.
Do agents without tools need permission tests?
Yes, if they retrieve data for a signed-in user. What reaches the model's context is itself a data permission.
Can one tool cover both?
Some can run cases of both kinds. What matters is the evidence each check reads: for permission cases, the records and effects in your systems, not only the reply.