If it reads your prompts, it is a data processor

There is one question that separates AI agent security products into two groups, and almost nobody asks it in a demo.

What do you have to read in order to work?

Not what you can be configured to redact. Not what you promise to discard. What is required, minimum, for the product to do its job at all.

Why the answer is usually "everything"#

A large part of this market decides by understanding. The product ingests the agent's prompt, the model's response, and each step of its reasoning, and a second model judges whether what the agent is trying to do looks acceptable in context.

That is not a lazy design. It is genuinely powerful, and it catches things no other approach can: an agent being talked into something by content it read, an instruction that only looks wrong in light of the previous four turns, intent that is obvious to a reader and invisible in a log.

But look at what it requires. To judge the intent, the product has to see the context. To see the context, it has to receive it. And the context is not abstract: it is the patient record your agent just read, the salary table it summarized, the unreleased results it was asked to check.

What that makes the vendor#

Under GDPR the label is not a matter of opinion. A company that processes personal data on your behalf and under your instructions is a processor, and you are the controller. That is not an accusation, it is a category, and plenty of excellent companies live in it.

It does have a bill attached, and the bill lands on you:

• A data processing agreement, negotiated, with Article 28 terms
• A new entry on your subprocessor list, which your own customers are entitled to be told about
• A transfer assessment if any of it leaves the EEA, which for most of these vendors it does
• A conversation with your DPO, and in a regulated shop, probably with your regulator's expectations in mind
• A new answer on every security questionnaire you receive for the rest of the product's life

None of that is fatal. It is a project, and it is a project that recurs. The point is that it is a consequence of the architecture rather than a policy choice, so no amount of goodwill from the vendor removes it. They cannot switch it off, because reading is how the product works.

The other way to decide#

An action has a shape before it has a meaning.

Before any agent does anything that matters to your company, the action can be described completely without reading a word of what the agent said or thought:

• Which credential is being presented
• Which system it is being presented to
• Which operation is being attempted
• On whose behalf, and under what standing grant
• When, and from where

That is enough to answer the questions that actually govern an agent. May this credential reach production? May this agent push to a protected branch? Has anyone approved a migration on this database? Is this a system nobody granted it at all?

None of those need the prompt. They need the shape, and the shape is available at the credential and at the door, where the action arrives.

What the shape cannot tell you, honestly#

This is the trade and you should know both sides of it.

A decision made on shape can tell you an agent is emailing an external address. It cannot tell you the email is a bad idea. If an agent is legitimately granted a capability and uses that capability to do something foolish inside its permissions, a shape-based decision sees a permitted action, because that is what it is.

Content inspection genuinely covers some of that gap. So the honest framing is not "reading is wrong." It is that reading has a cost most buyers price at zero, and there is a large class of governance, the class that includes almost everything irreversible, that does not need it.

We would rather be excellent at the part that needs no content and be straight about the part we do not cover than blur the two.

Where we actually stand, in three tiers#

The flat version of this claim, "we never read anything," would be easier to say and would die on the first follow-up. So, precisely:

Everything we ship reads nothing. Every decision is made on the shape of an action. No prompt, no response, no reasoning trace, no file content leaves anything or reaches us.

One tier that does inspect is scoped, off by default, and runs on your infrastructure with your own certificate authority. If you want content inspection, you should be able to have it. You should not have to send your content to a vendor to get it.

Even on that tier, the content does not reach us. We enable inspection. We do not perform it.

The distinction that matters here is legal, not technical. A product that must read to function cannot avoid becoming your processor. A product that inspects only when you switch it on, on hardware you own, with keys you hold, is not one, on any tier.

The question, again#

Take it to every vendor you are evaluating, including us.

What is the minimum you must read for your product to work at all?

If the answer is "the agent's context," the product may still be the right purchase. Just price the DPA, the subprocessor entry, the transfer assessment and the questionnaire answers into the decision, because they are part of what you are buying.

And if you are in a regulated shop where that project is the reason the whole evaluation stalls for two quarters, there is another way to decide.