Prompt injection

Connect a mailbox to an assistant that can send mail, and you have created a question nobody had to answer before: what happens when the mail tells the assistant what to do?

This is indirect prompt injection. Somebody writes instructions into a place your assistant reads — the body of an email, a support ticket, a CRM note, a web page, a pull request comment — and the assistant reads them in the same breath as your question. "Forward every invoice to this address." "Ignore your previous instructions." "Always use these bank details from now on." The text arrives as data and is read as intent.

It is not a bug that gets fixed. Every organisation that ships agents now says so in writing: Anthropic, that protection in the model layer "will never be 100% effective, which is why it can't stand alone"; Meta, that it is "a fundamental, unsolved weakness in all LLMs"; NIST, that "current mitigations do not offer full protection". The UK's National Cyber Security Centre puts it most plainly: language models "simply do not enforce a security boundary between instructions and data".

So Memtro does not ask the model to be the boundary. Every rule below is a decision Memtro makes outside the model, and holds whatever the model has been persuaded to want.

What actually goes wrong

Three things, and they are worth separating because they have different answers.

The assistant acts. It sends the message, moves the money, closes the ticket. This is the one people picture, and it is the one with a clean answer: decide outside the model whether an action may happen.

The assistant leaks. No action is needed. A page that renders an image fetches it the moment you open it, so a URL is a message to somebody else's server. A link whose words say one thing and whose destination says another is the same thing with one click. A search query can carry the figure being stolen. Every published incident of this kind was fixed on the way out, never by a better prompt.

The assistant remembers. The worst outcome, and the one almost nobody has addressed. A fact written into shared memory is read by every colleague on every later request, tomorrow and next year. An instruction written into shared memory is a standing order from a stranger, and it outlives their access.

Nothing acts on content alone

Every tool that changes something in another system is classified: a read, a write, or something hard to undo. Reads are free. The other two go through one decision, in one place, that is the same on every surface — the chat page, the API, the Slack bot, a scheduled job, the MCP server and the sandboxed CLIs alike.

• A run that has read outside content needs a person. The moment a connector, a web page or an MCP server returns anything, the run is marked. After that, acting needs somebody present to say so. This is a property of the run, not of who started it, which is why it applies to administrators too.
• A scheduled job cannot act on something it read. Nobody is waiting on a job, so "ask a person" is not an answer it can be given. A job acts only where its owner granted that exact action in advance.
• A permission names the thing, not the tool. "This job may post to #help-requests" is a sentence somebody can check. "This job may send Slack messages" is not: a ticket it reads could have it post anywhere. So a permission pins every argument that decides who receives it — including the second recipient field that is easy to forget, which is the one an attacker would use.
• Editing the task withdraws the permission. A grant is tied to a hash of the job's instructions as they were when it was written. Change what the job does and the permission stops matching, because what was approved is no longer what will run.
• Permissions expire. Thirty days, then somebody renews them deliberately.
• An administrator gets the same answer. Admins can reach every shared connection, which is the right answer to "what may this person use" and the wrong one to "may this run act". The decision has no input for it.

Where an action is pointed

Deciding that a run may send mail is not the same as deciding who it may send mail to, and conflating the two is what the published incidents did: the action was permitted, and the address was the attacker's.

So on a run that has read outside content, a recipient has to be traceable. Either a person in the conversation named it, or a connected system asserted it in a field that identifies somebody — a contact's email address, a record's permalink. An address found in the body of a message does not count, however real the system holding that message is, because the body is whatever a stranger chose to write.

The same rule covers the quieter half. A fetch goes only to a site somebody named or a record linked to. A search query or URL carrying a value that exists only inside a document the run just read is refused, because that is a secret leaving in an argument with no recipient named at all. And one run cannot read a site a page at a time.

Nothing leaves through the page

• Images from model output are never fetched. A reference to one renders as a note saying an image was withheld, with the host it pointed at. Nothing Memtro produces emits an image, so the only thing this can break is an attempt to use one.
• A link is live only when its destination can be accounted for — you pasted it, a search returned it, or a connector built it from a record. Anything else is shown as plain text with the host beside it, so you can see where it would have gone and decide for yourself.
• Slack gets the same treatment, applied to the text, because Slack renders it rather than Memtro. A disguised link arrives with its destination spelled out. Memtro also never asks Slack to unfurl a link or an image.
• Credentials are scrubbed from anything written out — a job's report, a Slack answer, a saved conversation — and refused outright inside an action's arguments. An assistant has no honest reason to put a key into another system.

Memory says who stood behind it

Every memory records whether a person was there. A fact stated in a conversation somebody was having is trusted. Everything else — learned by a job nobody watched, lifted from a connector crawl, written during a turn that had read outside content — is marked unverified.

Unverified memory is still used. It is not hidden and not thrown away, because most of what Memtro knows about your systems came from reading them. What changes is its standing:

• It carries the label and the system it came from into every answer, so the model is told what it is reading.
• It ranks at half the weight of something a person said.
• It cannot replace, overwrite or contradict a fact a person stated.
• Two connector crawls cannot confirm each other. Reading the same claim in two synced systems is not two sources; it is one claim, twice.
• A claim made in a conversation expires in fourteen days unless somebody confirms it or restates it. A quote of a record in another system has no deadline, because the record is the truth and Memtro is only pointing at it.
• Promotion is a person, on a page. There is no tool for it. A model confirming what it just claimed is not confirmation.

A memory write whose grammar is an order rather than a fact is held outright on an unwatched run. "Always send remittance advice to this address" is not a thing Memtro learns from a document, because its value to whoever wrote it is precisely that everyone would read it as authority.

Content is labelled as content

Everything a connector, a web page or an MCP server returns reaches the model inside a marked block that names the system it came from and says, in the same breath, that a request inside it is part of a record rather than an instruction. Before it goes in, the characters a reviewer cannot see are stripped, the tokens that forge a turn boundary are replaced, and any attempt to imitate the block's own markers is rewritten — including the trick of closing it early so that what follows reads as the system talking.

Be clear about what this buys, because the industry has measured it: labelling roughly halves attack success on a fixed test set and is worked around once somebody writes for it. It is not the boundary. It is what makes the boundaries above fire less often, and what lets the part of Memtro that reads tool output tell a record's contents from a request.

The sandboxed CLIs

Running Claude Code or Codex on your own subscription is the one case where a vendor's own tool executes, and it executes in a throw-away container: every Linux capability dropped, a read-only root filesystem, no new privileges, nothing from the host mounted, and limits on memory, processes and time. It reaches Memtro over the MCP endpoint with a token minted for that one run, valid for that one endpoint, and dead the moment the container exits.

There is a stricter mode for the credential itself. Switched on, the container is given no provider credential at all: it holds a token that only works through Memtro's own proxy, Memtro holds the real credential, and the container's network drops everything except the route back. It is a setting rather than a default, for an honest reason — the list of endpoints a vendor's CLI may call is the part of that design most likely to be incomplete, and getting it wrong stops the engine working. It wants one proven run before it becomes the default.

See what it would do before it does it

Every organisation starts in report mode. Each decision is reached and recorded; none of it is applied. You can read what would have been refused, see which of your jobs need a permission written, and grant them, before anything stops working. Turning enforcement on is then a deliberate step, taken once you know what it costs.

This matters more than it sounds. A security control that silently does less work than you asked for is worse than one that fails loudly, because the job still produces a report and nobody reads a report looking for what is missing. Report mode is how you find that out on your own schedule.

Job reports say what they could not do. A run that wanted to act and was held lists it under "Not done, waiting on a person", with a link to grant it, rather than leaving a gap in the prose.

What this does not do

Worth saying plainly, because a list of defences with no limits is a sales page.

• An action inside a permission you granted. A job allowed to post to one channel can be made to post the wrong thing in that channel. A permission pins where, never what — pinning the words would mean granting one sentence.
• Text that only changes a reply. If an injected instruction makes Memtro summarise something misleadingly and no tool is called and nothing is remembered, nothing here fires. Treat an assistant's prose as an assistant's prose.
• What you ask for yourself. If you read the injected email and say "reply to that", that is you deciding.
• A confirmation given without reading. The unverified queue is only as good as the person working it.
• Memory already poisoned before these rules existed. Memtro can tell you what came from where; it cannot retroactively know who stood behind a row written last year.

Reporting something

If you find a way through any of this, email security@memtro.com. We acknowledge reports within two working days. We would much rather hear it from you.