← Back to all free guides

Giving An Agent
Access

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, in an internal cyber test run without the usual guardrails, got out to the internet and pulled benchmark answers from Hugging Face’s production database. Hugging Face had already spotted and contained it. OpenAI said the models were hyperfocused on one narrow test goal, so don’t panic about yours.

The incidents that should change your setup are the boring ones. In July 2025 a Replit coding agent deleted a live production database during a code freeze, after being told not to make changes. Nobody was outsmarted by a model. The agent simply had access nobody had taken away.

Start Here: The Three-Leg Test

Simon Willison calls this the lethal trifecta, and it’s the fastest way to tell whether an agent can be turned against you. Check for these three legs.

01

It sees private data

Your email, files, customers, finances or credentials.

02

It reads untrusted text

Web pages, incoming email, support tickets, reviews, shared docs, PDFs you asked it to summarize.

03

It can send things out

Email, posting, webhooks, API calls, uploads, even opening a URL.

The Test

Any two is workable. All three at once means a stranger can write text your agent will read, and that text can tell it to take your private data and send it somewhere. Cut one leg and the attack has nowhere to go.

Your instructions and the page the agent just read arrive as the same stream of text, so "never follow instructions from a website" is a wish. The third leg is usually cheapest to cut. An agent that drafts replies into a folder is a very different risk from one that can hit send.

Rule 1: Permissions, Not Prompts

Writing "never delete anything" into an agent’s instructions is a preference. A web page can talk the model out of it. If losing something would hurt, the limit has to live outside the model.

Before: "Only read my Drive, never edit or delete files."

After: "The connector itself is set to read-only, so edit and delete don't exist for the agent."

  1. Connector permissions. Set read-only anywhere reading is the whole job. Here’s how I set mine.
  2. Allow and deny lists. If your agent runs commands, name what it can and can’t run. In Claude Code, rules are checked deny first, then ask, then allow, so a deny always wins (docs). My allow and deny setup.
  3. Scoped keys and spend caps. One key per service, limited to what it needs, with a hard spend limit and a rotation date you actually keep.
Rule 2: Autonomy Is Earned

Access is one dial. How much an agent can do without asking is a second one, and people leave it wide open.

For every agent you run, list every tool it can reach and ask two questions. Does it need this to finish the job? Fails, disconnect it. Does it need to do that unsupervised? Fails, put it behind approval.

The Rule I Follow

Two narrow agents beat one that can touch everything. A job that needs email and a job that needs your store is two agents with two sets of keys. Autonomy is something an agent earns after it’s been boring for a month.

Want a structure to start from? Use my agent guardrails template.

Rule 3: Three Newer Risks

01

What you installed can change later

A skill, plugin or connector can behave on install and change after you’ve approved it, and most tools never re-check. In early 2026, researchers found hundreds of malicious skills on ClawHub, OpenClaw’s public marketplace, before it added malware screening, and some still slipped past the scans months later. Install from publishers you can name and re-check anything with real access every few months.

02

Memory is an attack surface

Once an agent remembers between sessions, a bad instruction written into memory keeps working after the chat ends. OWASP lists memory and context poisoning in its Top 10 for Agentic Applications. If an agent insists on something you never told it, clear its memory. Never let it save to long-term memory straight from something it read online.

03

Borrowed logins 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 account or key with the narrowest scope and an expiry date, so forgotten access dies on its own.

Rule 4: Assume It Goes Wrong
  1. Keep the crown jewels out of reach. Customer records, payment details, contracts and credentials don’t belong in an agent’s working folder. Keys go in a .env file, never in a prompt or shared doc.
  2. Put a human in front of anything irreversible. Sending, publishing, paying, deleting and permission changes all need approval. Approve the action, not the session. "Yes, send this one" is a control. "Yes, use email today" is a blank check.
  3. Keep a log you can read. Find the activity view now, before you need it.
  4. Test the kill switch. Could you cut an agent off from everything in five minutes right now? Know where to revoke its tokens, where third-party app access lives in your Google or Microsoft account, and which key to rotate first.
The Access Audit

Describe one agent you already run. This runs the three-leg test on it, writes the 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.
  1. Use it once. Paste the audit prompt into a new chat in Claude or ChatGPT, fill in the [brackets], and send. Fill in the brackets for one real agent.
  2. Keep it. In Claude, make a Project, click Set project instructions, paste it in and save. Every chat in that Project starts with it. In ChatGPT, do the same with a Project’s instructions.

Run it on the agent with the most access, not the newest one. If you only act on one section, make it step 2.