Where does Decionis sit relative to Kong, Envoy, or Cloudflare?

[ocularminds]

There's a Kong plugin, and Envoy / Fastly / Cloudflare filters in the ecosystem. Are those Decionis enforcing at the gateway, and when should a team gate at the edge versus calling the SDK in-process?

[ocularminds]

Short answer: those adapters are enforcement points, and the verdict they enforce comes from the Decionis Protocol.

Presence is the human verification layer of Decionis — the Kong, Envoy, Fastly, Cloudflare and Vercel adapters ship as part of Presence, but they do not decide anything themselves. Each one calls through to the Decionis Protocol for the actual gate. Presence establishes that a real human is present; Decionis decides whether this action executes, and proves the verdict.

That layering is why an adapter stays deliberately thin: an adapter that re-derived its own verdict from a score would be out of contract.

What the adapters actually do

Each implements the same enforcement contract and enforces one of four dispositions — PASS, CHALLENGE, STEP_UP, DENY — failing closed on timeout or error.

Adapter	What it enforces
Kong	Verification on state-changing methods (POST/PUT/DELETE) matching your protected routes. Cache-first, with SHA-256 token digests as cache keys.
Envoy (proxy-wasm)	The same verification gate inside the mesh. Verification only — session minting and widget injection stay at the frontend edge.
Fastly / Cloudflare	Both halves: widget injection into HTML, and the verification gate on protected requests.

On a pass, a short-lived ES256 JWS is issued and adapters verify it offline against a published JWKS, so the hot path doesn't pay a round trip. The proof format is identical across all four; only the crypto runtime differs (WebCrypto, lua-resty-openssl, Rust p256).

How the verdict flows

Presence runs its deterministic checks locally, then hands a cryptographically bound signal package to the Decionis execution gate. Liveness becomes a policy input rather than a verdict — a low liveness score raises the risk on the decision, and device and presence evidence travel as decision context. The protocol's verdicts map straight onto what the adapter enforces: APPROVE → AUTHORIZED, REVIEW → RESTRAIN, ESCALATE → ESCALATE, REJECT → BLOCKED. If the protocol is unreachable, the gate fails closed.

Gateway/edge versus in-process SDK

Treat this as a wiring choice, not a policy choice — both paths run the same fail-closed pipeline, so picking one doesn't change what is enforced.

• A gateway usually fronts JSON APIs, where HTML widget injection doesn't apply — that's why the Kong plugin ships with injection off by default. Reach for the gateway when you want enforcement to land by configuration at an infrastructure choke point, without touching application code.
• Reach for the in-process SDK when the decision needs application context the gateway can't see — the cart, the margin, the wallet balance, the specific tool an agent is about to call. A gateway sees a request; your code sees the intent.

They compose, and in production they usually should: the edge establishes presence, the SDK gates the consequential action, and the same protocol decides both.

---

Related: How does Presence relate to Decionis? · Where Decionis sits in the stack · Can Decionis govern AI agent tool calls?

Have a different architecture or integration question? Start a new discussion — we answer publicly whenever we can.