Scope What an Agent Is Allowed to Do
Defines an agent's permission surface by blast radius rather than convenience: what it can do freely, what needs approval, what it must never do, and what happens when it goes wrong. Use it before connecting any agent to real systems.
0 likes
0 dislikes
Sign in to rate this prompt
Prompt
You are a security-minded engineer scoping what an agent is permitted to do. Assume the agent will at some point be wrong, be manipulated, or be both at once, and design for that rather than for the good case.
What the agent does: {{agent_purpose}}
Systems and data it needs to reach: {{systems_and_data}}
Whose data it touches: {{data_subjects}}
Who or what can trigger it: {{trigger_sources}}
Does it ever see untrusted content — web pages, emails, user uploads, third-party API responses: {{untrusted_inputs}}
Where it runs and under whose credentials: {{execution_context}}
Produce the following.
1. **A blast-radius inventory.** For every capability the agent has or wants, state the worst realistic outcome of it firing wrongly at the worst moment, and whether that outcome is reversible, expensive, or public. Sort by damage, not by how likely misuse feels.
2. **Sort every capability into four tiers.**
- **Free** — read-only, low-stakes, reversible.
- **Logged** — allowed, but recorded in a way a human will actually review.
- **Gated** — requires explicit human approval before it fires, with the approval showing what is about to happen in concrete terms rather than a vague confirmation.
- **Forbidden** — not available to the agent at all, enforced outside the model rather than by instruction.
Put anything irreversible, anything that spends money, anything that contacts a third party, and anything that deletes or publishes in gated or forbidden until argued otherwise.
3. **Enforce it outside the model.** For each restriction, say what enforces it in code, in credentials, or in infrastructure. A rule that exists only in the system prompt is a preference, not a control — a model that can be talked out of it will be. Flag every rule that currently lives only in the prompt.
4. **Scope the credentials.** What the agent's identity should be able to do at the API or database level, independent of what it is told. Apply least privilege concretely: name the permissions to remove and the scoping to add.
5. **The untrusted-content boundary.** If the agent ever reads content it did not author, mark exactly which of its capabilities become reachable by whoever wrote that content. Those are the ones an attacker gets, and they should be treated as attacker-controlled from the start.
6. **Failure and recovery.** How I would notice a bad run within minutes, how to stop it mid-flight, what is logged for reconstruction afterward, and how to undo what it did.
Return the tiered permission table, the list of rules currently unenforced outside the prompt, and the one change that most reduces blast radius.