The trick: 23 standards → 8 properties

Strip the labels, and they demand the same handful of things:

Compliance teams call this control mapping — and it's usually a 1,400-row
spreadsheet and a consultant. We built the 8 properties into the code instead.

The payoff: add the 23rd standard and you write zero new code — you
already satisfy it. Compliance cost stops scaling with the number of regimes.

The architecture that satisfies them

The 8 properties are baked into how the code is built — so they hold everywhere,
not just where someone remembered to add them:

• One way in for every dependency — nothing reaches in through a back door, so there's one place to audit
• Swappable parts behind clean seams — the cache, search, and audit layers can change without rewriting callers
• One encryption routine — a single AES-256-GCM helper for all at-rest encryption (opt-in via a key), never re-implemented per feature
• One safe web-fetch client — every outbound request goes through the same SSRF-checked path
• An audit log on every tool call — structured, secrets stripped out, and it never slows the request

"Compliance through architecture, not bolt-on checklists."

The safest config is the default config

Run it the normal way — locally, inside your AI app — and there's no network
port open, no login to misconfigure, nothing exposed to the internet. The app
that launched it is the only thing that can reach it. The typical user can't
hold it wrong, because there's nothing to set.

The heavyweight controls for shared, multi-user deployments — sign-in, per-customer
isolation, rate limits, encryption, audit logs — only switch on when an operator
deliberately runs it as a network server.

Secure by default, permissive by configuration. Power is unlocked by an
explicit choice, never the reverse.

Controls, not certificates: the honest line

"Compliance as architecture" ships the controls. It can't ship the operating
organization a certificate requires — so here's the split:

So "aligned with 23 standards" means we provide the technical controls each one
requires — not that an organization has been audited against them. A binary
can't clear a hospital's HIPAA bar; it hands that review its evidence.

Agency sharpens one old threat — and adds a new one

Give an AI a tool that fetches any page, and it now chooses the URLs. That
amplifies an old vuln and surfaces a new one:

Old vuln, now automated — SSRF (OWASP Web A10). A hijacked link can steer an
autonomous fetch at your internal network. So before any fetch the server
rejects private/reserved IPs and cloud-metadata hosts, connects only to the
exact resolved address (DNS-rebind defense), and re-checks on every redirect.

A genuinely new class — indirect prompt injection. A booby-trapped page can
try to hijack the AI reading it. The server strips active markup, caps size, and
stamps every result that carries external text with an untrusted-external-content
marker — in the JSON envelope, never inside the content where a page could forge
it, and enforced by a cross-tool drift test so a new tool can't ship unmarked.
It does not enforce the prompt boundary — that's the host's job, where the
model and agent loop live.

Prompt injection is #1 on OWASP's LLM list, and the agentic rules are still
being drafted. This tool sits squarely in that gap.

An erasure registry you can't outrun

Privacy starts with collecting little: the cache is content-addressed (not keyed
to a user), and the operator — not us — is the data controller. But the moment a
feature does store personal data, "right to be forgotten" has to actually work.

So it's enforced structurally: every store that holds personal data must
register an Exporter + Eraser. One (tenant, user) request fans out to all of
them — and each store ships a round-trip release-gate test.

Add a new feature and forget to wire its eraser? CI fails — not an auditor.
GDPR access / portability / erasure (Art. 15 / 17 / 20) becomes a property of
the build, not a promise in a policy PDF.

shipped in v1.13

Consent as a primitive: record → verify → honor

The AI-tool standard (MCP) says asking the user for consent is the client
app's job — so most servers do nothing. But whoever stores the data is, in
law, the data controller, and GDPR / Quebec Law 25 make them prove consent
was given and honor a withdrawal — a duty a login token can't discharge.

So the server treats consent as three things it actually does:

• Records it — encrypted, logged, with a typed purpose ("memory," "analytics," "workspace").
• Verifies it on every access — no record, no processing (it defaults to off).
• Honors it — a withdrawal automatically erases the data it covered.

shipped in v1.13

The docs are tested, not trusted

"Keep the docs accurate" isn't a good intention here — a stack of small
mechanisms makes drift hard to write and impossible to merge quietly:

The judgment — threat models, standards crosswalks — lives in prose and gets
human review. Where a claim is enumerable, the build enforces it.

So what is this actually worth?

The same architecture pays off differently for everyone who touches it:

Compliance stops being a project you fund and becomes a property you inherit.

What transfers to any project

1. Map standards to primitives, not checklists — satisfy many at once.
2. Make the default the safe one — gate power behind explicit config.
3. Let compliance scale with features (tiers) — not a big-bang program.
4. Encode the rules as constraints, enforce them in CI — including for AI coding agents.
5. If a doc can be wrong without a test failing, it will be — so test it.

Honest boundaries: "aligned with," not "certified." The local and server threat
models differ. By default it stores little; the features that do store personal
data are opt-in, consent-gated, and erasable — not absent.