--- title: "KYE™ Counterparty Governance Rail™ — partners · suppliers · 3rd-party AI agents acting on your behalf · KYE Protocol™" description: "KYE™ Counterparty Governance Rail™ — the runtime governance surface for every external party acting on your behalf: partners, suppliers, and 3rd-party AI agents. One registry, one authority kernel, one evidence envelope across all counterparty classes.…" url: https://kyeprotocol.com/counterparty-governance-rail/ lang: en source: "KYE Protocol" --- > KYE™ Counterparty Governance Rail™ — the runtime governance surface for every external party acting on your behalf: partners, suppliers, and 3rd-party AI agents. One registry, one authority kernel, one evidence envelope across all counterparty classes.… KYE™ Counterparty Governance 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. 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. [Partner directory](https://kyeprotocol.com/partners/) 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. [Widget catalogue](https://kyeprotocol.com/widgets/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. [Certification tracks](https://kyeprotocol.com/certification/) 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. [Talk to us](https://kyeprotocol.com/engage/) ## Ready to see your AI agents flagged? Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) 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. Canonical KYE™ surfaces referenced on this page: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE™ Cloud™](https://kyeprotocol.com/apps/) · [KYE Protocol™](https://kyeprotocol.com/) · [Purpose Permission](https://kyeprotocol.com/glossary/).