KYE Protocol · Deploy a Governed Agent

Deploy a governed agent on your own infrastructure.

You run real, sector-specific agent code on your side of the wire. KYE Protocol governs only the action boundary — the instant before an irreversible call — and proves who authorised it. Your agent, your model, and your customer data never leave your infrastructure: the enforcement point sends KYE Protocol a claim about the action, not the payload. Deploy on the SaaS edge, in-region and tenant-isolated, or from a gateway inside your own VPC. Each governed action seals an Evidence Pack, cutting audit and dispute evidence work from days to minutes.

1 · The fleet is real

Real agents, not an abstract wrapper.

A KYE Governed Agent is deployable agent code bound to one consequential job in one sector — governed, evidenced, and stoppable — never a generic shell around your model.

If your team is standing up an agent in a regulated flow, the first thing you want to see is that governance is specific to the decision your agent actually makes. KYE Protocol publishes a bounded fleet, each agent bound to named controls: the KYE Underwriting & Risk-Acceptance Authority Agent and KYE Quote & Bind Authority Agent, the KYE Claims Decision Authority Agent and KYE Policy Lifecycle Authority Agent for insurance; the KYE Account-Opening CDD Authority Agent and KYE Sanctions & AML Authority Agent for banking; the KYE DSAR Evidence flow for privacy; and the KYE Framework Mapping Agent and KYE Risk Agent for governance operations. Each is listed on the KYE Governed Agents page, derived from the canonical product registry so the list can never drift.

  • verifiedSector-bound. Each agent maps to a named regime — an insurance underwriting decision to the relevant conduct rules, an AML decision to sanctions-screening obligations — not a one-size policy.
  • boltDeployable. You scaffold a new agent with the KYE Agent Dev Kit or wrap an agent you already run; the governance ships with the code, not as an afterthought.
  • shieldGoverned by construction. Every scaffolded agent emits the constitution §0.3 evidence-event family on first run — self-governing by default.
2 · Three deployment models

One action boundary, three places to run it.

You choose where the PDP — the KYE Protocol decision engine — runs, based on your data-residency and isolation needs. In all three models your agent code and customer data stay customer-side.

ModelWhere the PDP runsBest when
SaaS edgeThe KYE Protocol edge runtime (constitution §16, edge-native compute and a structured datastore) as a multi-tenant service.You want the fastest path to a governed pilot with no infrastructure to run.
In-region, tenant-isolatedA dedicated PDP in your region, with your trust domain isolated per constitution §0.11 (a trust_domain_id predicate on every tenant-scoped read).You have data-residency rules and need a hard tenant boundary.
Self-hosted gatewayA KYE Gateway inside your own VPC (constitution §25 KYE Edge Governance), carrying a KYE Compiled Authority Bundle, the KYE Edge Arbiter, a KYE Safety Floor, and a KYE Offline Evidence Log.You need decisions to work in your network — air-gapped or offline — with nothing leaving the perimeter.

The common thread across all three: the PEP beside your agent sends the PDP a claim describing the action — the actor, the purpose, the scope, the limits — never the underlying record. Keys stay customer-held under bring-your-own-key, so KYE Protocol proves authority without ever holding your data or your secrets.

3 · The request lifecycle

Intercept before the irreversible call, then seal the proof.

Your agent decides to act; the PEP holds that action at the boundary until KYE Protocol returns a verdict; only an allow verdict lets the real call run — and the whole decision is sealed as evidence.

Governed agent request lifecycle Your agent decides to act; the policy enforcement point intercepts before the irreversible call and sends a claim to the KYE Protocol decision point, which resolves principal, delegation, purpose, scope, limits and t equals zero, then returns allow, deny, constrain or step-up. Only allow executes the real call, and an Evidence Pack is sealed and made replay-verifiable. YOUR INFRASTRUCTURE KYE PROTOCOL™ — ACTION BOUNDARY Agent decides to act real, sector-specific agent code — your model PEP intercept @kye/pep-express — holds the call, sends a claim PDP resolves authority principal · delegation · purpose · scope · limits · t=0 admissibility ALLOW deny · constrain · step-up (human) Execute the real call only on ALLOW — the action ships your side Evidence Pack™ sealed → Replay-Proof™, verifiable from public keys alone
A projection of the real seam: @kye/pep-express intercepts, KYE Protocol decides via Action Admissibility, and only an allow verdict releases the call.
  • pan_toolIntercept. The PEP holds the action the moment before it becomes irreversible — a payment, a bind, a disclosure — and sends the claim.
  • balanceDecide. KYE Protocol resolves whether this principal holds delegated authority for this purpose, in scope, at this moment, and returns allow, deny, constrain, or step-up.
  • how_to_regEscalate. A step-up routes a human approval through WebAuthn hardware sign-in or the governed approval surface before the action may proceed.
  • verified_userSeal. Allow or deny, the decision seals an Evidence Pack you can replay offline from public keys alone.
4 · The deploy journey

Four commands from scaffold to governed.

You discover the fleet on the KYE Governed Agents page, scaffold with the KYE Agent Dev Kit, wrap your actions with the enforcement point, then test and deploy — typically a same-day path for your first governed action.

# 1 — scaffold a self-governing agent (emits the §0.3 evidence family)
$ kye agent new claims-triage --lang ts --template kyc

# 2 — bind authority: principal, tool register (§52), limits, approval thresholds
#     wrap each consequential action with the PEP middleware
import { withKye } from '@kye/pep-express'

# 3 — prove conformance before you ship
$ kye agent test        # runs the conformance-runner
$ kye agent doctor      # checks bindings, evidence emission, kill-switch

# 4 — deploy; every action now seals an Evidence Pack™
$ kye agent deploy --target cloudflare

You bind the agent's identity as a first-class principal, register the tools it may call under constitution §52, set per-action limits and the approval thresholds that trigger a human step-up, and wrap each irreversible action with @kye/pep-express. For an inference-time boundary, the inference PEP governs the model call itself. Then kye agent test and kye agent doctor run the conformance checks so you ship green, not hopeful.

5 · Operate

Evidence per action — and a mandate that can be pulled mid-flight.

Once your agent is live, every governed action produces an Evidence Pack, and the authority behind it stays under continuous watch rather than being granted once and forgotten.

If the agent's behaviour drifts from the authority it was granted, the drift detector raises it; if the mandate must be withdrawn, the authority-revocation orchestrator suspends it in-flight — the next action is denied at the boundary, no redeploy required. That is the difference between a one-time permission and a living authority: KYE Protocol can stop a bounded agent the instant its right to act lapses, and every stop is itself an evidenced, replayable event.

6 · Honest boundary

KYE Protocol governs the boundary — it does not run your agent.

KYE Protocol proves exactly one thing, and proves it completely: whether the actor was authorised to take the action.

It does not host your model, execute your agent's logic, or replace your application — you keep all three. It competes with no agent framework. What it adds is the layer that decides whether a consequential action may proceed and seals the proof that it was authorised, so a regulator or a counterparty can replay the basis. Bring your own agent and your own data; add the boundary that makes every consequential action defensible.