KYE Counterparty Governance Rail™ · partners · suppliers · 3rd-party AI agents · one rail

Govern every counterparty acting on your behalf — with the same protocol that runs your runtime.

KYE Counterparty Governance Rail™ is how KYE Protocol™ governs every external party acting on your behalf — partners, suppliers, and 3rd-party AI agents (a vendor's AI procurement agent, a SaaS-shipped AI legal agent, a partner-deployed customer-service bot). Each counterparty joins the registry, holds scoped authority bounded by a Purpose Permission™ grant, embeds widgets, ships through the partner/supplier app, earns certification, and surfaces deals — all under the same Authority · Purpose · Scope · Decision · Evidence kernel as direct customers. Partner-Rail is the founding instance; the rail naturally extends to supplier-rail + 3rd-party-agent-rail as the same primitives apply.

person_add Registry verified_user Authority widgets Widgets apps Partner App workspace_premium Certification payments Deals
1 · Partner Registry

Every partner is an entity.

Each partner organisation receives a KYE-ID and joins the directory. Tier, sector, jurisdiction, and certification status are queryable — the same way customers find auditors, integrators, or implementers.

arrow_forward Partner directory

2 · Partner Authority

Partners hold scoped authority.

A partner can act on behalf of a customer only when the customer grants them an explicit scope. Every partner action is bound to a delegation chain, evaluated by the same Decision Engine that runs the customer's own runtime, and replayable.

3 · Partner Widgets

Embed authority where the work happens.

Drop-in widgets carry KYE™ authority into a partner's own UI. The widget queries the partner's grants, renders only what the partner is permitted to do, and emits the same evidence as a first-party call.

arrow_forward Widget catalogue

4 · Partner App

A workspace shaped for delivery.

Partner App is the partner-facing workspace inside KYE Cloud™: customers you serve, scopes you hold, deals you originated, certifications you earned, evidence you signed. Owners-only data stays out; partner-relevant context stays in.

5 · Certification

Earn a tier, prove it publicly.

Four tiers (Registered → Certified → Implementer → Authority). Each tier is earned through measurable conformance + delivery, never assigned. Status is publicly verifiable in the Directory; lapsed certifications are listed openly.

arrow_forward Certification tracks

6 · Deals & Co-sell

Source, share, settle.

Partner-sourced deals carry a signed origination claim from the moment they land. Revenue share, lead share, and settlement use the same audit chain as runtime decisions — no parallel CRM truth.

arrow_forward Talk to us

Ready to see your AI agents flagged?

Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.

rocket_launch Apply for pilot → science Try the sandbox →
v1.1 · KYE Federation Cross-Org Delegation™

When the agent acts across organisational tenancy boundaries.

The single-tenant Authority Chain™ assumes the root principal and the acting agent live in the same KYE™ tenant. Cross-organisation delegation breaks that — your supplier's agent acts under your authority; your bank's procurement agent acts under a treasury VP's grant; a SaaS-shipped legal-AI agent acts on a counterparty's behalf. KYE Federation Cross-Org Delegation™ binds the chain across hops without depending on any tenant's runtime.

  • Per-hop independent signatures. Each hop in the chain is signed by its issuer tenant against that tenant's published JWKS. A verifier can walk the chain offline — no live API calls into any tenant, no shared trust root.
  • JWKS snapshot pinning. Each hop optionally pins the content-addressed hash of the issuer's JWKS at issuance time, so the verifier detects key rotation and revocation deterministically on later replay.
  • Declared attenuation invariant. Every chain carries an explicit invariant — scope-subset-monotonic, scope-equal, or scope-explicit-narrow. The verifier rejects chains that break the declared invariant, without depending on the runtime's attenuation logic.
  • Bounded chain depth. Maximum 16 hops; pathological depth is a violation. Real-world chains are 2–4 hops (principal → tenant → sub-delegate).

Schema: kye.federation.cross_org_delegation.v1. Example envelope: /examples/federation/cross_org_delegation.json. Algorithm internals (attenuation propagation, multi-hop validation order) are proprietary and are not disclosed in the public spec.