Claude AI Agents

Agent Governance Prompts: 6 to Run Before You Give One Permissions

Agents can now hold wallets, make payments and act across connected services, and the standards for proving they were authorised are still being written. These six prompts are for the audit you should do before enabling any of that: what your agents can already reach, what happens when one is manipulated, and what evidence exists afterwards. Written for Claude but they work in any assistant.

⌨️ 6 prompts 🕐 Updated Aug 30, 2026

💡 How to use these prompts: Replace everything in [BRACKETS] with your specific details before sending. Click Copy to copy any prompt to your clipboard instantly.

List what the agent can actually reach

Designed permissions and actual permissions diverge quickly. This surfaces the gap.

Here is my agent setup: [DESCRIBE TOOLS, CONNECTORS, CREDENTIALS]

Tell me what this agent can reach in practice, not what it was designed to do. For each capability:
- What it can read
- What it can write, delete or purchase
- Whether that permission is scoped to a task or standing
- What it could do that I probably have not considered

Rank by blast radius, not by likelihood.

Write the spend policy before enabling payments

Per-run caps matter more than monthly ones. A compromised agent spends its whole month in an afternoon.

I am considering letting an agent make purchases for: [PURPOSE]

Draft a spending policy covering:
- Maximum per transaction and per run, not per month
- Which merchants or services are permitted
- What requires human approval regardless of amount
- What happens when a limit is hit mid-task
- What gets logged, and where

Then tell me the first thing an attacker would try against this policy.

Trace the authorisation chain

Built around the task-reference pattern emerging across Google AP2, NIST work and the AI AGENT Act.

For this workflow: [DESCRIBE]

Trace who authorised what. For each action the agent takes:
- What permission allows it
- Where that permission came from
- Whether it is bounded to this task or applies generally
- What record would exist if the action were later disputed

Flag any action where the answer to the last question is nothing useful.

Model the manipulation case

The Forcepoint email injection and the Copilot memory poisoning both worked this way. Worth modelling before enabling spend.

Assume an attacker controls content my agent reads. Web page, email, document, issue title, anything ingested.

Walk through:
- What instructions could plausibly be injected there
- What the agent would do if it followed them
- Which of its permissions turn that into real damage
- What would stop it, and whether that control actually exists in my setup

Be specific to what I described, not general advice.

Decide what needs a human

Most teams enable everything or nothing. The middle category is where the useful configuration lives.

Here are the actions my agent can take: [LIST]

Sort them into:
- Safe to run unattended
- Needs a checkpoint before proceeding
- Should never be automated

For each in the second and third groups, say why in one line. If you would put something in a different group depending on context, say what the deciding factor is.

Write the incident procedure now

Written before you need it, this is a runbook. Written afterwards, it is an inquest.

My agent has done something wrong: [SCENARIO]

Write the procedure for handling it:
- How I would find out
- How to stop it immediately
- What to check for other actions taken in the same session
- What evidence exists and where
- What to fix so the class of problem cannot recur

Write it as steps I could follow at 2am, not as principles.