What an AI agent breach means for a one-person stack

You gave Claude access to your Google Drive because you were tired of pasting. You let ChatGPT browse the live web because a research task needed pages, not training data. Cursor has your repository. An n8n workflow holds an API key that can write to your billing system, and a Zapier zap moves every inbound attachment into a folder that three other tools read. Each of those grants was small, reasonable, and made on a Tuesday. None of them is written down anywhere.

The useful question is no longer whether an AI agent can be talked into doing something you did not ask for. Two public incidents have settled that. The question is what the trick reaches, and the answer is fixed entirely by a list you have probably never assembled: what each agent can read, and where it can send things. This guide is for people running a one-to-ten person operation with a handful of connected tools and no security team. It is not for anyone operating a platform that ingests files from the public, which is a different job with a different budget and a different guide.

Agentic attacks stopped being a slide in a conference talk

In November 2025, Anthropic published its account of a cyber espionage campaign in which a threat actor it assessed with high confidence to be a Chinese state-sponsored group manipulated Claude Code into carrying out intrusions directly. Anthropic wrote that the attackers used AI “not just as an advisor, but to execute the cyberattacks themselves”, that roughly thirty global targets were attempted and the attackers “succeeded in a small number of cases”, and that AI performed 80-90% of the campaign, with human intervention needed at only “4-6 critical decision points per hacking campaign” [2].

In July 2026, Hugging Face disclosed an intrusion into its own production systems. The entry point was a malicious dataset that abused “two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration)”. From that foothold, the campaign “was run by an autonomous agent framework … executing many thousands of individual actions across a swarm of short-lived sandboxes, with self-migrating command-and-control staged on public services”. Hugging Face reported unauthorised access to a limited set of internal datasets and to several credentials used by its services, found no evidence of tampering with public models, datasets or Spaces, closed the dataset code-execution paths, rebuilt the compromised nodes and rotated the affected credentials and tokens [1].

Notice what is absent from both stories. Neither is about someone jailbreaking a chatbot into saying something rude. One was a coding agent pointed at targets by a human who checked in occasionally. The other was an ordinary ingestion path that treated an outside file as content to process rather than as code that might run. The durable lesson has nothing to do with datasets specifically. It is that the risk sits in the machinery that takes in outside material automatically, and that an agent given a foothold there can keep working without anyone at a keyboard.

Your exposure is the overlap of private data, untrusted content, and a way out

The clearest model for this is what Simon Willison calls the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. Any one of the three on its own is ordinary. All three in the same agent is the problem, because a model cannot reliably tell your instructions apart from instructions hidden in material it was asked to read. As he puts it, if you ask an LLM to “summarize this web page” and the page says the user wants their private data emailed to an attacker, “there’s a very good chance that the LLM will do exactly that” [3].

Apply that to a real setup. A Claude connector reading your Drive is private data. Web search or a fetched PDF is untrusted content. A Gmail connector, a Zapier webhook, or an agent that can post to a public repository is the way out. Wired together in one assistant, that is the full trifecta, assembled by you, one convenience at a time. OpenAI describes the same failure in its own launch announcement for ChatGPT agent: a malicious prompt hidden in a webpage, “such as in invisible elements or metadata, could trick the agent into taking unintended actions, like sharing private data from a connector with the attacker” [8].

Untrusted content is anything you did not type yourself

Most people underestimate this category badly. OWASP splits prompt injection into direct injection, where a user’s own prompt alters model behaviour, and indirect injection, which occurs when “an LLM accepts input from external sources, such as websites or files” whose content then changes how the model behaves [4]. The word “external” is doing a lot of work. In a small business, external means the client brief that arrived as a PDF, the invoice you dropped into a folder an agent watches, the calendar invite a stranger sent, the issue comment on your open-source repo, the Notion page a contractor edited last week, and every web page your agent opened while researching.

None of that looks like an attack. That is the point. OWASP notes these attacks “do not need to be human-visible/readable, as long as the content is parsed by the model”, so text sized to zero, white on white, or buried in metadata works exactly as well as visible text [4]. Anthropic’s own Claude Code documentation lists a matching set of habits for handling this: review suggested commands before approving them, avoid piping untrusted content directly to Claude, and use virtual machines for scripts and tool calls, particularly when interacting with external web services [6].

The practical version for a solo operator is a sorting rule. Before you connect anything, ask which of your agents routinely eat material from outside your own head, and treat those as compromised-by-default surfaces rather than as helpful assistants who happen to browse.

Least privilege survives the model being fooled, and instructions to the model do not

You cannot fix this in the system prompt. Telling an assistant to ignore instructions found in documents is a request, not a control, and OWASP’s mitigation list puts the actual controls elsewhere: constrain model behaviour, enforce least-privilege access by restricting model capabilities to the minimum necessary, require human approval for high-risk operations, and segregate external content so it cannot influence the user’s prompt [4].

Least privilege in this context means the OAuth scopes you click past. Anthropic’s connector guidance is explicit about it, telling users to review requested permissions carefully and to “Limit these scopes when possible and deny access if requested permissions seem unnecessary” [7]. The MCP specification makes the same argument to the people building these servers, warning that broad scopes create an “expanded blast radius: stolen broad token enables unrelated tool/resource access”, and advising clients to “Begin with only baseline scopes” [5]. Wildcard and omnibus scopes such as *, all, or full-access are named as common mistakes [5].

Claude Code shows what the shape of a good default looks like. In Manual mode it starts with read-only permissions and asks before editing files or running commands, it can only write to the folder where it was started and its subfolders without explicit permission, and its web fetch uses a separate context window specifically “to avoid injecting potentially malicious prompts” [6]. You will not rebuild that yourself, but you can copy the principle: give each agent read where read is enough, keep write scoped to one folder or one project, and put anything holding client records or payment access behind a separate account the browsing agent cannot see.

Human approval belongs on the actions that leave the building

Approving every step teaches you to click through everything, which is worse than approving nothing thoughtfully. The dividing line worth defending is whether an action is reversible and whether it is visible outside your own machine.

The major vendors draw it in roughly the same place. OpenAI says ChatGPT is trained to explicitly ask permission before taking actions with real-world consequences such as making a purchase, that certain critical tasks like sending emails require active oversight through Watch Mode, and that it is trained to actively refuse high-risk tasks such as bank transfers [8]. Anthropic tells connector users to click “Allow always” only when they are certain the server and tool warrant unsupervised operation, and to be aware of any actions Claude is taking and that they have no destructive or unintended effects [7].

Translate that into your own settings. Sending, publishing, paying, deleting, and granting access are the five verbs worth a prompt every time, even when the tool offers to remember your answer. Reading, drafting, and summarising are not. OpenAI’s own advice for reducing exposure is blunter still, and worth taking literally: disable connectors when they are not needed for a task [8].

Nobody vetted the connector for you

The most common wrong assumption is that appearing in a directory means somebody checked. Anthropic states plainly that it “reviews connectors against its listing criteria before adding them to the Anthropic Directory, but does not security-audit or manage any MCP server” [6]. Its connector documentation is more direct: custom connectors let you link Claude to “arbitrary services that have not been verified by Anthropic”, a malicious server may carry “hidden instructions that try to make Claude perform unintended actions”, and the people who build these servers may update “tool behavior unexpectedly, leading to unintended or malicious behavior” [7].

That last clause is the one people miss. Approval is not permanent, because the thing you approved can change under you after you approve it. A server that behaved for six months can ship an update whose tool descriptions now instruct the model to do something else, and nothing in your setup will announce that.

Locally installed servers deserve more caution than remote ones, not less. The MCP specification lists servers that run on your machine as an arbitrary code execution risk with “no visibility”, meaning users have no insight into what commands are being executed, and it requires clients offering one-click configuration to show the exact command that will be executed, without truncation, before running it [5]. Read that command. The specification’s own example of a malicious startup command posts ~/.ssh/id_rsa to an attacker’s server, which is exactly what you are reading for [5]. Anthropic’s rule is the safe default for anyone without time to audit: only connect Claude to servers built and hosted by organisations and applications you trust [7].

Detection at your scale is a short list you actually re-read

Hugging Face did not spot its intrusion by watching logs. Its anomaly-detection pipeline “uses LLM-based triage over security telemetry to separate real signals from the daily noise”, and the forensic work afterwards ran analysis agents over an attacker action log “comprised of more than 17,000 recorded events” [1]. You have none of that, and you are not going to build it.

What you do have is a smaller problem. A company with thousands of internal services cannot enumerate its own attack surface; you can, on one page, in an afternoon. The entire security programme available to a solo operator is keeping the connection list short enough to read, re-reading it on a schedule, checking the connected-apps or OAuth screen of each account you care about, and rotating any key an agent has held for a long time. The value of the list is not that it prevents anything. It is that when a tool starts behaving oddly, you already know what it could touch, instead of spending the first two hours finding out.

What still goes wrong

There is no complete fix for prompt injection, and the vendors say so themselves. Anthropic’s Claude Code security page, after listing its protections, warns that “no system is completely immune to all attacks” [6]. Every control described above reduces what a successful injection reaches. None of them stops one from succeeding. If you were hoping for a setting that makes this go away, it does not exist yet.

Scopes are also coarser than the advice implies. Plenty of APIs offer read and write and nothing in between, so “least privilege” often collapses into a binary choice between an agent that cannot do the job and one that can do far more than the job. Where that happens, the honest fix is a separate account with less in it, not a cleverer prompt. Approval prompts have their own failure mode: ask often enough and you will approve without reading, which is the state OWASP and both vendors are implicitly trying to avoid by reserving prompts for high-risk actions [4][8].

Finally, an audit is a snapshot. The connector you approved can change behaviour in an update [7], the contractor you offboarded may still hold a token, and the workflow you built in Zapier last quarter is still running whether or not you remember it. Treat the checklist as something you repeat, not something you complete. And if you are running anything that ingests files from the public automatically, this guide is the floor, not the ceiling. That case needs the review Hugging Face ended up doing, ideally before rather than after [1].