Penweir is in development, and this page describes the Phase 1 behaviour. We would rather tell you where the limits are than let you find them.
It guarantees
No payload is stored. Prompts, completions, tool calls, tool results and the token mappings that restore redacted values live in memory for one request and nowhere else. They are not written to the database, the logs or any file. There are no metrics or traces to leak into.
- How: the token vault is wiped when a request ends, however it ends. Logs are built from an allow-list of typed fields, and exception messages are reduced to type names. Error responses use fixed messages.
- How it is tested: an automated test sends unique canary strings through the real server on every path: success, streaming, upstream errors, invalid and blocked requests, blocked answers, bad keys and dropped clients. It then searches the database files, the logs and the temporary directory, on SQLite and on Postgres. One hit fails the build.
The audit log holds metadata only. Who, when, which application, pipeline, provider and model, token counts, latencies, how many values each detector found, and what was done to them. Every string in an audit event is an identifier or a fixed code, and a schema test fails on any column that could hold free text.
Configured detectors run on every request. Request steps run before any provider call, on message text from every role, tool results, tool-call arguments and the user field. If a pipeline names a detector that does not exist, the gateway is not ready. It does not run without the step.
A block is a block. A block step stops the request before any provider sees it. A response block stops the answer, and in a stream the matching value is never sent.
Tested against a fake provider. Under the example policy, IBANs, email addresses and BSNs never reach the provider.
No calls home. Penweir talks only to the providers in your configuration. A container test runs the image on a network with no route out and checks that it still works.
It does not guarantee
It does not detect names or free-form addresses in free text. Detection is rule-based: patterns plus checksums for structured identifiers. “Jan de Vries lives at the end of the street” passes untouched. For structured data, use field steps on keys such as customer_name.
It cannot catch every format. A detector finds what it is built to find: an IBAN with its letters spelled out, or a phone number written in words, passes. Patterns are tuned to prefer false positives over misses.
It does not scan images, audio or files. They are refused unless a pipeline sets allow_non_text. Then they pass unscanned.
A detection in a name or id blocks the request. Tool names, schema names, message names, tool-call ids and JSON keys cannot be rewritten without breaking the request, so a detector hit there blocks it instead.
It does not protect what the model does with the data it gets. Penweir decides what reaches a provider, not what the provider does with it. Pick providers and data-processing terms accordingly.
It does not protect against a compromised host. Whoever controls the machine running Penweir can read its memory, its master key and its traffic.
Tokens are not encryption. A token such as [EMAIL_1#a3f9c2] hides the value from the provider. The provider still sees that an email address was there, and that two mentions are the same address.
Hashes can be guessed for small value spaces. hash uses a secret key per installation. A provider cannot reverse it without the key, but anyone with the key can test guesses.
See the threat model for who Penweir protects against, and the security page for the architecture.