Your AI knowledge base is an attack surface
A knowledge base an AI agent can read and write is a productivity tool, and dated 2026 incidents show it is also somewhere an attacker can plant instructions.
An AI agent that reads and writes a folder of your business’s knowledge is being trusted with three things at once: your private data, whatever untrusted content gets fed into it, and some way of communicating back out. Simon Willison, who has tracked AI security closely, calls that combination the “lethal trifecta”: private data, exposure to untrusted content, and an outbound channel, in one system. Put all three in the same place and the system can be induced to leak what it holds. A knowledge base built from clipped web pages, pasted emails, and forwarded documents is untrusted content by definition. That is not a hypothetical risk. It has already been demonstrated.
What has already happened
Within 48 hours of Anthropic’s Cowork (a desktop agent with folder access) launching in research preview in January 2026, the security firm PromptArmor demonstrated a working attack: a Word document containing invisible one-point white text, which caused the agent to exfiltrate financial documents. The vulnerability was not a bug in one feature. It was the trifecta, played out against a real product within two days of launch.
The clearest numbers come from OpenClaw, the open-source persistent-agent framework whose memory is plain markdown files (SOUL.md, MEMORY.md, USER.md). In its January and February 2026 security crisis, SecurityScorecard’s research, reported by Infosecurity Magazine on 9 February 2026, found 40,214 exposed instances across 28,663 unique IP addresses, with 63 per cent of observed deployments vulnerable and 12,812 exploitable by remote code execution. Beyond the exposure count, the crisis surfaced something specific to this pattern: marketplace skills that wrote persistent backdoor instructions directly into the memory files, instructions that survived even after the skill itself was removed. The memory file was the payload. A poisoned note is not just bad data sitting in a folder; it is an instruction an agent may act on the next time it reads that file.
Why the memory file is the exposure
This is the part of the AI knowledge base pattern that gets the least attention in the enthusiastic write-ups, because it is not where the pattern’s benefits show up. But it follows directly from the architecture. The instruction file that makes the agent useful (what tells it how to behave, what to trust, what to do) is read by the agent every session. If an attacker can get a hostile instruction into any file the agent treats as trustworthy, whether through a poisoned document, a compromised plugin, or a note copied in from somewhere untrusted, that instruction persists exactly as long as any legitimate one does. Deleting the plugin that planted it does not delete what it already wrote into memory.
What the practitioners who take this seriously actually do
The mitigations that show up with real evidence behind them are not exotic. Read-only defaults, so the agent cannot write without deliberate permission. A human gate on anything moving from raw, untrusted capture into the trusted, reviewed layer, the same trust-boundary architecture that shows up across every serious build in this field. Git as a rollback mechanism, so a bad write can be undone rather than just discovered. Secrets never stored in notes. And, the one that matters most given the trifecta: treating anything ingested from outside the business, a forwarded email, a scraped page, a pasted document, as untrusted until a person has reviewed it, not the moment it lands in the folder.
None of this is a reason to avoid the pattern. It is a reason to build it with the trust boundary as a genuine control, not a tidiness convention. A knowledge base with unattended write access and no gate between capture and trusted knowledge is not a small risk sitting alongside a large productivity gain. Until an agent’s write access is scoped and gated, that is the one part of the build worth treating as non-negotiable, whatever else is on the wish list.
Getting that boundary right, not as an afterthought but as part of how the system is designed from the first session, is the kind of judgement call we work through with clients directly in our AI strategy and governance work.