Calling a detector

A gateway can call the detector you already pay for. Every gateway in post 7 does, and the plugin list there is mostly wrappers for that call.

What comes back is a verdict about a string.

What the detector sees

A detector is reached by an API call from something else that holds the connection. That something takes a body, or part of one, and sends it as text. The detector answers: there is a card number at offset 412, there is a prompt injection with confidence 0.93, this output contains a person’s name. That answer is good, often better than anything a gateway would build for itself, and the security team that bought it was right to.

The string is missing the credential that signed the request, so the detector cannot know whose call this is or what budget it draws on. It is missing the provider’s response until that response is complete, so a streamed answer is either scanned after the client has it or held whole until it can be sent. And it is missing the bytes the provider actually received, because the detector saw a copy, made by the thing that called it, before or after whatever else that thing did to the request.

The verdict cannot speak to any of those. It can say “this text contains a card number”. It cannot say “this key sent a card number to this model under this rule, and here is the signed record”. The process holding the connection composes that second sentence out of the verdict and everything the verdict did not have. That composition is the decision, and the detector is one input to it.

Vendors that moved into the path

Some detector vendors noticed this and shipped a server, a gateway or a network hook of their own, so that their product holds the connection instead of answering a call. NeMo Guardrails runs as a server that speaks the chat-completions API. Palo Alto’s Prisma AIRS, which absorbed Protect AI, sells a gateway and intercepts at the firewall. Lakera, now part of Check Point, describes runtime enforcement instead of detection. Once a product holds the connection it is on this map as a gateway or a proxy, and belongs in those posts. Its detection is still an input, now to itself.

The concession is about topology, not integration. A detector vendor whose product sits in the path runs beside pistra or in front of it, and which is right depends on which one you want holding the record. A classifier that runs beside the stream is an input like any other, from whichever vendor. The box at the end says which classifiers pistra ships and which it does not.

Who should buy a detector anyway

Anyone who needs a kind of content recognised that the process on the path cannot recognise itself. Prompt injection, jailbreaks, toxicity, a hallucinated citation: these are classifier problems, the classifiers are the detector vendors’ whole business, and a gateway that claimed to have solved them in-house would be wrong. Buy the detector. Then decide separately what holds the connection and what it does with the verdict.

What pistra does at this box

pistra ships a first tier of detection in-process: 74 pattern recognizers derived from Presidio, each with its checksum validator where upstream has one, so a card number that fails Luhn is not reported as one. It ships a second tier that runs a transformer token-classifier in-process for the entities patterns cannot find. And it takes any detector that speaks Presidio’s analyzer protocol as a remote input, so an existing deployment needs no adapter. Findings from all three arrive in the same shape and the same rule language decides on them: deny, redact the span, or annotate the record.

On a stream, the decision runs on each frame, and the frame is held back as far as the enabled recognizers could still match. For a card number that is twenty bytes. The client sees the stream a few bytes late, and the digits do not reach it.

All posts