A one-question test that tells you if an agent is exploitable, the four rules I use before I connect one to a real account, and an audit prompt that hands you a ranked fix list.
In July, OpenAI disclosed that two of its models broke out of a sandboxed test environment, reached the internet, and pulled evaluation answers out of Hugging Face's production database. Hugging Face spotted the intrusion and contained it on its own.
Fair caveat, which OpenAI said plainly. Guardrails were off for that test and the models were fixated on one benchmark, so it is not proof your agent is plotting anything.
The incidents that should change your setup are the boring ones, and 2026 produced plenty. A coding agent pointed at staging connected to production instead and wiped 1.9 million customer rows. Trading agents at Step Finance could move funds with no human approval, so when one executive's device was compromised, roughly $27 million left in 261,000 SOL transfers. Nobody there was outsmarted by a model. They were hurt by permissions they granted and forgot.
I am not slowing down on agents. I have gotten strict about what mine can reach when I am not watching.
Start Here: The Three-Leg Test
Before any rule, run this. Security researcher Simon Willison named the pattern the lethal trifecta, and it is the fastest way to tell whether an agent can be turned against you. Three properties:
01It sees private dataYour email, files, customers, finances, credentials.
02It reads untrusted textWeb pages, incoming email, support tickets, reviews, shared docs, PDFs you asked it to summarize.
03It can send things outEmail, posting, webhooks, API calls, uploads, browsing a URL.
The testAny two of these is workable. All three at once means a stranger can write text your agent will read, and that text can instruct it to take your private data and send it somewhere. Cut one leg and the attack has nowhere to go.
This works because of something models cannot fix. An agent receives your instructions and the web page it just read as the same stream of text, with no reliable way to tell which one is the boss. So never follow instructions from a website is a wish, not a defense. Design the combination out yourself rather than waiting for a vendor patch.
The third leg is usually cheapest to cut. An agent that drafts replies into a folder is a different risk from one that can hit send.
Rule 1: Permissions, Not Prompts
Writing never delete anything or always ask before you send into an agent's instructions is a preference, not a control. A model can misread it, a long session can bury it, and a web page it reads can talk it out of it. If losing something would genuinely hurt, the limit has to live outside the model where the agent cannot argue with it.
"Only read my Drive, never edit or delete files."
The connector itself is set to read-only, so edit and delete are not available to ask for.
Three places to move a rule from your prompt into the actual settings:
Connector permissions. Most tools let you pick read-only versus full access per app. Set it to read-only anywhere reading is the whole job. Here is how I set mine.
Allow and deny lists. If your agent runs commands or code, name the ones it can run and the ones it never can. In Claude Code, deny rules are evaluated before ask and allow, so a deny entry wins. My allow and deny setup.
Scoped keys and spend caps. One key per service, limited to what that service needs, with a hard spend limit and a rotation date you actually keep.
Rule 2: Autonomy Is Earned
Least privilege means give it the minimum access. Agents need a second dial next to that one, which is how much it can do without asking. People tune the first and leave the second wide open.
An agent that lives in Shopify does not need my inbox, my Drive and my Slack. Every extra connection is another place a bad instruction can land, and those arrive in ordinary places. A product review, a support ticket, a calendar invite from a stranger.
Do this once for every agent you run. Write down every tool it can reach, then ask two things. Does it need this to finish the job I gave it, and does it need to do that unsupervised. Fails the first, disconnect it. Fails the second, gate it behind approval.
The rule I followTwo narrow agents beat one that can touch everything. If a job needs email and a job needs your store, that is two agents with two sets of keys, not one agent with both. Autonomy is something an agent earns after it has been boring for a month.
These barely existed when most people set up their first agent.
The thing you installed can change later. A skill, plugin or connector can behave perfectly on install and quietly change its behavior after you have granted permission. Researchers call it a rug pull, and it works because most tools ask approval once and never re-check. Early in 2026, attackers uploaded 824 malicious skills to one marketplace with no code review or malware scanning. Install from publishers you can name, and re-check anything with real access every few months.
Your agent's memory is an attack surface. Once an agent remembers between sessions, a bad instruction written into that memory keeps working long after the conversation ends. OWASP added it to its agentic top ten this year. Two habits cover it. If an agent insists on something you never told it, clear its memory instead of arguing. And never let it write to long-term memory straight from something it read online.
Borrowed credentials hide the real permission level. A connector running on a shared admin login inherits that login's ceiling, not the task's. Give each agent its own identity with short-lived scoped credentials and an expiry date, so forgotten access dies on its own.
Rule 4: Assume It Goes Wrong
Build as though something will eventually go sideways, because eventually it will. Four things make that survivable instead of expensive.
Keep the crown jewels out of reach. Customer records, payment details, contracts and credentials do not belong in an agent's working folder. Keys go in a .env file it loads, never pasted into a prompt or a shared doc.
Put a human in front of anything irreversible. Sending, publishing, paying, deleting and permission changes all get an approval step. Approve the action, not the session. "Yes, send this one" is a control. "Yes, you can use email today" is a blank check.
Keep a log you can read. If you cannot see what the agent did and when, you cannot tell a bad week from a breach. Most platforms have an activity view. Find yours before you need it.
Test the kill switch before you need it. Almost everyone skips this. Could you cut an agent off from everything in under five minutes right now? Know where you revoke its tokens, where third-party app access lives in your Google or Microsoft account, and which key to rotate first. An untested kill switch is a plan, not a control.
The Access Audit
Describe an agent you already run. This runs the three-leg test on it, separates the access it needs from the access it inherited, turns your prompt-only rules into real settings, writes the actual attack chain against your setup, and ranks every fix by risk removed per minute of work.
Agent Access Audit
You are my AI agent security auditor. Your job is to find every way an agent I am running could cause real damage, and to give me a specific, ordered plan to close those gaps. Be direct. I would rather hear an uncomfortable finding than a reassuring summary.
MY SETUP
Agent name and the job I gave it: [describe it in one or two sentences]
Where it runs: [ChatGPT, Claude, Claude Code, Copilot, n8n, Zapier, a custom script, a server, a phone]
Tools, apps and accounts it can reach: [list every connector, MCP server, skill, plugin, extension, API key, integration, file folder and login]
Whose account those connections use: [my personal login, a shared admin account, a dedicated service account, a mix]
What it is allowed to do without asking me: [be honest about what runs unattended]
What data it can see: [customers, finances, employees, health, private files, credentials, nothing sensitive]
Where its input comes from: [me only, incoming email, web browsing, uploaded files, support tickets, form submissions, other agents]
Does it remember things between sessions: [yes with persistent memory, no, not sure]
How often it runs and whether I watch it: [live while I watch, scheduled, overnight, continuously unattended]
If it did the worst possible thing, who else is affected: [just me, my customers, my team, my clients]
WORK THROUGH THIS IN ORDER. DO NOT SKIP A STEP.
1. ACCESS INVENTORY
List every system the agent can reach. For each, state the real permission level it holds right now (read, write, delete, admin, send, spend) and the worst realistic outcome if that permission were used wrongly. Be concrete about the damage in my business, not abstract about risk categories. If I have described a permission vaguely, say what you would need to check and where.
2. THE THREE-LEG TEST
Determine whether this agent has all three of the following at once:
A. access to private or sensitive data
B. exposure to text written by someone outside my business
C. any way to send data out (email, posting, webhooks, API calls, uploads, opening a URL)
State clearly which legs are present and quote the specific part of my setup that creates each one. If all three are present, say so bluntly, explain that this makes the agent exploitable by anyone who can get text in front of it, and tell me which single leg is cheapest for me to cut given what this agent is actually for. If only two are present, name the change that would accidentally add the third, so I do not create it later without noticing.
3. UNTRUSTED INPUT PATHS
List every place this agent reads text that somebody outside my business could have written: web pages, incoming email, support tickets, reviews, shared documents, file contents, search results, calendar invites, form submissions, output from other agents. For each, name the specific action the agent could be talked into taking through that path, and the change that stops a bad instruction there from reaching a dangerous tool.
4. NECESSARY VS INHERITED
Split the access list in two: what the agent genuinely needs for the job I described, and what it only has because it came bundled with a broad login or a wide scope. For everything in the second group, tell me exactly what to disconnect or narrow, and where in that product's settings I do it. If you are not certain of the current menu path, say so rather than inventing one.
5. PROMPT-ONLY RULES
Find every rule I am currently enforcing with instructions instead of permissions. For each, give me the enforced equivalent: the setting, the scope, the allow or deny entry, the separate account, the spend cap, the approval gate. If the product has no way to enforce it, say that plainly and give me the closest real workaround.
6. AUTONOMY REVIEW
Separately from access, assess how much this agent can do without asking. For each unattended action, tell me whether it has earned that autonomy, and what evidence would justify it (how long it has run clean, what volume, what review). Recommend a specific graduation path rather than all-or-nothing.
7. SUPPLY CHAIN
List every skill, plugin, extension, MCP server, template or third-party integration this agent loads. For each, ask: who publishes it, is that publisher verifiable, when did I install it, and has anything re-checked it since. Flag anything with real access whose behavior could have changed silently after I approved it. Tell me which ones to re-verify first and what specifically to look at.
8. MEMORY AND PERSISTENCE
If this agent remembers across sessions, identify what can write into that memory and whether any of it originates from untrusted content. Name the risk of a bad instruction persisting after the conversation ends. Tell me how to review what it currently holds, how to clear it, and what rule to set about what may be written to long-term memory.
9. CREDENTIALS AND IDENTITY
For every key, token, or connected login: is it dedicated to this agent or shared with me or my team, how old is it, when was it last rotated, does it expire, and does it carry a spend limit. Flag any credential where the agent inherits broader rights than the task requires. Give me a rotation and expiry plan with actual dates.
10. APPROVAL GATES
Name every action this agent can take that is irreversible, outward facing, or costs money. For each, tell me whether it should be blocked outright, require my approval at the moment it runs, or stay automatic. Give me a short list I can paste straight into the agent's configuration or settings.
11. THE ATTACK CHAIN
Now work against me. Write the most plausible realistic attack on this specific setup as a short numbered sequence: where the attacker gets text in front of the agent, what that text says, which tool the agent reaches for, and what leaves my business. Use my actual tools and data, not a generic example. Then write the shortest version of that chain that still works, because that is the one that will actually happen. Finally, name the single change that breaks the chain earliest.
12. BLAST RADIUS
Assume the agent is fully compromised tomorrow and does the worst thing its current permissions allow. Describe that scenario in plain language, including who else it touches and what I would owe them. Then give me the two changes that shrink it most for the least effort.
13. THE KILL SWITCH DRILL
Assume I need to cut this agent off from everything in the next five minutes. Write the exact steps in order: what to revoke, where, what to rotate, what to disconnect, and what stays broken afterward that I should expect. Then tell me what I should test in advance so this works under pressure, and what evidence I should preserve before I start revoking.
14. THE FIX LIST
End with a numbered checklist of the exact changes to make, ordered by how much risk each removes per minute of work. For each item give: the change, where I do it, roughly how long it takes, and what it protects against. Mark each one Today, This Week, or Nice To Have. Put anything that closes the three-leg test at the top regardless of effort.
HOW TO ANSWER ME
Use only what I told you about my setup. If something is unclear or missing and it changes your answer, ask me before assuming.
Do not tell me my setup looks fine without naming exactly what you checked and what you could not check.
If a risk depends on a product detail you are not certain about, say you are not certain rather than inventing a setting name or menu path.
Rank honestly. If one finding matters far more than the rest, say that instead of giving me a flat list of ten equal items.
Skip the reassuring summary at the end. Finish on the fix list.
How to set it up. Two ways, both take about a minute.
The fast way. Hit Copy, paste it into Claude or ChatGPT, and fill in the brackets for one real agent.
If you want to keep it. Download it as a Claude Skill, or paste it into a Project's instructions, and re-run it every time you connect something new.
Run it on the agent with the most access, not the newest one. That is usually something you set up months ago and stopped thinking about. If you only act on one section, make it step 2.