The agent that talks can't look. The agent that looks can't talk.

This post covers three things: what prompt injection is, why you can't fix it in the prompt layer, and what we built instead, as part of how we secure our agentic support platform. This topic comes up in nearly every security review we go through, usually some version of, "what stops your AI from handing our data to whoever asks nicely?"

The short version: beef up your agent, assume it can still be tricked, and design the infrastructure so that being tricked doesn't get the attacker anything.

What is prompt injection?

This is a well-known phrase now, but it's worth a quick recap. Prompt injection happens when text somebody else wrote arrives through the same channel as the instructions you write, and the AI model has no reliable way to tell them apart.

Usually the intent is to break your agent's intended behavior; for example, to exfiltrate sensitive data, or trick your AI into solving an unrelated problem. Security researchers have an older, broader name for this shape of problem, the "confused deputy." It evokes an image of someone with real authority, talked into using their extended power on behalf of a stranger.

In a support product, that stranger gets in through the ticket: the message body, the forwarded email thread underneath it, the PDF someone attached, the text sitting inside a screenshot. All of it written by people outside your company.

You can't remove this input, because reading what strangers wrote is the goal of a support system.

Why you can't fix it in the prompt layer

Every AI-fluent builder's first idea is to write their way out. Tell the model to ignore instructions it finds in ticket content, never reveal internal data, and refuse anything off-topic.

That helps, and it works often enough to feel like a control. The leading AI research labs have teams devoted to making models better at resisting this, and the progress is real. Boris Cherny described Anthropic's newest frontier model as their least prompt injectable model yet, with supporting evaluations in the model's system card. They're careful not to overstate that progress, though: in a separate report on browser agents specifically, Anthropic wrote that no browser agent is immune to prompt injection, and said they share findings like this to demonstrate progress, not to claim the problem is solved.

Whatever resistance rate you land on with your own model, compare it against real-world volume. Even a low single-digit failure rate works out to several tickets a week where the guard might not hold. A percentage is not a boundary. A better model lowers the rate everywhere at once, and it's worth paying for, but it still doesn't give you anything you can stand by in a security review.

So we changed what the input can reach

If you can't stop the untrusted input, the only thing left to change is what that input can reach.

Simon Willison's "lethal trifecta" names the three ingredients that are dangerous together: access to private data, exposure to untrusted content, and the ability to communicate externally. We've already established that untrusted content is required for any support system, so that leaves two to trade.

Meta turned the same idea into a rule they call the Agents Rule of Two. An agent gets at most two of the three in one session, and anything that needs all three doesn't run unsupervised.

Here's how we split it.

• Our Support Agent is the one that talks. It replies to customers on its own, with no human in the loop, and in exchange it has no access to past tickets, no internal notes, and no connectors unless you turn them on.
• Our Background Agent is the one that looks. It reads full ticket history and calls connectors into your other systems, and it can stage a reply, but no answer reaches a customer until a human approves it.
• Assist Agent and Slack Agent are a third variation. They run as your own session, inherit your permissions, and also require human review before a reply goes out.

Each card gives up a different leg of the trifecta, and between them they still cover the whole job. The agent that talks can't look, and the agent that looks can't talk.

There's a second layer to this, in how we build the tools themselves. The inputs that matter most to a data-access tool are system-determined, not agent-defined: which account, which contact's email, and so on, pulled directly from Pylon's system fields. The agent can never see those input parameters, let alone alter them, so it has no way to cause cross-account leakage.

This applies to every tool built on Pylon's own architecture. Remote MCP connectors work differently: as a secure default, we only enable them for the agents that already require supervision, Background Agent, Assist Agent, and Slack Agent. We're building the controls to extend the same system-determined mapping to Support Agent, so it can eventually use connectors under the same guarantee.

What it costs us

None of this is free.

Our Support Agent can't read ticket history, so to let it answer from past resolutions, we generate a knowledge base from ninety days of already-resolved tickets, with a required pass to sanitize PII and account-specific detail.

The other cost is a handoff. Background Agent and Assist Agent do all the investigative work, but require a final human review before sending a reply.

It would be simpler to let Background Agent investigate and hand Support Agent a summary to send, skipping human review entirely. We don't do that, because it quietly recombines all three legs of the trifecta in one step, and a redacted summary doesn't neutralize an injection, it just hides it from the audit trail.

To recap, here are the three things we'd advise anyone trying to build their own solution:

1. Decide which leg of the trifecta each agent gives up, before you write its prompt.
2. Treat model hardening as a way to reduce risk, never a full removal.
3. To actually remove a risk, make the dangerous outcome unreachable rather than unlikely.

A mitigation reduces probability. A guarantee removes reachability.