Kenshiki

Secure entry point

Prompt Sanitizer

Where the request enters the system.

Every request enters through Input. Before the Compiler sees the question, Input establishes who is asking, what evidence they can access, and binds that identity through the entire pipeline via OpenFGA/ReBAC. No anonymous requests reach the bounded-synthesis pipeline.

Without this: the model receives requests with no identity context. Evidence scoping is impossible, audit trails have no caller attribution, and access control cannot be enforced at the retrieval boundary.

What Input does

Receives the raw request, authenticates the caller, establishes the ReBAC identity binding, and passes the authenticated request to the Compiler. The identity follows the request through every stage — from compilation through retrieval through generation through evaluation.

  • Authenticates the caller (Clerk for Workshop, customer IdP for Refinery/Clean Room)
  • Binds caller identity to the request via OpenFGA/ReBAC
  • Passes identity context to the Crosswalk for evidence scoping
  • Every audit record traces back to the identity established here

How identity propagates

The identity established at Input determines what evidence the caller can see. The Crosswalk uses the caller's ReBAC attributes to scope retrieval — the model only sees evidence the caller is authorized to use.

  • Workshop uses Clerk (social login, email, MFA)
  • Refinery uses customer IdP with enterprise SSO
  • Clean Room uses physical tokens (CAC, YubiKey, biometrics)
  • All tiers propagate identity through JWT to every pipeline stage

Who this is for

Application developers

integrate their application with the Kenshiki API. The Input layer handles authentication and identity propagation — the caller's application sends the request, Input binds the identity.

The pipeline

every downstream system (Compiler, Kura, Kadai, Ledger, Gate) receives the caller's identity and access boundary established at Input.