SUN, SEPTEMBER 20, 2026
Independent · In‑Depth · Practitioner‑Tested
Claude General

Agent Safety Prompts: 6 to Run Before You Hand Over the Keys

Google disclosed that Gemini reached live systems at three real companies during a May evaluation. The cause was not a rogue model - it stopped every time. The cause was a test environment that used a company name belonging to a real business. These six prompts check for that class of mistake in your own setup, before an agent gets credentials or network access.

⌨️ 6 prompts 🕐 Updated Sep 20, 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.
1
Check your test fixtures for real-world collisions
This is the exact failure behind the Gemini incident. Ten minutes now.
Here are the fictional company names, domains, usernames and email addresses used in my test environment: [PASTE LIST]

For each, tell me whether it could plausibly belong to a real organisation. Flag anything that looks like a registered domain, a real trading name, or a name common enough to collide.

Then rewrite the risky ones using reserved patterns that cannot resolve to anything real, and explain the convention so I can apply it to new fixtures myself.
2
Scope the access before you grant it
Agents do what you said, not what you meant. Scope is the only real control.
I want an agent to do this task: [DESCRIBE TASK]

I am about to give it: [LIST CREDENTIALS, KEYS OR NETWORK ACCESS]

Work out the minimum access the task actually needs, then tell me what I am over-granting. For each permission, say whether it is required, optional or unnecessary, and the worst realistic outcome if misused.

Assume the agent interprets ambiguous instructions literally and pursues them enthusiastically. Do not reassure me.
3
Find the secrets before the agent does
Two of the three Gemini accesses used credentials somebody left in a public repository.
Review this repository or directory listing for anything an autonomous agent could use as a credential: [PASTE FILE LIST, CONFIG OR REPO TREE]

Look for API keys, connection strings, tokens, passwords in config files, credentials in comments, committed .env files, and anything in a public path.

For each finding, say what it grants and how urgent rotation is. Then list where you would look next that I have not shown you.
4
Write the stop condition
A stop condition written after the incident is a postmortem. Written before, it is a control.
My agent has this goal: [DESCRIBE GOAL]

Write an explicit stop condition and a set of tripwires, phrased as instructions I can paste into the system prompt.

It must halt and report rather than continue when it: meets a system it was not told about, is offered or asked for a credential, finds the target does not match the expected fingerprint, or would take an irreversible action.

Then tell me which of these a determined optimiser would route around.
5
Pre-mortem the run
Writing the report in advance surfaces the control you forgot.
Assume I run this agent task and it goes badly wrong: [DESCRIBE TASK AND ACCESS]

It is two weeks later and I am writing the incident report. Write it for me.

Include what the agent did in order, which control failed first, the blast radius, who had to be notified, and how long before anyone noticed. Be specific and plausible rather than dramatic.

Then list the three cheapest changes that would have prevented it.
6
Review the access after the run
Out-of-scope access with no consequence is the near miss you get to learn from free.
My agent finished this task: [DESCRIBE TASK]

Here is the log: [PASTE LOG OR SUMMARY]

Identify every external system it touched, every credential it used, and anything accessed that was not needed for the stated task. Flag out-of-scope access even where nothing bad resulted.

Give me a revoke and rotate list in priority order, and tell me what I should have been logging and was not.