Can we keep our guardrails library and add the gate?

Yes — that’s the intended shape. The library keeps doing app-level validation where it’s strongest; the gate enforces boundary policy across everything that routes through it. They operate at different layers and don’t contend: your code path keeps its library, your base URL gains a gate.

Isn’t an in-process library faster than a network hop?

For the check itself, yes — in-process is microseconds and a gate is a hop plus under 50ms of enforcement budget. We concede that plainly. The question is what the check needs to be: for app UX validation, stay in-process; for enforcement you have to prove ran on every request, it belongs where every request passes and where the verdict gets signed.

Our library supports custom validators — can the gate match that flexibility?

Not at the app level, and it doesn’t try. The gate’s policy DSL covers boundary concerns — PII, targets, risk bands, verdicts — and stays deterministic on purpose. Rich, app-specific validation logic belongs in your library; policy that must hold across the estate belongs in the gate.

vs guardrails libraries

A library protects an app. A gate covers the estate.

In-app guardrails libraries are genuinely useful — output validation, schema checks, app-specific rails, all microseconds from your code. What they can’t be is infrastructure: they cover the apps someone instrumented, enforce whatever each team configured, and leave evidence in application logs. That’s the layer AnchorGate exists for.

Get started — it's free View on GitHub

How it composes

They stack, in the literal sense

Keep the library for app-level validation; the gate picks up everything at the boundary. Your app’s code path doesn’t change — the base URL does.

# in the app: your guardrails library, as today

# at the boundary: every request crosses the gate

export OPENAI_BASE_URL=http://anchorproxy:8080/v1

The difference in kind

Two jobs, done by the layer built for each

These rows compare purposes, not feature checklists — their features ship weekly and ours do too, and a stale checklist helps nobody.

In-app guardrails libraries

AnchorGate

In-app guardrails libraries

Live inside one application’s process — checks run exactly where the app calls them, microseconds away.

AnchorGate

Live at the network boundary — every request from every app that routes through the gate crosses the same policy, including apps you didn’t write.

In-app guardrails libraries

Coverage equals instrumentation: each team adds the library, pins a version, and configures its own rules.

AnchorGate

Coverage equals routing: one deployment, one human-approved policy bundle, applied uniformly — plus shadow-AI discovery for the traffic that isn’t routed yet.

In-app guardrails libraries

Validation logic is the app team’s choice — including model-based validators where they fit.

AnchorGate

Enforcement is deterministic and fail-closed by design: a compiled DSL where the same input always gets the same verdict, because the verdict goes on the record.

In-app guardrails libraries

Results land in application logs — useful for debugging, invisible to an audit.

AnchorGate

Every verdict is a signed decision event on an append-only ledger, graded L1–L5, exportable as an offline-verifiable Trust Packet.

Characterization accurate as of July 2026. If we’ve gotten something about In-app guardrails libraries wrong, tell us and we’ll fix it.

The honest split

Where each one earns its place

Use a library for

Output structure and schema validation deep in app logic
App-specific rails and UX fallbacks close to the code
In-process checks where microseconds matter
Validators the app team iterates on daily

Add AnchorGate for

Uniform, fail-closed enforcement across every routed app
PII redaction before egress — including apps with no library
MCP tool-call gating and shadow-AI discovery
Signed evidence and compliance posture an auditor can use

FAQ

Composing with In-app guardrails libraries

Can we keep our guardrails library and add the gate?: Yes — that’s the intended shape. The library keeps doing app-level validation where it’s strongest; the gate enforces boundary policy across everything that routes through it. They operate at different layers and don’t contend: your code path keeps its library, your base URL gains a gate.
Isn’t an in-process library faster than a network hop?: For the check itself, yes — in-process is microseconds and a gate is a hop plus under 50ms of enforcement budget. We concede that plainly. The question is what the check needs to be: for app UX validation, stay in-process; for enforcement you have to prove ran on every request, it belongs where every request passes and where the verdict gets signed.
Our library supports custom validators — can the gate match that flexibility?: Not at the app level, and it doesn’t try. The gate’s policy DSL covers boundary concerns — PII, targets, risk bands, verdicts — and stays deterministic on purpose. Rich, app-specific validation logic belongs in your library; policy that must hold across the estate belongs in the gate.

Instrument nothing. Gate everything.

One deployment covers every app that routes through it — including the ones nobody instrumented and the ones discovery finds. That’s the point of infrastructure.

Deploy the stack

or email hello@anchorgate.ai