Cryptographic sovereignty

Audience: CISOs, CIOs, Risk and Compliance leaders, Enterprise Architects

Reading time: 22 minutes

Prerequisites: The Cryptographic Control Plane for architectural context

The core thesis

Cryptographic keys must never leave the data owner's control domain.

Third parties and internal systems do not own keys. They are authorized to invoke cryptographic capabilities under strict governance, in a mediated and auditable manner.

Every enterprise exchanges sensitive information with dozens or hundreds of third parties. When one of them has to process protected data, the organization usually hands over the key, or decrypts the data and hands over the cleartext. Either way, control over the data ends at the moment of sharing. Cryptographic sovereignty in third-party exchange is the architectural model that changes this: keys stay in the owner's domain, and third parties invoke cryptographic capabilities under governed, mediated and auditable conditions.

A third-party exchange preserves sovereignty when it has three properties at the same time:

Remove any one of the three and sovereignty collapses. Control without mediation is a key stored in a vault and then copied out. Mediation without evidence is a service whose use cannot be proven. Evidence without control is a log of decisions the owner could not have prevented.

Sovereignty is a property of the organization, not of the key. An organization that owns a key and hands a copy to a processor still owns the key, and has lost sovereignty over its use. Sovereignty concerns authority: who may exercise a cryptographic capability, under what conditions, for how long, and who can withdraw that authority, without the cooperation of the party whose authority is withdrawn.

This is a problem of today, not of the quantum era. A key handed to a provider is as exposed whether it is classical or post-quantum. Solving it requires neither a post-quantum migration nor a complete cryptographic inventory; it can start with the algorithms and HSMs already in place, and post-quantum readiness across external relationships follows as a consequence.

This page describes the principle, the problem it addresses, the paradigm shift it represents, and the scenarios it solves. It summarizes the ANKATech whitepaper Cryptographic Sovereignty in Third-Party Information Exchange; see ANKATech whitepapers.

The forces dismantling the traditional model

Four structural forces are dismantling the traditional model for third-party data exchange.

quadrantChart
    title Forces disrupting third-party data exchange
    x-axis Low complexity --> High complexity
    y-axis Low urgency --> High urgency
    quadrant-1 Critical
    quadrant-2 Monitor
    quadrant-3 Emerging
    quadrant-4 Accelerating
    Hyperconnected ecosystems: [0.75, 0.80]
    Growing regulatory pressure: [0.65, 0.90]
    Supply chain risk: [0.85, 0.85]
    Quantum computing horizon: [0.70, 0.60]

Hyperconnected ecosystems. A bank issues cards through several networks and embossing providers, outsources collections and customer service, reports to regulators and integrates embedded fintechs. A hospital shares clinical records with laboratories, insurers and research partners. Each relationship means protected information is processed outside the owner's domain.

Growing regulatory pressure. DORA, PCI DSS 4.0, GDPR, SOX, data-residency laws and banking supervisors in many jurisdictions all assign ultimate responsibility to the data owner. Outsourcing a process does not outsource the liability, and regulators increasingly expect evidence of how third parties are controlled, not only a contract.

Supply-chain risk. The costliest breaches of recent years did not occur at the organizations whose data was exposed, but at their third parties. An organization's attack surface is now the union of the attack surfaces of everyone who holds its data or its keys.

Quantum computing on the horizon. Migrating to post-quantum cryptography is not optional. An organization that has distributed keys and cleartext to many third parties cannot migrate on its own timeline: every algorithm change must be coordinated bilaterally with every counterparty.

The structural problem: control ends at the moment of sharing

The traditional model has two variants, and both end the same way whatever the channel (files over SFTP or managed file transfer, payloads over APIs, events over messaging platforms, transactions across integrations):

• The owner shares the key. The third party can decrypt, sign or verify at will, for as long as the key is valid, over any data protected with it.
• The owner relies on the channel alone. The information is decrypted before it leaves, or protected only by the transport, and arrives in cleartext at the third party's application.

flowchart LR
    A["🏢 Your organization<br/>(data owner)"] -->|"key delivery /<br/>cleartext data"| B["🤝 Third party<br/>(full control over your data)"]

    B --> C["❌ No visibility into when<br/>or how data is used"]
    B --> D["❌ Cannot revoke access<br/>in real time"]
    B --> E["❌ No auditable evidence<br/>of usage"]
    B --> F["❌ Key or cleartext lives<br/>outside your domain"]

    style A fill:#d6eaf8,stroke:#1a5276,stroke-width:2px
    style B fill:#fadbd8,stroke:#c0392b,stroke-width:2px
    style C fill:#fef9e7,stroke:#c0392b
    style D fill:#fef9e7,stroke:#c0392b
    style E fill:#fef9e7,stroke:#c0392b
    style F fill:#fef9e7,stroke:#c0392b

Neither traditional strategy is wrong; each solves the problem it was designed for. Transport protection gets information to the third party safely, and encryption keeps it unreadable in transit and at rest. Neither decides when, under which conditions and how often the third party may open it.

In the traditional strategies the third party decides when it decrypts; in sovereign exchange, the owner's policy decides.

The accumulation effect of recurring exchange

Most exchanges are recurring. Consider an organization that sends protected data to a provider twice a month under a key shared on day zero. After one year the provider holds 24 deliveries, and the key it holds opens every one of them, at any time, as many times as it wants, together with anything else ever encrypted under that key. A compromise of the provider in month twelve exposes a year of deliveries, and revoking the key requires generating, distributing and activating a new one on both sides while the deliveries already received stay readable with the old one. The longer the relationship, the larger the blast radius of a single compromise.

Consequences of losing cryptographic sovereignty

The risks span operational, regulatory, and strategic dimensions.

mindmap
  root((Loss of<br/>cryptographic<br/>sovereignty))
    Operational risk
      Third-party breach = your breach
      Irreversible sensitive data leakage
      Inability to cut access immediately
      Uncontrolled key duplication
    Regulatory risk
      SOX and PCI audit findings
      DORA non-compliance penalties
      Shared GDPR controller liability
      Exposure to civil litigation
    Strategic risk
      Operational dependency on the third party
      High cost of provider switching
      Barrier to new integrations
      Loss of market trust

The accountability problem. Regulatory frameworks make the data owner accountable for what third parties do with its data. The legal responsibility cannot be delegated, yet the traditional model places control with the third party. Each of these risks follows from one architectural fact: the cryptographic authority over the data was transferred along with the data. Restoring control therefore requires not better contracts or more monitoring, but a different model of how cryptographic authority is exercised across organizational boundaries.

The paradigm shift: from sharing keys to sharing capabilities

The traditional model and the sovereign model differ in a single decision: what is shared.

flowchart TB
    subgraph TRADITIONAL["❌ Traditional model — sharing a key"]
        direction LR
        T1["Data owner"] -->|"delivers key"| T2["Third party"]
        T2 --> T3["Possesses cryptographic material"]
        T2 --> T4["Uses it whenever and<br/>however they want"]
        T2 --> T5["Revocation requires<br/>bilateral coordination"]
        T2 --> T6["Audit depends on<br/>what the third party reports"]
    end

    subgraph ANKASECURE["✅ Sovereign model — sharing a capability"]
        direction LR
        A1["Data owner"] -->|"grants capability"| A2["Control Plane"]
        A2 -->|"mediated invocation"| A3["Third party"]
        A3 --> A4["Only what was authorized,<br/>when it was authorized"]
        A2 --> A5["Unilateral revocation<br/>without depending on the third party"]
        A2 --> A6["Every execution logged<br/>in owner's domain"]
    end

    TRADITIONAL -.->|"paradigm shift"| ANKASECURE

    style TRADITIONAL fill:#fadbd8,stroke:#c0392b,stroke-width:2px
    style ANKASECURE fill:#d5f5e3,stroke:#1e8449,stroke-width:2px

This is an architectural change, not a procedural one. Stricter contracts and tighter rotation schedules operate on a key that has already left the owner's domain. The sovereign model prevents the transfer, and that requires a component between the third party and the owner's material that understands the exchange relationship, evaluates each request against policy, executes the operation in the owner's domain and records the result: a Cryptographic Control Plane.

Because the third party invokes a capability rather than holding a key, the owner can rotate keys and change algorithms behind that capability as often as its policy requires, even one key per delivery, without the third party or the owner's applications changing any code.

Two planes: transport and cryptographic control

Third-party exchange involves two distinct jobs. The transport plane moves information: managed file transfer, SFTP, APIs, messaging platforms and application integrations. The cryptographic control plane decides who may open what travels, under which conditions and with which evidence. Sovereign exchange changes only the second.

sequenceDiagram
    participant OA as Owner's application
    participant CCP as ANKASecure©<br/>Control Plane
    participant CH as Existing channel<br/>(MFT, SFTP, API, messaging)
    participant TP as Third party's application

    OA->>CCP: 1. Protect the information
    CCP-->>OA: Protected payload
    OA->>CH: 2. Send, as today
    CH->>TP: 3. Deliver, as today
    TP->>CCP: 4. Invoke decrypt under the owner's policy
    CCP-->>TP: Result, if authorized (recorded either way)

Steps 2 and 3 are the exchange as it works today; steps 1 and 4 are the only new element, and neither call travels through the channel. The control plane does not route, transform, schedule or deliver information, and it does not sit in the middle of the exchange. Keep the exchange you already have: what changes is who holds the cryptographic authority to open what travels through it.

The same model applies to files and batches, individual records, API payloads in JSON or XML, messages and events, and transactions between applications, provided the integration invokes the capabilities and the formats are supported. The third party adapts its integration once; after that, key rotation and algorithm changes need no further change on either side.

Why existing components are not enough

HSMs and KMS platforms are foundational, and nothing in this model replaces them or moves custody away from them. Each existing component provides part of sovereign exchange; none provides the whole.

HPKE (RFC 9180) encrypts data to the holder of a private key; in a third-party exchange that holder is the third party, which can then decrypt every delivery outside the owner's view. Encryption libraries define how data is protected. A control plane governs who may use that protection, for what, and for how long.

An HSM stores. A proxy transports. A control plane governs.

The solution: ANKASecure© as a Cryptographic Control Plane

ANKASecure© is the control plane that governs how cryptography is used across systems and organizations, without ever handing over the keys that underpin it.

flowchart TB
    subgraph OWNER["Owner's control domain"]
        HSM["🔑 HSM / Cloud KMS<br/>Root of Trust:<br/>the key-encryption key"]
        POL["📋 Policies"]
        AUD["📊 Audit + Revocation"]
    end

    subgraph CCP["ANKASecure© — Cryptographic Control Plane"]
        AUTH["Authentication"]
        AUTHZ["Authorization"]
        REST["Restrictions"]
        MED["Mediation"]
        EV["Evidence"]
    end

    OWNER <--> CCP

    CCP -->|"invokes capability"| P1["🏦 Provider A<br/>e.g. card network"]
    CCP -->|"invokes capability"| P2["💳 Provider B<br/>e.g. card network"]
    CCP -->|"invokes capability"| P3["🏭 BPO / Vendor<br/>e.g. embossing"]

    style OWNER fill:#d6eaf8,stroke:#1a5276,stroke-width:2px
    style CCP fill:#85c1e9,stroke:#1a5276,stroke-width:3px
    style P1 fill:#fdebd0,stroke:#d68910
    style P2 fill:#fdebd0,stroke:#d68910
    style P3 fill:#fdebd0,stroke:#d68910

Four foundational capabilities

For the broader architectural treatment of the control plane, see The Cryptographic Control Plane.

Execution and Roots of Trust

ANKASecure© is not a proxy that forwards every operation to an HSM. Keys are generated in the platform and operations run in its cryptographic engines. Each key's material is stored wrapped under a key-encryption key held in the key-protection backend configured for the deployment or the tenant (an HSM through PKCS#11, AWS KMS, Google Cloud KMS or Azure Key Vault), so the protection of every key stays anchored to that backend. Centralized governance of third-party access therefore does not make the control plane the ultimate Root of Trust: the owner retains the Root of Trust, the control plane performs governed operations on its behalf, and the third party never holds either.

The sovereignty invariant for Bring-Your-Own-Key (BYOK)

Sovereign custody extends to the key-protection backend itself. A tenant that brings its own HSM or Cloud KMS backend has its key material wrapped under its own key-encryption key, in its own account, and the platform reaches that backend with the tenant's own credential, never the platform operator's identity. If that credential is absent or unusable, the operation fails closed rather than falling back to the operator's identity. On a public-SaaS deployment, a regulated tenant therefore keeps its keys under a key-encryption key the platform operator cannot exercise. The credential itself is sealed under the tenant's own custody key and never leaves the owner's domain in the clear.

A tenant's own backend outranks the ANKA-managed backend a tenant's Edition assigns, which in turn outranks the deployment's own backend, so a tenant that has declared its own is never served by either of the two below it, and the platform refuses any change that would move already-wrapped material between them.

How it works

The key never moves to the third party. The capability does: governed, restricted and audited.

sequenceDiagram
    participant TP as Third party / System
    participant CCP as ANKASecure©<br/>Control Plane
    participant POL as Policy engine
    participant KP as Key-protection backend<br/>(Owner's Root of Trust)
    participant AUD as Audit log

    TP->>CCP: Invocation request (capability, key, actor)
    CCP->>POL: Evaluate grant, context and constraints
    POL-->>CCP: Decision: Permit / Deny

    alt Permitted
        CCP->>KP: Unwrap the key's protection under the owner's KEK
        CCP->>CCP: Execute the operation in the platform's engine
        CCP->>AUD: Record: actor, context, grant, constraints, outcome
        CCP-->>TP: Result only (never key material)
    else Denied
        CCP->>AUD: Record the refused invocation and its reason
        CCP-->>TP: Rejection
    end

Every invocation passes through five stages in the owner's domain: authentication of the actor, authorization against a valid grant for that capability, key and exchange context, restrictions from the grant's constraints, mediation (execution with material that never reaches the third party), and evidence in the owner's audit trail.

Critical invariant: key material is never delivered to the third party or to any external system. What crosses the organizational boundary is a request and a result, never the material that connects them. Revocation follows the same path: withdrawing a grant, revoking or suspending an actor, or suspending an exchange context takes effect on the next invocation the platform evaluates, without any action by the third party and without re-encrypting data.

The conceptual model behind sovereign exchange

ANKASecure© materializes sovereign control through five conceptual blocks. These map directly to entities in the deployment organization model.

flowchart LR
    EC["1️⃣ Exchange Context<br/>The exchange relationship<br/><br/>Models the third-party exchange:<br/>for what purpose, with what sensitivity;<br/>its Exchanges say with whom<br/>and in which direction"]
    CA["2️⃣ Cryptographic Actor<br/>Who executes<br/><br/>The operational identity of the<br/>third party or system that actually<br/>invokes cryptographic operations"]
    CAP["3️⃣ Capability<br/>What they can do<br/><br/>The abstract cryptographic function<br/>— encrypt, decrypt, sign, verify —<br/>decoupled from the material behind it"]
    CAS["4️⃣ Cryptographic Asset<br/>With which material<br/><br/>The key, named by its identifier.<br/>Protected under the owner's Root of Trust.<br/>Never delivered — only its use is mediated"]
    CP["5️⃣ Constraint Policy<br/>Under which restrictions<br/><br/>Usage rules: time window, weekly<br/>schedule, max invocations,<br/>rate limit, single use"]

    EC --> CA --> CAP --> CAS --> CP

    style EC fill:#d6eaf8,stroke:#1a5276,stroke-width:2px
    style CA fill:#d5f5e3,stroke:#1e8449,stroke-width:2px
    style CAP fill:#fdebd0,stroke:#d68910,stroke-width:2px
    style CAS fill:#e8daef,stroke:#7d3c98,stroke-width:2px
    style CP fill:#fadbd8,stroke:#c0392b,stroke-width:2px

Together, these five blocks answer a single compound question:

Who can do what, on which material, in which context, under which conditions — with complete evidence.

A Capability Grant binds the five together, and four properties make the answer unambiguous:

• Every grant belongs to exactly one Exchange Context. There is no grant that authorizes outside a context.
• An actor's grants never overlap. Two live grants of one actor cannot cover the same capability on the same material, so every request is authorized by at most one grant, in that grant's context.
• Direction is enforced. A relationship has an origin and a destination, and a re-encryption grant from one key to another authorizes that direction only.
• One budget per grant. A usage limit counts every operation the grant authorizes, whatever its capability; a schedule such as "weekdays, business hours only" is evaluated in the platform's time zone on every request.

Because the capability is decoupled from the key behind it, the owner can rotate the key, or change its algorithm, as often as policy requires. The third party keeps invoking the same capability and cannot know which key version or algorithm fulfills each invocation. Combined with single-use grants, this bounds the impact of a compromise to the delivery that was authorized rather than to the history of the relationship.

The composition

erDiagram
    EXCHANGE_CONTEXT ||--o{ CRYPTOGRAPHIC_ACTOR : "authorizes"
    EXCHANGE_CONTEXT ||--o{ CAPABILITY : "permits"
    CAPABILITY ||--|| CRYPTOGRAPHIC_ASSET : "operates on"
    EXCHANGE_CONTEXT ||--o{ CONSTRAINT_POLICY : "governed by"
    CRYPTOGRAPHIC_ACTOR ||--o{ CONSTRAINT_POLICY : "subject to"

    EXCHANGE_CONTEXT {
        string id
        string name
        string purpose
        string sensitivity_level
        string regulatory_regime
    }
    CRYPTOGRAPHIC_ACTOR {
        string id
        string identity
        string actor_type
        string authentication_method
    }
    CAPABILITY {
        string id
        string function_type
        string operation
    }
    CRYPTOGRAPHIC_ASSET {
        string id
        string key_identifier
        string key_family
    }
    CONSTRAINT_POLICY {
        string id
        datetime valid_from
        datetime valid_until
        string schedule_weekdays_and_hours
        int max_invocations
        int rate_limit_per_minute
        bool single_use
    }

The full treatment, including the additional entities (Deployment, Tenant, Application, Credential, Capability Grant, Policy, Audit Event) that round out the twelve-entity model, is in the deployment organization model.

Banking scenario: card issuance with multiple embossing providers

A bank issues cards through two card networks and a local provider. Each must decrypt sensitive cardholder data to produce the physical card. Sharing keys multiplies risk: every provider becomes a holder of the bank's cryptographic authority.

flowchart TB
    BANK["🏦 Bank<br/>Card Issuance Application<br/><br/>🔑 All keys under the bank's control"]

    BANK --> CCP

    subgraph CCP["ANKASecure© Control Plane"]
        EC1["Exchange Context: Embossing-Network-A<br/>decrypt · max 2,847 uses · 2h window"]
        EC2["Exchange Context: Embossing-Network-B<br/>decrypt · max 9,012 uses · 4h window"]
        EC3["Exchange Context: Embossing-Local<br/>decrypt · rate-limit 10/min · 30-day window"]
    end

    EC1 --> NA["💳 Network A<br/>network-a-embossing-actor"]
    EC2 --> NB["💳 Network B<br/>network-b-embossing-actor"]
    EC3 --> LOCAL["🏷️ Local issuer<br/>local-issuer-actor"]

    style BANK fill:#d6eaf8,stroke:#1a5276,stroke-width:2px
    style CCP fill:#85c1e9,stroke:#1a5276,stroke-width:3px
    style NA fill:#fdebd0,stroke:#d68910
    style NB fill:#fdebd0,stroke:#d68910
    style LOCAL fill:#fdebd0,stroke:#d68910

Outcomes for the bank

The fully modeled scenario (entities, attributes, capability grants, constraints) is in Reference scenarios.

Banking scenario: BPO collections and outsourced processing

A BPO operates on behalf of the bank over delinquent customer data. Today it receives decrypted CSV files. With ANKASecure© it opens one record at a time through governed capabilities, and the SFTP channel can stay in place: what travels through it is protected information instead of cleartext.

flowchart LR
    subgraph TODAY["❌ Today — without sovereign control"]
        direction TB
        S1["Bank decrypts the portfolio"]
        S2["Sends CSV files to BPO via SFTP"]
        S3["BPO operates on cleartext data"]
        S4["Bank has no visibility into BPO's data use"]
        S5["Files remain on BPO servers"]
        S6["Revoke = rewrite entire ETL process"]
        S1 --> S2 --> S3 --> S4 --> S5 --> S6
    end

    subgraph ANKA["✅ With ANKASecure©"]
        direction TB
        A1["Bank defines Exchange Context: BPO-Collections"]
        A2["BPO is a controlled Cryptographic Actor"]
        A3["Each individual decryption is an invocation"]
        A4["Restrictions: record-by-record, business hours only"]
        A5["Every operation logged in bank's audit domain"]
        A6["Revocation: immediate from the console"]
        A1 --> A2 --> A3 --> A4 --> A5 --> A6
    end

    style TODAY fill:#fadbd8,stroke:#c0392b,stroke-width:2px
    style ANKA fill:#d5f5e3,stroke:#1e8449,stroke-width:2px

The full modeling (actors, contexts, grants, constraints) is in Reference scenarios.

Banking scenario: credit origination with a fintech over an existing API

A bank sends customer data to a partner fintech through a REST API for credit scoring. Today the sensitive fields (identification, income, account) are protected only by TLS and arrive in cleartext at the fintech. In the sovereign model the API, its contracts and its infrastructure do not change: the bank's application encrypts the sensitive fields inside the JSON payload, and the fintech's scoring service, authenticated with its own workload identity (OIDC), invokes the decrypt capability only when it needs a field. The grant's validity window equals the term of the alliance, with a per-minute rate limit and a usage cap. When the alliance ends, or on an incident, the bank closes the exchange context and the fintech loses cryptographic access, without any coordination.

Banking scenario: recurring deliveries over managed file transfer

A bank sends protected data to a provider twice a month over its existing managed file transfer platform. The platform keeps ensuring each delivery arrives; the control plane decides when, under which conditions and how often it can be opened.

Over one year that policy produces twelve keys and four algorithms, and the provider makes the same "decrypt" call all year. The accumulation effect is inverted: exposure is bounded, at any moment, to the delivery currently authorized.

Beyond banking: cross-industry applicability

The same conceptual model solves sovereign control scenarios across multiple industries.

mindmap
  root((ANKASecure©<br/>Cryptographic<br/>Control Plane))
    Financial services
      Card issuance
      BPO collections
      Recurring outsourced processing
      Regulatory reporting
      Embedded fintechs
      Open banking
    Government & defense
      Inter-agency exchange
      Contractors
      Binational interoperability
      Sovereign signing
    Healthcare
      Shared clinical records
      External laboratories
      Insurers
      Clinical research
    Telecommunications
      Partner data sharing
      Roaming
      MVNOs
      CDR exchange
      IPX interconnection
    Retail & value chains
      EDI with suppliers
      Federated loyalty
      Outsourced logistics
      Marketplaces
    Software & SaaS
      Multi-tenancy
      B2B integrations
      Data processors
      Enterprise BYOK

One conceptual model. One product. Dozens of regulated scenarios where the data owner must retain control.

Business benefits by stakeholder

flowchart TB
    subgraph CEO["👔 For the CEO / Board"]
        C1["Structural reduction of third-party risk"]
        C2["Defensive posture against litigation and penalties"]
        C3["Enabler for new commercial integrations"]
        C4["Competitive differentiator with regulated clients"]
    end

    subgraph CISO["🛡️ For the CISO"]
        CI1["Real cryptographic sovereignty — not declarative"]
        CI2["Reduced attack surface from third parties"]
        CI3["Complete evidence for audits and forensics"]
        CI4["Instant revocation without external coordination"]
    end

    subgraph CTO["⚙️ For the CIO / CTO"]
        CT1["Single control plane for all third parties"]
        CT2["Crypto-agility: migrate algorithms without touching apps or counterparties"]
        CT3["Native post-quantum readiness"]
        CT4["Standard integration with HSMs and existing ecosystem"]
    end

Target values

These are design objectives of the model, not measured results.

Post-quantum readiness is a consequence, not a prerequisite: because third parties invoke capabilities rather than hold keys, a post-quantum migration across external relationships becomes a policy change in the owner's domain instead of a bilateral project with every counterparty.

Regulatory compliance alignment

Sovereign exchange is not designed around any single regulation. It is designed around the principle those regulations share: the data owner is responsible for how third parties use its data and must be able to demonstrate control.

Three properties carry the alignment: evidence generated by the owner's infrastructure rather than attested by the third party, revocability that does not depend on the counterparty's cooperation, and reduced dependency, because counterparties never hold keys.

For the regulatory dimension as a CAPA pillar, see Pillar 4 — Cryptographic Governance & Compliance.

Adoption path

Sovereign exchange starts from a list every organization already has: its third parties. It is adopted one exchange context at a time, starting where the risk or regulatory urgency is highest, with the algorithms and key infrastructure already in place, and without replacing any exchange channel.

Where to read next

Summary

Cryptographic sovereignty means the data owner keeps the authority over its cryptography wherever its data goes. Third parties never receive keys — they receive the right to invoke capabilities, mediated and audited.

This principle inverts the traditional model of third-party data exchange. Control no longer ends at the moment of sharing; it is exercised at every decryption. The channels stay the same, and the shift from sharing keys to sharing capabilities is what makes governed cross-organization cryptography possible.

Share the information. Keep the authority.