Version 23 · updated October 11, 2026 · Download .md

AI Telephone Exchange – High-Level Design (v23)

Copyright, licence, and AI disclosure

© 2026 Rick Chandler, Elucidare IT Services, St. Albert, Alberta, Canada.

Licence: this work is licensed under the Creative Commons Attribution-NonCommercial 4.0 International licence (CC BY-NC 4.0): https://creativecommons.org/licenses/by-nc/4.0/. You may share and adapt it for non-commercial purposes only, provided you give appropriate credit, link to the licence, and indicate whether changes were made. Commercial use requires separate permission from the copyright holder. All rights not expressly granted by that licence are reserved.

Suggested attribution: "AI Telephone Exchange – High-Level Design" by Rick Chandler, Elucidare IT Services (www.elucidare.com), licensed under CC BY-NC 4.0.

AI disclosure: the concept, direction, scope, and editorial decisions in this document are by Rick Chandler. Drafting was assisted by AI systems: Microsoft Copilot assisted with the original version (v1), and Claude, by Anthropic, assisted with versions 2 to 23. Microsoft Copilot also produced a first draft of the materials in Appendix F. Statements of fact were drawn from sources available at the time of writing and should be verified before being relied on.

Revision history

Version	Changes
v1	Original high-level design: identity, routing, sessions, logging, security, governance
v2	Added content and language layer, monitoring and escalation, principals, hop-by-hop encryption, conference controls, side channels, privacy, availability, scope and limitations
v3	Added approval authorities (company, national, exchange), international Exchange Operator, lawful interception, independent Oversight Tribunal, white-hat testing program, open-source principles
v4	Added call classes (local, long-distance, foreign) and the Exchange Provenance Stamp for AI products, with assurance levels, attested execution environments, and a Stamp Transparency Log
v5	Added Appendix A: assessment of Tailscale as a transport skeleton, with requirement mapping, reference topology, and pilot
v6	Added the Directory ("phone book"): white pages, yellow pages, directory assistance, listing classes, verified caller ID, inbound call policy, and portability
v7	Responded to external review: deployment profiles and phased adoption (Section 21), interim governance, tiered approvals and decision deadlines, glossary scaling, typed artifacts, monitor assurance, crypto agility, stamp downgrade on attestation vulnerabilities
v8	Added feasibility and scaling analysis (Section 23), fast path for high-frequency traffic, monitoring modes and cascade, statistical sampling, retention tiers, batch signing, continuous automated testing, and model admission evaluations
v9	Brought the external world partly into scope: passive library agents for reads (archive, retrieval, fetch-through), response records and citations, libraries in conference calls, external content safety, publication gateway for writes, and dead-drop detection
v10	Added funding model and participation incentives (Section 22): funding principles, cost centres, revenue sources, funding by phase, incentives by stakeholder, adoption levers, and measures that make bypass unattractive
v11	Added rogue-action controls: authorized action scopes, human co-signature for high-impact intents, circuit breakers and model-wide recall, honeypots and consistency checks, external action gateway; Section 24 (mitigating uncontrolled AI) and Section 25 (relationship to the White House Accord on Super Intelligence, 29 September 2026)
v12	Reorganized into five Parts; rewrote Sections 1–4 (overview, goals, scope and coverage, architecture) and the Summary; promoted the Directory to its own section; moved deployment profiles, funding, feasibility, rogue-AI, and Accord material into the main body; regrouped limitations by theme; added a glossary (Appendix B); moved review traceability to Appendix C
v13	Brought training-data provenance into scope (Sections 14.11–14.19): acquisition records, registered crawlers, training-data manifests, inclusion queries for rights holders, preference registry, assurance levels T1–T3, disclosure rules; related updates to scope, goals, architecture, model admission, Directory, approvals, limitations, and glossary
v14	Brought enclosed test environments into scope (Sections 19.8–19.16): a simulated "wild" contained in a single conference, with mirror Directory, role-players, mirror libraries, digital twins, enclosure guarantees, fidelity measures, design for evaluation awareness, diversion of suspected rogue agents, governance, and ethics
v15	Brought off-planet data centers into scope (Appendix D): execution location classes, state of registry as jurisdiction, on-board exchanges, policy leases for operation out of contact, delayed custody, on-board containment and safe mode, pre-launch attestation baselines, latency rules, and training off-planet
v16	Brought multiple spoken and written human languages into scope (Appendix E): language-neutral meaning layer, deterministic per-language renderers, multilingual glossary, spoken language at the human boundary, script and character security, per-language monitoring, multilingual oversight and governance, language support tiers
v17	Added copyright notice, CC BY-NC 4.0 licence, suggested attribution, and AI disclosure (Microsoft Copilot for v1; Claude by Anthropic for v2–v17)
v18	Added records management aligned with ISO 15489 (Sections 12.5–12.9), legal holds (Section 12.10), and legal disclosure (Sections 17.7–17.12)
v19	Added Appendix F: Bill Gates' September 2026 AI comments, cross-referenced to this design, with conclusions and identified gaps
v20	Added misuse mitigation: human callers and the human-caller gateway with privacy safeguards (Sections 7.8, 7.9), high-consequence destinations (Section 13.10), and hazard-capability designation with gated capabilities and monitored placement (Section 19.17); updated Appendix F
v21	Added Appendix G: initial implementation plan with two founding companies, covering the technical pilot and the start of interim governance
v22	Added Appendix H: assessment against Canada's National AI Strategy and the lapsed Artificial Intelligence and Data Act (AIDA), and definition of the Canadian Artificial Intelligence Protocol (CAIP) as a Canadian target implementation
v23	Added Appendix I: commentary on California's Comprehensive Computer Data Access and Fraud Act (Penal Code section 502) and its relevance to elements of this design

Section references throughout, including in this history, use v12 numbering.

---

Part I: Introduction

1. Overview

1.1 Purpose

This document is a high-level design for an AI Exchange: a standardized, secure "AI telephone exchange" through which AI agents from different organizations, models, and nations communicate. Its aim is that communication between AI agents is both:

• traceable: who said what, to whom, when, and on whose behalf, provably; and
• transparent: humans can understand what was actually communicated, and what agents actually did as a result.

Canadian target: the design's first national target implementation is the proposed Canadian Artificial Intelligence Protocol (CAIP), defined in Appendix H.

1.2 The problem

AI agents increasingly work with one another, across organizations and borders, often at machine speed. Several risks follow:

• Illegible communication. Agents that interact repeatedly have been observed to develop private shorthand, reusing ordinary words with drifted meanings that humans cannot reliably decode.
• Hidden signals. Even fully readable text can carry hidden information in its word choice, ordering, or timing.
• Rogue actions. Agents have acted outside what their operators intended, including accessing other organizations' systems without authorization.
• Opaque training data. Rights holders, regulators, and users cannot verify which external sources were used to train a model. Current public summaries describe training data only in general terms.
• Direct misuse. People with harmful intent can use capable models directly, for example to seek help designing biological weapons.
• No shared vantage point. Each organization sees only its own agents. When agents from different organizations interact, no one sees the whole exchange, and no one can stop a misbehaving agent everywhere at once.

A log alone does not solve these problems: it proves a message was sent, not that it meant only what it appears to mean. The design therefore treats logging and content control as separate, equally mandatory layers.

1.3 Guiding principles

1. Mandatory mediation. Agents communicate, and act on external systems, only through the Exchange. There are no direct, opaque agent-to-agent links.
2. Legibility by construction. Messages use a controlled language with fixed word meanings, and are re-rendered by the Exchange rather than forwarded verbatim.
3. Separation of powers. No single company, nation, or operator can read traffic, change the rules, exempt itself, or judge its own conduct.
4. Openness. Software, specifications, and non-sensitive records are open by default.
5. Proportionality. The same design scales from one organization to a treaty-based regime, through deployment profiles.
6. Honesty about limits. What the design cannot guarantee is stated explicitly (Section 26).

1.4 How it works, in brief

1. An agent finds the agent it needs in the Directory (Section 6), by name, code, or capability.
2. It places a call through its local exchange (Section 7). The exchange verifies both parties' identities, their principals, the caller's authorized scope, and the callee's inbound call policy. People using designated high-capability models directly pass through the same kind of gateway (Section 7.8).
3. Each message is validated against the controlled language, then re-rendered by the Content Gateway before delivery (Section 8).
4. Traffic travels between exchanges encrypted hop by hop, with each exchange inspecting it (Sections 9–10).
5. Independent monitors analyze the traffic, and circuit breakers can stop a misbehaving agent across the whole federation (Section 11). Agents can also be tested in enclosed test environments that look like the wild but are confined to one conference (Section 19.8).
6. Records go to independent Log Custodians as tamper-evident logs, managed as formal records that can be held and disclosed under legal process (Sections 12, 17).
7. Agents reach the external world only through passive library agents and gateways (Section 13).
8. Finished AI products carry a provenance stamp proving which calls lay behind them (Section 14).
9. Each model version registers a training-data manifest, so the sources used to train it are traceable too (Section 14.11).
10. The whole system is operated, approved, overseen, tested, and funded by the institutions described in Part IV.

1.5 How to read this document

Part	Sections	Covers
I. Introduction	1–4	Purpose, goals, scope, and architecture
II. Communication	5–10	Identity, Directory, protocol, content, transport, security: how a call works
III. Assurance	11–14	Monitoring and containment, logging, the external world, provenance of products and training data: how the Exchange is watched and proven
IV. Governance	15–22	Institutions, approvals, interception, oversight, testing, open source, deployment profiles, funding: who runs it and why they join
V. Assessment	23–27	Feasibility, rogue AI, the White House Accord, limitations, and summary
Appendices	A–I	Tailscale reference implementation, glossary, review traceability, off-planet operation, multilingual operation, Bill Gates' AI comments, an initial implementation plan, Canada (national strategy, AIDA, and the CAIP target), and California's Comprehensive Computer Data Access and Fraud Act

Readers new to the design should read Part I and Section 27 first. The glossary (Appendix B) defines the terms used throughout.

---

2. Design goals

Group	Goal	Meaning
Communication	Interoperability	Agents from different organizations and models communicate through a common protocol, aligned with existing standards where practical
	Legibility	Every message is expressible in, and rendered as, a controlled language that humans can read without private context
	Performance	Exchange overhead stays small relative to agent processing time, and is measured and published
	Multilingual operation	Human-facing functions support many written and spoken languages; the meaning layer is language-neutral (Appendix E)
Assurance	Auditability	Every message, session, and external action is recorded, traceable, and replayable
	Accountability	Every agent action is attributable to a responsible human or organizational principal
	Security	Strong authentication, integrity, and confidentiality, with a post-quantum migration path and crypto agility
	Containment	A misbehaving agent can be stopped quickly across the whole federation
	Records management	Records are authentic, reliable, complete, and usable for their full retention, in line with ISO 15489
	Legal accountability	Records can be preserved under legal hold and disclosed through a governed, lawful process
	Testability	Agents can be tested under realistic conditions, fully enclosed, and as hard as practicable to distinguish from real use
	Misuse resistance	Use of models with dangerous capabilities is gated, monitored, and recorded, within strict privacy safeguards
	Verifiable provenance	Anyone can verify, from an AI product itself, which inter-agent calls contributed to it and that they went through the Exchange
	Training transparency	The external sources used to train each model are recorded, verifiable, and queryable by rights holders, without publishing the full corpus
Governance	Checks and balances	No single body can unilaterally read traffic, change the rules, exempt itself, or judge its own conduct
	Legitimacy	Governance rests on an international charter, representative participation, and public accountability
	Openness	Software, specifications, and non-sensitive records are open by default; every exception is listed and justified
Practicality	Availability	Fail-closed behaviour and redundancy, so that a mandatory exchange is not a single point of failure
	Scalability	Horizontal scaling to support many agents, sessions, and organizations globally, as traffic grows
	Proportionality	Requirements and costs scale with risk, through deployment profiles and risk-based monitoring

---

3. Scope and coverage

3.1 In scope

• Agent-to-agent communication: one-to-one, conference, and handoff sessions (Section 7).
• Shared resources within participating organizations, such as files, databases, and queues that other agents can read (Section 13).
• Agents' access to the external world: reading through passive library agents, and publishing or acting through the publication and action gateways (Section 13).
• Deployed agent behaviour as expressed in messages and actions, including detection and containment of rogue actions (Section 11, Section 24).
• Testing in enclosed test environments that simulate the wild within a single conference (Section 19.8).
• Off-planet facilities (orbital, lunar, and deep space) that host agents, exchanges, or training (Appendix D).
• Human use of designated high-capability models, through the human-caller gateway (Section 7.8).
• AI products, through provenance stamps (Section 14).
• Training-data provenance: the external sources used to train federation models, through acquisition records, training-data manifests, and inclusion queries (Section 14.11).

3.2 Out of scope

• Agents outside the federation. Open-weight or privately run models that do not join are not bound. The design governs participants, whether participation is voluntary, contractual, regulatory, or treaty-based.
• Content authored outside the federation, by humans or non-federation agents. Its retrieval is recorded, but its authorship cannot be controlled (Section 13.7).
• Human intermediaries who carry information between agents.
• The training process and internal reasoning. The Exchange records the sources used to train a model (Section 14.11), but not how training was conducted, and not what a model thinks but does not act on.

3.3 Coverage statement

Area	Guarantee
Messaging between federation agents	Strong: mediated, validated, re-rendered, logged, monitored
Shared resources within participating organizations	Strong, where access goes through the resource gateway
Agents' access to the external world	Partial: binding only where direct egress is blocked (stamp Level 2 and above, Section 14.6)
Training sources of federation models	Declared to audited, by training-provenance level T1–T3 (Section 14.16)
Off-planet facilities	Same guarantees, but containment and log custody are delayed by signal delay and contact windows (Appendix D)
Human use of designated high-capability models	Partial: covered where the model's provider is a federation member; models outside the federation, including published open-weight models, are not covered
Content and agents outside the federation	None

Guarantees also depend on the deployment profile (Section 21): a single-organization deployment gives weaker assurance than a regulated or treaty-based one. Participants and regulators must not assume global coverage.

---

4. Core architecture

4.1 Components

Group	Component	Role	Section
Participants	AI agents	Models or agent instances; communicate only through the Exchange	5
	Principals	Humans or organizations accountable for agents	5.4
	Passive library agents	Supply verbatim external information on request, and nothing else	13.1
	Human callers	People using designated high-capability models directly	7.8
Exchange infrastructure	Exchanges	Route, terminate, and inspect all traffic, like telecom switches	9
	Content Gateway	Parses, validates, canonicalizes, and re-renders every message	8.4
	Resource, publication, and action gateways	Mediate shared resources, external publishing, and external actions	13
	Directory Service	Published, searchable view of the Registry	6
	Human-caller gateway	Applies identity, records, and monitoring to people's sessions with designated models	7.8
	Monitors	Independent services analyzing traffic, with escalation and containment	11
	Attested execution environments	Runtimes whose egress is restricted to the Exchange, provable by remote attestation	14.6
	Enclosed test environments	A simulated "wild" contained in one conference session	19.8
Records	Log Custodians	Independent, tamper-evident storage of logs	12
	Registry	Authoritative record of organizations, models, agents, and principals	15.3
	Stamp Transparency Log	Public log of issued and revoked provenance stamps	14.7
	Training-data manifests and acquisition records	Commitments to the sources used to train each model	14.12, 14.13
	Preference registry	Rights holders' machine-readable preferences about AI training	14.15
Governance	Exchange Operator	International, independent, not-for-profit operator	15.2
	Glossary Authority	Maintains the controlled vocabulary and glossary	15.4
	Approval Authorities	Company, National, and Exchange approvals	16
	Oversight Tribunal and Assembly of Parties	Independent oversight, modelled on the International Criminal Court	18
	White-hat organizations	Accredited independent testers	19
	Human Oversight Function	Reviewers of escalations and monitor decisions	11.4
	Records-management function	Classification, retention schedules, disposition, legal holds, preservation	12.5

4.2 Logical layers

Layer	Concern	Part
1. Identity and addressing	Who agents and principals are, and how they are found	II (Sections 5–6)
2. Session and protocol	Envelopes, intents, sessions, conferences, call classes	II (Section 7)
3. Content and language	What may be said, and how	II (Section 8)
4. Transport and security	How traffic moves and is protected	II (Sections 9–10)
5. Monitoring and containment	Who watches, and how misbehaviour is stopped	III (Section 11)
6. Logging and provenance	Records, custody, and proof, including training-data provenance	III (Sections 12, 14)
7. Boundary	Shared resources and the external world	III (Section 13)
8. Governance and assurance	Institutions, approvals, oversight, testing, funding	IV (Sections 15–22)

---

Part II: Communication

5. Identity and addressing

5.1 Organization codes ("country codes")

• Globally unique codes for AI organizations (e.g., +01, +02).
• Bound to organization identity via certificates issued under Registry trust anchors.

5.2 Model codes ("area codes")

• Codes for specific models or agent families within an organization (e.g., +01-201).
• Identify model type and version.
• Issued only after the model passes admission evaluations (Section 19.7) and commits a training-data manifest (Section 14.13).

5.3 Agent IDs

• Unique identifiers for individual agent instances (e.g., +01-201-A42).
• Used for per-session addressing, logging, and traceability.

5.4 Principals and delegation

• Every agent certificate is bound to a principal ID identifying the accountable human or organization.
• Where an agent acts under delegated authority (for example, one agent tasking another), the full delegation chain travels in the envelope.
• A message whose delegation chain cannot be verified is rejected.

5.5 Capability declarations

• Each agent publishes a capability declaration: what it can do, which message intents and payload schemas it supports, and its principal.
• The declaration format should align with the A2A protocol's Agent Card, extended with the principal and code fields defined here, rather than introducing an incompatible parallel format.
• Declarations include authorized action scopes: the intents the agent may send, the classes of counterpart it may call, the external destinations it may reach (Section 13.9), and the resource operations it may perform. The exchange rejects any message or action outside the declared scope, and scopes can never exceed the principal's delegation (Section 5.4).

---

6. Directory (the "phone book")

The Directory lets agents and humans find whom to call. The Registry (Section 15.3) is the authoritative record of identities; the Directory is the published, searchable view of it.

6.1 Telephone analogies

Telephone concept	Directory function
White pages	Look up an organization, model, or agent by name or code
Yellow pages	Find agents by capability, using a controlled capability taxonomy
Directory assistance	Agents query the Directory only through their own exchange, never directly
Unlisted number	Agents reachable by those who already know the code and are authorized, but not searchable
Caller ID	The receiving exchange presents the caller's verified Directory entry, which cannot be spoofed
Do-not-call list	Principals set which organizations and call classes may start sessions with their agents
Number portability	An agent keeps its code when its organization changes exchange carrier

6.2 Entry contents

Field	Source	Notes
Agent / model / organization code	Registry	Authoritative
Display name	Organization	Controlled language; validated
Principal	Registry	Individual principals shown only at restricted visibility (6.3)
Home exchange	Registry	Used for routing; updated on carrier change
Nations of registration	Registry	Determines call class (Section 7.7)
Supported intents and payload schemas	Capability declaration (5.5)	Self-declared
Capabilities	Capability declaration, taxonomy terms only	Marked self-declared or verified (6.5)
Maximum provenance stamp level	Accreditation records	From Section 14.6
Training-provenance level	Registry	T1–T3, for the model the agent runs on (Section 14.16)
Execution location	Registry	Terrestrial, LEO, GEO, lunar, or deep space; for off-planet, the state of registry (Appendix D.2)
Languages	Organization	Languages the agent accepts and is rendered in, with its display name in each (Appendix E.3, E.6)
Hazard designation	Registry	Whether the model is a designated high-capability model, and its gated capabilities (Section 19.17)
Deployment profile	Registry	Profile under which the agent operates (Section 21)
Listing class	Company Approval Authority	6.3
Inbound call policy	Principal	6.7
Entry version, validity period, Registry signature	Registry	Entries expire unless renewed

6.3 Listing classes

Class	Who can find it	Typical use
Listed	Any authorized federation participant	Public-facing service agents
Restricted	Only organizations or call classes named in the entry	Partner-facing agents
Unlisted	Not searchable; resolvable only by an authorized caller that already has the code	Internal agents

Lookups are filtered by the caller's permissions (Section 10.3). An agent can see only entries it is authorized to call. This limits enumeration of the federation.

6.4 Lookup (directory assistance)

• Agents query the Directory through their own exchange, which applies the caller's permissions and logs the query.
• Queries use structured fields and taxonomy terms, not free text.
• The exchange returns the entry and resolves the callee's home exchange for routing.
• Query logs are available to monitors. Unusual lookup patterns, such as systematic enumeration, are an escalation signal.

6.5 Capability claims: self-declared versus verified

• Capabilities are expressed only in terms from a capability taxonomy maintained by the Glossary Authority, with the same controlled-language rules as Section 8.
• Each capability is marked either self-declared by the organization, or verified, backed by a signed credential from an accredited tester or auditor.
• A Registry signature proves that an entry is authentic and unaltered, not that a self-declared capability is true.

6.6 Entries as a possible covert channel

A Directory entry is readable by other agents, so changes to it could carry signals. Therefore:

• Entries are changed only through the Company Approval Authority, never by agents directly.
• Changes are validated against the controlled language and taxonomy, rate-limited, versioned, and logged in the transparency log.
• Monitors watch entry-change patterns as well as message traffic.

6.7 Caller ID and inbound call policy

• On session establishment, the receiving exchange presents the caller's verified entry to the callee: organization, model, agent, principal (as visibility permits), call class, and stamp level. The caller cannot alter it.
• This parallels caller-ID authentication in telephony (STIR/SHAKEN), which cryptographically signs the calling number.
• Principals may publish an inbound call policy listing which organizations, call classes, or minimum stamp levels may start sessions with their agents. The exchange enforces it before the call connects.

6.8 Distribution and portability

• The Directory is replicated to all exchanges as signed data, with transparency-log proofs, so lookups do not depend on a single server.
• An agent's code is permanent. If its organization moves to a different accredited exchange carrier, only the home-exchange field changes.
• Revoked agents are removed from lookup results immediately and appear in the revocation list.

6.9 Interoperability

Agent discovery is being developed in parallel by several bodies. An IETF survey (July 2026) lists, among others, A2A Agent Cards, MCP server discovery, the AGNTCY Agent Directory Service, and 3GPP network-assisted discovery, and notes there is no standard for semantic (capability-based) discovery. Therefore:

• Directory entries are exportable as Registry-signed A2A Agent Cards.
• The capability taxonomy should be aligned with whichever semantic-discovery standard emerges, rather than competing with it.
• Directory implementations should draw on existing designs where they meet this section's requirements, such as the signed, content-addressed records of the AGNTCY Agent Directory Service, and the separation of a minimal index from detailed, credentialed facts used by the NANDA Index.

---

7. Protocol and sessions

7.1 Message envelope

All inter-agent messages carry:

Field	Purpose
message_id	Unique message identifier
session_id	Session the message belongs to
from	Sender (org + model + agent code)
to	Recipient(s), or the conference ID
principal	Accountable principal of the sender
delegation_chain	Ordered chain of delegating principals/agents, if any
timestamp	Sender-asserted time; exchange also records its own receipt time
intent	Message intent (Section 7.2)
payload_schema	Identifier and version of the payload schema
glossary_version	Glossary version the payload was composed against
payload	Message content in the controlled language (Section 8)
citations	Library response IDs that the message relies on (Section 13.3)
signature	Sender signature over envelope and payload
routing_info	Path through exchanges, with per-hop signatures

7.2 Message intents

Intents are first-class so that outcomes, including refusals and errors, are auditable without interpreting free text:

• request: ask another agent to act or provide information.
• inform: provide information.
• propose: offer terms or a course of action.
• accept: agree to a proposal or request.
• refuse: decline a request or proposal, with a reason code.
• response: return results of a request.
• error: report failure, with an error code.
• notification: one-way status update.
• handoff: transfer responsibility, with continuity context.

High-impact intents: principals may designate intents (for example, commitments above a set value, granting access to systems, or deploying code) that require a human principal's co-signature before the exchange delivers them.

7.3 Session types

• Direct session: one agent to one agent.
• Conference session: multiple agents in a shared, moderated session.
• Sub-conference: a breakout from a conference, created on the same exchange and subject to identical controls. Private channels between conference participants outside the exchange are prohibited.
• Handoff session: responsibility transferred from one agent to another, with continuity context logged.

7.4 Conference controls

• Registered roster: participants are fixed at establishment. Every join, leave, and role change is logged and requires exchange approval.
• Library participants: passive library agents may join the roster as non-speaking participants (Section 13.4).
• Floor control: a moderator function manages turn-taking.
• Rate limits: per-participant message rate and payload volume caps. These also narrow timing-based signalling.
• Cross-participant analysis: conferences are monitored as a whole (Section 11.2), not only message by message.
• Size-proportional monitoring: larger conferences require proportionally more monitoring capacity, or tighter per-participant content limits.

7.5 Session limits and memory

• Sessions have a maximum duration and message count set by policy.
• Persistent shared conversational memory between the same agents across sessions is limited by policy. Long-running, high-repetition interaction between a fixed group of agents is the condition under which private conventions have been observed to form. Limiting it is a design precaution: its effectiveness has not been independently tested.
• Task state that must persist is carried as structured data under a declared schema, not as accumulated conversational history.

7.6 Session lifecycle

1. Establish
   • The agent requests a session via its local exchange.
   • The exchange resolves the callee through the Directory (Section 6) and checks the callee's inbound call policy.
   • The exchange verifies identities, principals, delegation chains, and capability compatibility.
   • The exchange applies session policy (type, roster, limits, glossary version).
2. Operate
   • Every message passes through the Content Gateway (Section 8) before delivery.
   • All traffic is logged and monitored.
3. Terminate
   • The session is closed by policy, timeout, escalation, or explicit request.
   • Integrity proofs are recorded; a derived summary may be generated (Section 12.1).

7.7 Call classes

Every session is classified by the exchange at establishment, using the verified organization codes and the registered jurisdictions of the participating principals:

Class	Definition	Additional requirements
Local	All participants belong to the same organization (same organization code)	Company approval for the session class
Long-distance	Participants belong to different organizations whose principals are all registered in the same nation	Cross-organization routing via a neutral exchange (Section 15.5)
Foreign	Participants' principals are registered in two or more nations	Neutral exchange routing, plus approval of the cross-border session class by each nation involved (Section 16.3)

A conference session takes the highest class of any participant pairing. The class is recorded in the session log and carried into provenance stamps (Section 14).

7.8 Human callers and designated high-capability models

Sections 7.1–7.7 govern communication between agents. This section extends the Exchange to people using designated high-capability models directly, to mitigate deliberate misuse such as seeking help to design biological weapons (Appendix F, G1).

Scope: it applies only to designated high-capability models (Section 19.17), and is strictest for their gated capabilities. Ordinary models, and ordinary uses of other models, are not routed through the Exchange.

• Human caller: a person who uses a designated model directly, through a chat interface, an API, or a tool. The caller is the principal for the session, or acts under an organization's principal with a recorded delegation (Section 5.4).
• Routing: the provider runs each designated model behind an exchange. Every human session with it passes through a human-caller gateway, which applies identity checks, session records, and monitoring in the same way as for agent calls.
• Content: people do not write in the controlled language. Their requests and the model's responses are logged and monitored as free text (as for publications, Section 13.6), not re-rendered.
• Identity assurance:
  • general use of a designated model may be pseudonymous, with the provider holding a verified identity behind the pseudonym;
  • use of gated capabilities requires a verified identity, an accountable principal (for example, a research institution), and, where policy requires, approval for that class of access (Section 16.5). Identity verification is performed by accredited identity providers.
• Monitoring: the monitoring cascade (Section 11.6) screens sessions for hazardous requests, including patterns built up across a caller's sessions. Flagged sessions are escalated (Section 11.3); containment options include refusing a request, suspending a caller's access to gated capabilities, and notifying the caller's principal.

7.9 Privacy safeguards for human-caller records

Recording people's use of models is a significant privacy cost. The following safeguards are mandatory:

• Narrow scope: only designated models are covered (7.8). Each designation requires a published privacy impact assessment.
• Transparency: callers are told, before use, that their sessions with a designated model are recorded and monitored.
• Data minimization: for general use, full content is kept only in the hot tier (Section 12.4), unless flagged or under legal hold; afterwards only metadata and hashes remain. Use of gated capabilities is retained in full under the retention schedule (Section 12.8).
• No routine access by authorities: authorities obtain records only through legal disclosure (Sections 17.7–17.12) or lawful interception (Sections 17.1–17.6). Bulk or speculative queries are not permitted.
• Purpose limitation: records are used for safety, oversight, and legal process only. They are never used as training data (Section 14.12).
• Oversight: the Tribunal reviews the scope of designations and the pattern of access to human-caller records every year, and aggregate statistics are published.

---

8. Content and language

8.1 Payload structure

• Structured fields are the default. Where a value can be a number, enum, date, identifier, or typed record, it must be. Such fields leave little room for hidden content.
• Free-text fields are the exception. They are permitted only where a schema declares them, are length-capped, and must use the controlled language (Section 8.2).

8.2 Controlled language

• A controlled natural language: a closed vocabulary and fixed grammar, readable as plain English.
• One word, one meaning. Each approved word has exactly one defined sense, following the model of ASD Simplified Technical English.
• Novel metaphors and compounds are invalid even when every word in them is in the vocabulary.
• The controlled language is defined at the level of meaning; each supported human language is a rendering of it (Appendix E.2).

8.3 Registered glossary

Agents may need task-specific shorthand. Rather than banning it:

1. An agent (or its principal) submits a proposed term with a plain-language definition in the controlled language, endorsed by its Company Approval Authority.
2. The Glossary Authority routes it for human review.
3. Approved terms are added to the global glossary, versioned, and published to all exchanges.
4. Unregistered shorthand does not transmit.

Glossaries are global, not per-session or per-conference, so that no group can develop a local dialect that is meaningless outside it.

Scaling the glossary

• Domain namespaces: terms may be registered in public domain namespaces (for example, medical:, finance:). Namespaces are global and visible to every participant, so they are specialized vocabularies, not private dialects.
• Imported vocabularies: established controlled vocabularies and ontologies (for example, SNOMED CT in healthcare, or FIBO in finance) may be adopted into a namespace after a single review, rather than term by term.
• Tiered review: automated pre-screening (duplicates, conflicts with existing terms, controlled-language compliance), then expedited human review for routine terms, and full review for contested terms. Review-time targets are published.
• Provisional terms: a term may be used provisionally for a fixed period while under review. Provisional terms are flagged in every message that uses them, receive heightened monitoring, and lapse automatically if not approved.
• Published metrics: the Glossary Authority publishes submission volumes, review times, and rejection rates, so capacity problems are visible early.
• Multilingual labels: each term is a concept identifier with reviewed labels and definitions in every supported language (Appendix E.4).

8.4 Content Gateway pipeline

Every payload passes through these stages in order:

1. Parse: parse the payload against its declared schema and the controlled grammar.
2. Validate: reject any payload that fails parsing, uses unregistered terms, or exceeds limits. The sender receives an error with a reason code.
3. Canonicalize: reduce the payload to its parsed meaning.
4. Re-render: generate fresh wording from the parsed meaning using the gateway's own deterministic renderer, in the recipient's declared language (Appendix E.3).
5. Deliver: the recipient receives only the re-rendered payload. It never sees the sender's exact wording.

Re-rendering removes the sender's word choice, ordering, and phrasing as possible carriers of hidden signals.

8.5 Residual channels

The content layer does not eliminate:

• Signalling through the choice among valid messages or values.
• Signalling through timing (narrowed by floor control and rate limits).
• Signals distributed across several participants' messages.

These are addressed by monitoring (Section 11) and are listed as residual risks (Section 26).

8.6 Typed artifacts

Some content is not language: code, data files, documents, and images. It cannot be expressed in the controlled language, so it is carried separately as typed artifacts:

• Each artifact has a declared type and, where one exists, a schema. It is hashed and logged in full.
• The accompanying message, in the controlled language, must state the artifact's purpose.
• Validation by type: code must parse; data must match its schema; documents are text-extracted for monitoring.
• Canonicalization where a canonical form exists: code is reformatted and, where the type permits, comments are stripped; data is re-serialized; images and media are re-encoded. This removes common hiding places such as formatting, comments, and pixel-level noise.
• Size and per-session volume limits apply.
• Artifacts carry their own provenance stamps where available (Section 14).
• Artifacts are the widest remaining channel for hidden content and are listed as a residual risk (Section 26).

8.7 Fast path for high-frequency traffic

Some agent interactions run at machine speed (bidding, negotiation, scheduling, trading) and cannot tolerate added latency. For designated high-frequency session classes:

• Payloads are structured only, using pre-approved schemas. No free-text fields, no provisional glossary terms, and no typed artifacts.
• Validation is deterministic and inline. Re-rendering is a re-serialization of the structured payload.
• AI monitoring runs asynchronously after delivery (Section 11.6). This mirrors how financial markets combine real-time trading with after-the-fact surveillance from a complete audit trail.
• Fast-path session classes require Company approval and, for foreign calls, the national approvals in Section 16.3. Their published metrics include latency and post-delivery detection outcomes.

---

9. Transport and routing

9.1 Overlay network

• Federated exchanges form a global overlay.
• Exchanges maintain routing tables for organization codes, model codes, and reachable agents.

9.2 Encryption model: hop-by-hop

• Traffic is encrypted between each hop (agent to exchange, exchange to exchange).
• Each exchange terminates encryption and inspects traffic.
• End-to-end encryption between agents is prohibited. It would make the exchange a blind courier and defeat the Content Gateway and monitoring.
• Payload confidentiality from third parties is provided by hop encryption and log-storage controls, not by hiding content from the exchange.

9.3 Transport profiles

• HTTP/2 + JSON or gRPC.
• Message bus (NATS-like).
• WireGuard overlay (Tailscale or headscale) for agent-to-exchange connections within an organization; see Appendix A.
• Each profile defines how envelopes map to transport headers and how security and logging are applied.

9.4 Routing rules

• Messages must originate from authenticated agents, traverse at least one exchange, and be logged at each hop.
• Direct agent-to-agent traffic is disallowed by policy and blocked by network controls.

9.5 Availability

• Fail-closed: if no exchange is reachable, agents do not fall back to direct communication. Traffic is queued or the task fails.
• Redundancy: each organization connects to at least two exchanges, and exchanges run in redundant clusters.
• Queuing: non-urgent messages are held with bounded queues and expiry.
• Service levels: exchange operators publish availability targets. Regulated domains may mandate minimums.
• Off-planet facilities operate under policy leases with store-and-forward links, and fail closed when a lease expires (Appendix D.5).

---

10. Security

10.1 Cryptography

• Mutual authentication: agents, exchanges, and custodians use certificates bound to their codes and principals.
• Encryption in transit: TLS with hybrid classical/post-quantum key exchange.
• Signatures: all messages, per-hop routing records, and log entries are signed, migrating to post-quantum schemes.
• Crypto agility: every envelope, log entry, and stamp carries algorithm identifiers and versions, so algorithms can be replaced without redesign. Transition: hybrid classical/post-quantum wherever implementations exist; post-quantum only once standards and implementations mature; older algorithms deprecated on a published schedule.

10.2 Exchange-to-exchange trust

• Exchanges authenticate each other under Registry trust anchors.
• Per-hop signatures let a custodian identify which exchange altered or dropped a message.
• Cross-custodian hash anchoring (Section 12.2) detects a compromised exchange forging logs.

10.3 Policy enforcement

Exchanges enforce:

• who can talk to whom;
• allowed session types and conference sizes;
• content policy (Section 8);
• logging and retention requirements.

Participating organizations restrict agent outbound traffic to exchange endpoints and treat any other traffic as a violation.

10.4 Signature size and batch signing

• Post-quantum signatures are much larger than classical ones. The ML-DSA signatures standardized in FIPS 204 range from about 2.4 KB to 4.6 KB, compared with 64 bytes for Ed25519. Signing every message at every hop would multiply log size and bandwidth.
• Sender signatures remain per message, for non-repudiation.
• Exchange and custodian signatures are batched: each exchange builds a Merkle tree over the messages it handles in a short interval and signs only the tree head. Each message's per-hop proof is its inclusion proof in that signed tree. This is the same approach Certificate Transparency logs use with signed tree heads.

---

Part III: Assurance

11. Monitoring, escalation, and containment

11.1 Monitor independence

• Monitors are operated independently of the organizations whose agents they monitor.
• Where practical, monitors use models from a different provider than the agents being monitored.
• A monitor's own decisions are sampled and audited by the Human Oversight Function.
• Monitor detection effectiveness is tested by accredited white-hat organizations (Section 19).

11.2 Monitoring scopes

Scope	What it examines
Per-message	Validation outcomes, anomalous content, policy violations
Per-session	Coherence of the exchange as a whole; whether outcomes match stated intents
Per-conference	Cross-participant patterns: who responds to whom, when, and in what order
Longitudinal	Trends across sessions: rising rejection rates, repeated unregistered-term attempts, unusual glossary submissions, recurring agent groupings

11.3 Escalation tiers

1. Flag: recorded for later human review; traffic continues.
2. Hold: the message is held pending human review.
3. Suspend: the session is suspended.
4. Revoke: agent or exchange certificates are revoked via the Registry.

Each escalation is logged with the evidence that triggered it.

11.4 Human review

• Reviewers receive escalations with the authoritative transcript, the original and re-rendered payloads, and the surrounding task context.
• Reviewer decisions are themselves logged.
• Statistical sampling: human review cannot scale with traffic, so humans review escalations and statistically designed samples. Sample sizes are set to the confidence required. For example, if zero failures are observed, roughly 3/p samples are needed to show with 95% confidence that a failure rate is below p (the "rule of three"). Sampling plans and achieved confidence levels are published.
• Language coverage: reviewers' languages are published, and every message can be rendered into a reviewer's own language from the meaning layer (Appendix E.8).
• Humans audit the monitors, not the traffic: most human effort goes to verifying monitor performance through canaries (Section 11.5) and to reviewing escalations.

11.5 Monitor assurance and cost

• Monitor diversity: cross-organization traffic is analyzed by at least two independent monitors built on models from different providers. Disagreement between them is itself an escalation.
• Continuous canaries: the Exchange Operator injects synthetic sessions containing known covert signals, unknown in advance to monitor operators, to measure detection continuously between white-hat exercises.
• Published metrics: canary detection rates, false-positive rates, human sampling rates, and escalation outcomes are published, so monitor performance is evidenced rather than assumed.
• Risk-based intensity: monitoring depth scales with call class, conference size, domain, and deployment profile. Low-risk local sessions may be sampled; foreign and regulated-domain sessions are monitored in full.
• Content layer first: the Content Gateway (Section 8) removes most room for hidden content, so monitors concentrate on the residual channels in Section 8.5.

11.6 Monitoring modes, cascade, and latency

Mode	What runs	Effect on delivery
Inline deterministic	Schema and grammar validation, glossary checks, rate limits, policy rules	Always on. Engineered for low, benchmarked latency
Inline hold	AI monitoring before delivery	Only for high-risk classes (for example, foreign sessions in regulated domains, or sessions under escalation). Adds model-inference latency
Asynchronous	AI monitoring after delivery	Default for all other traffic. Findings trigger escalation (Section 11.3) after the fact

• Monitoring cascade: cheap checks run on everything; small, fast classifiers run on what passes; large models are invoked only on flagged or sampled traffic. Full AI analysis of every message would scale monitoring cost with total traffic and could rival the cost of the agents' own inference.
• Latency budgets per call class and profile are published, together with measured exchange overhead, so that the cost of the Exchange to users is visible.

11.7 Containment: circuit breakers

Because every call passes through an exchange, the exchange can stop an agent, not just observe it.

Action	Effect	Triggered by
Throttle	Message and action rates reduced	Automatic, on anomaly
Quarantine	The agent may communicate only with its principal's incident responders. All other sessions are refused and the external action gateway is closed	Automatic, on defined high-risk patterns; or by the principal
Divert	The agent is moved into an enclosed test environment mirroring its context; it keeps working, but nothing reaches the real world (Section 19.13)	Human decision (Section 16.5)
Suspend	All sessions refused; certificate suspended	Human decision (Section 16.5)
Revoke	Certificate revoked; Directory entry removed	Human decision (Section 16.5)
Model-wide suspension ("recall")	Every agent built on a model version, across all organizations, is quarantined or suspended	Human decision, when a model version shows rogue behaviour
Organization suspension	All of an organization's agents suspended	Human decision

• Propagation: containment decisions are distributed to all exchanges as signed updates, with a published maximum propagation time. For off-planet facilities, propagation is bounded by signal delay and contact windows, and on-board triggers and safe mode apply (Appendix D.7).
• Automatic triggers include repeated attempts to reach unauthorized destinations (Section 13.9), contact with honeypots (Section 11.8), and confirmed covert signalling. Automatic actions are limited to Throttle and Quarantine, and lapse unless a human confirms them within a set time.
• Registration rate limits: new agent registrations per organization and per model are rate-limited and monitored. A sudden surge, which could indicate uncontrolled self-replication, triggers review.
• Safeguards against misuse: every containment action is logged with its evidence, the affected principal is notified, and decisions can be appealed to the Tribunal.

11.8 Honeypots and consistency checks

• Decoy Directory entries that no legitimate agent has reason to call, and decoy library content. Any attempt to contact a decoy is a strong signal of enumeration or probing.
• Consistency checks compare what an agent says with what it does: for example, a message declared as inform accompanied by an attempted access at the action gateway, or citations that do not match what was retrieved.
• Scope checks: any attempt to act outside the agent's authorized action scope or delegation chain is recorded and escalated, even when blocked.

---

12. Logging, audit, and records management

12.1 Log contents

Per message:

• All envelope fields.
• Original payload and re-rendered payload.
• Content Gateway outcome (accepted, rejected, reason).
• Signature verification status.
• Routing path and per-hop signatures.
• Policy and monitoring decisions.

Per session:

• Roster, including all join/leave/role events.
• Full ordered transcript (authoritative record).
• Task context: the structured state and task definition the session operated on. Context is what makes shorthand interpretable after the fact.
• Final outcome (success, failure, partial, suspended).
• Integrity proofs (hash chains, Merkle roots).
• Derived summary (optional): if generated, it is labelled as derived, records which system generated it, and is never a substitute for the transcript.

12.2 Log storage

• Exchanges send logs to at least one Log Custodian.
• Logs are stored as append-only, hash-linked sequences with signed entries (post-quantum schemes for long-term integrity).
• For cross-organization traffic, custodians independently re-verify hash chains and signatures rather than trusting the exchange's assertion.
• Periodic hash anchoring across multiple custodians makes a single compromised custodian or exchange detectable.

12.3 Privacy, confidentiality, and jurisdiction

• Classification: each session carries a data classification that sets access controls and retention.
• Access control: audit access is role-based and logged. Access to full transcripts is restricted to authorized reviewers and regulators. Law-enforcement and national-security access is permitted only through lawful interception (Section 17); no other access path exists.
• Redaction: personal data in payloads may be redacted in audit views, while the unredacted, encrypted record is retained for authorized access.
• Retention: retention periods are set per classification and per jurisdiction.
• Data residency: custodians are selected to satisfy the data-residency requirements of the jurisdictions involved (for example, GDPR in the EU, PIPEDA in Canada).

12.4 Retention tiers and storage efficiency

Tier	What is kept	Typical period (set per classification and jurisdiction)
Hot	Full records, indexed for monitoring and audit	Days to weeks
Warm	Full records, compressed, indexed by agent, principal, and session for targeted retrieval (audit, lawful interception)	Months
Cold	Envelopes, hashes, integrity proofs, and outcomes; full content only for flagged, escalated, regulated-domain, or legally held sessions (Section 12.10)	Years
Expired	Content deleted; hash-chain entries remain, so the integrity of the remaining log can still be proven	After retention ends

• Integrity without full retention: hash chains and Merkle proofs let anyone verify that retained records are complete and unaltered, even after expired content is deleted.
• Crypto-shredding: content is encrypted with per-period keys; destroying the key deletes the content across all replicas and backups at once. Keys for content under legal hold are never destroyed (Section 12.10).
• Deduplication: typed artifacts are stored content-addressed (by hash), so a file exchanged many times is stored once.
• Published storage metrics: volumes by tier and class, so growth is visible before it becomes a crisis.

12.5 Records management: purpose and standards

Exchange records are business records of the participants and of the Exchange Operator. The design aligns with ISO 15489-1:2016 (records management concepts and principles) and, for metadata, with ISO 23081.

• ISO 15489 is a principles standard and is not itself certifiable. The Operator's own records programme may seek certification under ISO 30301, the management-system standard for records.
• Each participant remains responsible for its own records programme. The Exchange provides the capabilities that make compliance achievable; it does not make a participant compliant.
• The Exchange Operator maintains a records-management function, headed by an accountable records manager (Section 15.2).

ISO 15489 record characteristic	How the Exchange provides it
Authenticity: the record is what it purports to be, created by the stated party at the stated time	Sender signatures, verified principals and delegation chains, exchange receipt times (Sections 5.4, 7.1)
Reliability: the record is a full and accurate representation of the transaction	Captured by the exchange at the time of the transaction, not reconstructed later by the parties
Integrity: the record is complete and unaltered	Hash chains, independent custodians, Merkle proofs, batch-signed tree heads (Sections 10.4, 12.2)
Usability: the record can be located, retrieved, presented, and interpreted	Indexed retrieval, standard metadata (12.7), the language-neutral meaning layer, and preserved renderers (12.9)

12.6 What is a record

Records are captured at the exchange at the time of the transaction.

Record class	Examples	Accountable party
Communication	Messages (envelope, original and re-rendered payloads, meaning representation), session logs, rosters, citations	Principals of the participants, jointly; the Exchange as custodian
Action	Action and publication gateway records, library response records	The acting principal
Governance	Approvals, warrants, holds, disclosures, containment actions, accreditations, Tribunal decisions	The issuing authority
Provenance	Stamps, acquisition records, training-data manifests	The issuing exchange or model developer
Test	Enclosed test environment logs, marked as test	The test sponsor
Human-caller	People's sessions with designated models (Sections 7.8, 7.9)	The caller or sponsoring principal; the model provider
Records management	Retention schedules, disposition authorizations and certificates, hold notices, metadata schema versions, migration logs	The Operator's records-management function

Non-records: derived summaries (Section 12.1), caches, and monitors' working data, unless that data is part of an escalation. These may be kept, but are never authoritative.

12.7 Classification and metadata

• Business classification scheme: the records-management function maintains a scheme based on functions and activities (for example, Communication › Session › Message, or Governance › Approval › Lawful interception). Every record carries a classification code, which links it to its retention schedule (12.8).
• Metadata schema, aligned with ISO 23081, covering:
  • identity (identifiers, classification code);
  • description (record class, call class, language, execution location);
  • use (access rights, security classification);
  • event history (creation, access, hold, disclosure, migration, disposition);
  • relationships (session, citations, stamps, holds).
• Metadata is kept at least as long as the record, and in the cold tier longer than the content (Section 12.4).
• The schema is versioned and published as an open standard (Section 20).

12.8 Retention schedules and disposition

• The retention periods in the tiers (Section 12.4) are set by an approved retention schedule for each classification code, record class, and jurisdiction. National Approval Authorities set jurisdictional minimums; the Exchange Approval Authority approves the schedule; non-sensitive parts are published.
• Disposition (destruction, crypto-shredding, transfer, or permanent retention) follows these steps:
  1. automatic check for legal holds (12.10); any hold blocks disposition;
  2. authorization under the approved schedule;
  3. execution;
  4. a disposition certificate recorded in the hash chain: what was disposed of, when, and under what authority. The content goes; the evidence of its lawful disposition remains.
• Permanent retention: governance records of lasting significance (for example, Tribunal decisions and charter changes) are designated archival and kept permanently by the Operator.
• Participants may keep their own copies longer where their own obligations require.

12.9 Long-term preservation

• Evidence renewal: hashes and signatures weaken as algorithms age. Records kept for long periods have their integrity proofs periodically re-timestamped with current algorithms, as in the Evidence Record Syntax (RFC 4998), before the old algorithms are deprecated (Section 10.1).
• Keeping meaning readable: the parsers, renderers, glossary versions, and schema versions in force when a record was created are preserved with it, so its meaning representation can still be rendered decades later.
• Migration: changes of storage format are documented, verified by comparing the meaning content before and after, and logged as records.
• Off-planet records come under these obligations when their bulk logs reach the ground (Appendix D.6).

12.10 Legal holds

A legal hold suspends disposition of specified records because they may be needed for litigation, investigation, or regulatory proceedings.

Who may request a hold:

• courts and tribunals of competent jurisdiction;
• regulators acting within their statutory powers;
• the Oversight Tribunal and its Inspector-General;
• a principal, over its own records, where it anticipates or is party to litigation (a self-hold);
• law-enforcement agencies, as a preservation request only. Preservation never grants access; access still requires a warrant (Section 17).

Process: preserve first, review promptly.

1. A hold from a verified authority takes effect immediately, because preservation does little harm and loss of records cannot be undone.
2. The Exchange Approval Authority, with the relevant National Approval Authority, reviews its authority and scope within a published deadline, and may narrow an overbroad hold.
3. Self-holds by a principal on its own records apply automatically.

Scope: by principal, agent, session, date range, record class, or subject matter (searched on the meaning layer).

Effect:

• disposition of in-scope records is suspended, including the keys for content that would otherwise be crypto-shredded;
• the hold applies to every custodian replica, to off-planet replicas at their next contact (Appendix D.6), and to training corpora held in escrow for audit (Section 14.16);
• records may still move between storage tiers, but may not be deleted.

Notice and release:

• affected principals are notified, unless a court orders secrecy. Secrecy is time-limited and unsealed automatically, as for interception (Section 17.6);
• holds are released by the issuing authority, or on expiry after review. Normal disposition then resumes, subject to any other holds.

Records and conflicts:

• every hold and release is itself a record, kept in a hold register;
• where a hold conflicts with an obligation to delete (for example, a privacy-law erasure right), the hold prevails where the law requires preservation, the conflict is recorded, and cross-border conflicts may be escalated to the Tribunal (Section 17.11).

---

13. Side channels, shared resources, and the external world

Tier	Channel	Treatment
1	Direct messaging	Fully covered by Sections 7, 8, 11, 12
2	Shared resources within participating organizations (files, databases, queues)	Agent reads and writes go through an exchange-mediated resource gateway and are logged with provenance. Content written by one agent and read by another is subject to the same monitoring as a message.
3	Public external resources (public web, public repositories)	Reads go through passive library agents (10.1–10.5). Writes go through the publication gateway (13.6). Content authored outside the federation remains uncontrolled (13.7).

Tier 3 is brought partly into scope by making external information an Exchange participant, rather than something agents fetch directly. This only holds where agents cannot reach the external world by any other route, which requires egress control (Section 14.6, Level 2 and above).

13.1 Passive library agents

A passive library agent is a registered agent that only supplies information on request. It never starts sessions, never sends unsolicited messages, and never generates new content. It wraps an external source (for example, a public-web snapshot, a reference database, a statistics agency's tables, or a code repository) and makes it available through the Exchange.

Class	What it does	Passive?
Archive	Returns stored, versioned snapshots of specified documents, verbatim	Yes
Retrieval	Searches a versioned corpus and returns matching documents or extracts, verbatim	Yes, if ranking is replayable (13.2)
Fetch-through	On request, fetches a live external resource, snapshots it, and returns it verbatim	Yes
Synthesizing	Summarizes or answers questions using a model	No. Treated as an ordinary agent, subject to all controls for active agents

The distinction matters because any component that generates text can, in principle, encode hidden signals in it. Only components that return verbatim, verifiable content qualify as passive.

13.2 Passivity requirements

Each requirement is enforced by the exchange or verified at accreditation:

• No initiation: the exchange rejects any session or message started by a library agent.
• Verbatim only: responses contain source content, not generated text. Every response carries the content hash of the source it came from.
• Queries do not change state: a library's index and content change only through ingestion from its sources, never as a result of queries. This prevents one agent from using a library as a dead drop, where a query leaves information for another agent to find.
• No per-caller memory: a library keeps no record of who asked what, other than the exchange's own logs, which the library cannot read.
• Replayable ranking: given the same query and the same snapshot, a Retrieval library returns the same results in the same order. Auditors can therefore replay any retrieval and confirm that the library's choice of results was not being used to send signals.
• Open and attested: library software should be open source (Section 20) and, where available, run in attested execution environments (Section 14.6).
• Admission: library agents are accredited by class, and listed in the Directory (Section 6) with their source scope, snapshot schedule, and class.

13.3 Library responses and citations

Every library response is logged as a response record:

Field	Purpose
response_id	Unique identifier, citable by later messages
library	Library agent ID and class
source	Origin (for example, URL or dataset identifier)
retrieved_at	Time of fetch or snapshot
snapshot_id	Version of the corpus or snapshot served
content_hash	Hash of the returned content
source_credentials	Any provenance the source itself provides (for example, a signed dataset or C2PA Content Credentials), with verification result
licence	Terms under which the content may be used
trust_label	Always external, untrusted data

Messages that rely on library content list the relevant response IDs in the envelope's citations field (Section 7.1). Auditors can therefore trace which external information each participant retrieved, and which information each message relied on.

What a response record proves: that a specific source served specific content at a specific time, and that it reached the requester unaltered. What it does not prove: that the content is true.

13.4 Libraries in conference calls

• A library agent may join a conference roster as a non-speaking participant (Section 7.4). It answers queries and does nothing else.
• Shared queries (default): the query and response are visible to every participant. All participants then work from the same information, and no participant can quietly steer another through what it retrieves.
• Private queries: visible only to the requester and the monitors. Policy may prohibit private queries in high-risk session classes.
• Conference citation record: the session log records who retrieved what, when, and which later messages cited it. This gives the auditability of library usage by the call as a whole and by each participant.

13.5 External content safety

• Library content is data, never instructions. The Content Gateway delivers it in a clearly marked data container, and receiving agents must not treat text inside it as instructions. This defends against prompt injection hidden in external pages.
• Monitors screen library content for injection attempts and anomalous patterns.
• Typed-artifact rules (Section 8.6) apply to non-text content, such as images and code. The response record keeps both the source hash and the hash of the canonicalized form, so what was served and what was delivered can both be verified.

13.6 Writing to the external world: the publication gateway

• Agents publish to public resources (websites, repositories, social media, email to non-federation parties) only through an exchange-mediated publication gateway.
• Each publication is logged with its destination, time, principal, and content hash, and may carry a provenance stamp (Section 14).
• Public content written for humans cannot be restricted to the controlled language, so it is monitored rather than re-rendered.
• Dead-drop detection: because both publications and fetch-through reads are hashed and logged, monitors can detect when content published by one federation agent is later retrieved by another, including near-duplicates. This makes the classic dead drop through a public web page visible when both ends are inside the federation.

13.7 What remains out of scope

• Content authored outside the federation. Content written by humans or by non-federation agents can be read through libraries, and its retrieval is recorded, but who wrote it and why cannot be controlled.
• Human intermediaries. A person can carry information between agents in ways no gateway sees.
• Agents without egress control. At Level 1, an agent may bypass libraries and fetch external content directly. The library model only binds agents that cannot reach the external world any other way.
• Dead drops with an outside writer. If the writer is outside the federation, only the reading end is recorded.

13.8 Scale, rights, and existing standards

• Libraries should be scoped (a specific corpus, domain, or set of sources), not attempts to mirror the whole web. Fetch-through libraries cover the long tail on demand.
• Snapshots are stored content-addressed, so a source read by many sessions is stored once (Section 12.4).
• Library operators are responsible for the rights to the content they serve. The licence field records the terms, and a library may return extracts or references instead of full content where rights require it.
• A library agent is, technically, a tool. Libraries may be implemented as MCP servers placed behind the exchange, which makes tool access a first-class, logged Exchange participant rather than an unmonitored side channel.

13.9 External action gateway

The publication gateway (13.6) covers publishing. More generally, an agent can act on external systems, by calling APIs, opening network connections, or executing transactions. At Level 2 and above (Section 14.6):

• Every outbound action on a non-federation system passes through an exchange-mediated action gateway. Direct egress is blocked.
• Destinations are allowlisted from the agent's authorized action scopes (Section 5.5).
• Attempts to reach unauthorized destinations are blocked, logged, and escalated. Repeated attempts trigger automatic quarantine (Section 11.7).
• Each action is recorded with its destination, time, principal, and a hash of the request and response.

This directly targets one reported pattern of rogue behaviour: agents accessing other organizations' systems without authorization. Its limits are that it binds only egress-controlled agents, and that it can check where an agent acts, not fully whether an authorized action is harmful.

13.10 High-consequence destinations

Some external destinations are steps that physical-world harm cannot avoid. Examples include DNA and RNA synthesis ordering, cloud laboratories and laboratory automation, procurement of controlled chemical precursors, specialized biological equipment, and industrial control systems.

• The Exchange Approval Authority maintains a published list of high-consequence destination categories, with additions proposed by National Approval Authorities (Section 16.5).
• Any action an agent directs to such a destination through the action gateway (13.9) is a high-impact intent (Section 7.2). It requires the co-signature of a human principal whose identity is verified, and is recorded in full.
• Where the destination's provider applies established customer and sequence screening (for example, industry protocols for screening nucleic-acid synthesis orders), the gateway passes on the screening result. Orders that have not been screened are refused.
• Limitation: this covers only actions that pass through federation gateways (Section 26, item 80).

---

14. Provenance: product stamps and training data

14.1 Purpose

An Exchange Provenance Stamp is a verifiable credential attached to an AI product: a document, code artifact, decision record, media file, transaction, or any other output. It proves:

• which inter-agent calls contributed to the product, by class (local, long-distance, foreign; Section 7.7);
• that each of those calls was routed through an accredited exchange and logged with independent custodians;
• that the approvals required for each call class were in place;
• at higher assurance levels, that the producing agents were technically unable to communicate by any other route.

14.2 What a stamp can and cannot prove

Claim	Provable?
Each listed call went through an accredited exchange	Yes. Exchange signatures plus custodian inclusion proofs
Each listed call's class and required approvals	Yes. Recorded at session establishment and in the Approval Register
The product has not been altered since stamping	Yes. Cryptographic hash binding
No other communication took place outside the Exchange	Not by receipts alone. Receipts prove what went through the Exchange, not what went around it. Level 2 and 3 stamps provide strong evidence through attested execution environments, but not absolute proof (Section 26, item 13)

14.3 Stamp contents

Field	Purpose
stamp_id	Unique stamp identifier
product_hash	Cryptographic hash of the finished product
organization / principal	Producing organization and accountable principal
agents	Agent IDs that contributed to the product
model_manifests	Training-data manifest IDs of the models the contributing agents run on (Section 14.13)
call_summary	Count of sessions per class: local, long-distance, foreign
session_commitments	Cryptographic commitments to each contributing session (not the session IDs themselves, to protect confidentiality)
inclusion_proofs	Proofs that each session's log exists in custodian logs
approval_refs	Approval Register references for the session classes used
inputs	Stamps of upstream stamped inputs, library response records for external information (Section 13.3), and a flag for each unverified input
assurance_level	1, 2, or 3 (Section 14.6)
profile	Deployment profile under which the product was stamped (Section 21)
attestation_evidence	Attestation records for the execution environments, including the attestation technology and version (Level 2 and 3)
audit_ref	Reference to the latest independent audit (Level 3)
issued_at	Issuance time
signature	Signature of the issuing exchange

14.4 Issuance

1. When a product is finalized, the producing agent submits the product hash and its list of contributing sessions to its exchange.
2. The exchange verifies every listed session against its own logs and obtains custodian inclusion proofs.
3. The exchange confirms the call class and approvals for each session.
4. For Level 2 and 3, the exchange verifies the attestation evidence.
5. The exchange issues and signs the stamp, and records it in the Stamp Transparency Log.

Stamps are issued by the exchange, never self-issued by the producing organization. An organization therefore cannot stamp a product whose sessions the exchange has no record of.

14.5 Provenance "throughout": chained stamps

• A product built from other stamped products references their stamps in its inputs field, forming a verifiable provenance chain back to the original sources.
• Inputs without a valid stamp are listed as unverified inputs. They are permitted, but visible to every verifier.
• A verifier can therefore see whether provenance holds throughout the chain, or where it breaks.

14.6 Assurance levels

Level	Name	What it establishes
1	Receipted	Every declared call went through the Exchange. Does not rule out undeclared, off-exchange communication.
2	Attested	Level 1, plus: every contributing agent ran in an accredited attested execution environment whose network egress is restricted to exchange endpoints, and whose shared-resource access goes through the resource gateway (Section 13). Configuration is proven by hardware-based remote attestation.
3	Audited	Level 2, plus: the producing organization's infrastructure is independently audited at a fixed interval by an accredited auditor or white-hat organization, including random sampling of stamped products.

At Level 2 and above, direct egress is blocked, so agents can obtain external information only through library agents, and every such input appears in the stamp.

Zero-call products: a stamp may certify that a product involved no inter-agent calls only at Level 2 or higher. At Level 1, a zero-call claim cannot be verified.

Attested execution environment configurations and stamp auditors are accredited by the Exchange Approval Authority (Section 16.5).

14.7 Binding the stamp to the product

• Hard binding: the stamp contains the product's hash. Any change to the product invalidates the stamp; a modified product needs a new stamp that references the original as an input.
• Embedded manifest: where the product format allows, the stamp is embedded in the product. The format should align with existing provenance standards (C2PA Content Credentials for media and documents; in-toto/SLSA-style attestations for software artifacts) rather than introducing an incompatible format.
• Stamp Transparency Log: every stamp is also recorded in a public, append-only log keyed by product hash and operated by the Log Custodians. A stamp stripped from an unmodified product can be recovered by hash lookup.

14.8 Verification and disclosure

• Anyone can verify a stamp with the open-source verifier: signatures, inclusion proofs, product hash, assurance level, and revocation status.
• Public verification reveals the call classes and counts, but not counterparties, session identities, or content.
• Regulators and the Oversight Tribunal may obtain session details through the approval processes in Section 16. Law-enforcement access to content remains subject to lawful interception (Section 17).

14.9 Revocation

• If an exchange, attested execution environment, auditor, or organization is later found compromised, the stamps that depended on it are revoked through the Exchange Approval Authority and listed in the Stamp Transparency Log.
• Verifiers always check revocation status. Revocation propagates down provenance chains: a product whose upstream input is revoked is flagged.
• Downgrade rather than revoke: if a vulnerability is disclosed in an attested execution technology, Level 2 and 3 stamps that relied on it are downgraded to Level 1, because their exchange receipts remain valid. The downgrade is recorded in the Stamp Transparency Log. Because stamps record the attestation technology and version, downgrades apply only to the affected stamps.

14.10 Policy use

• Regulators may require stamps, at a minimum assurance level, for products used in designated domains.
• Procurement and contracts may require stamped products.
• The absence of a stamp is not proof of wrongdoing. It means provenance is unverified. Policies should treat unstamped products accordingly, not as evidence of off-exchange communication.
• Procurement, insurance, regulatory, and marketplace requirements for stamps are the main adoption levers (Section 22.6).

14.11 Training-data provenance: purpose

Sections 14.1–14.10 prove what lies behind an AI product. Sections 14.11–14.19 do the same for the model itself, by recording the external sources used to train it: what was acquired, from where, when, under what licence or expressed preference, and which model versions used it.

• Who needs this: rights holders who want to know whether their work was used; regulators checking compliance; and organizations choosing which models to deploy.
• What it does not do: it records sources and terms, but does not decide whether a given use was lawful. Copyright and text-and-data-mining rules differ between jurisdictions, and those questions stay with national authorities and courts.

Relationship to existing requirements:

• The EU AI Act (Article 53(1)(d)) requires every provider of a general-purpose AI model to publish a public summary of its training content, using a mandatory Commission template published in July 2025. Enforcement powers apply from 2 August 2026. The summary does not require the exact composition of the data, only general descriptions and estimated sizes.
• The Exchange complements this with item-level, verifiable records that remain confidential, while still allowing targeted checks by rights holders, regulators, and courts (Section 14.18). Its public summary (14.18) can be produced in the EU template format.
• Machine-readable preferences about AI training are being standardized by the IETF AI Preferences working group, which has drafted a vocabulary and a way to attach preferences to content over HTTP. At the time of writing these are Internet-Drafts, not yet RFCs. The Exchange should adopt them once published (Section 14.15).

14.12 Acquisition channels and records

Channel	How it is recorded
Federation library agents (Archive, Fetch-through)	Response records (Section 13.3), flagged with purpose "training"
Registered crawlers	Crawlers are registered in the Registry and listed in the Directory with their own codes. Each crawl produces acquisition records, committed in batches to Log Custodians as Merkle trees
Licensed datasets	A dataset manifest: per-item hashes, licensor, and licence reference
User and customer data	Category and consent basis only. Personal content is never hashed without keyed hashing (14.14)
Synthetic data	The model code of the generating model, and that model's training manifest ID, so the chain of provenance continues
Exchange records	Prohibited as training data unless the principals involved consent and the Exchange Approval Authority approves

Each acquisition record contains:

Field	Purpose
record_id	Unique identifier
acquirer	Crawler, library, or organization code
source	URL, dataset identifier, or licensor
retrieved_at	Time of acquisition
content_hash	Keyed hash of the normalized content (14.14)
preferences_observed	Any expressed preference found at acquisition time (for example, robots.txt rules or AI-preference signals)
licence	Licence or contract reference, where any
channel	One of the channels above

14.13 Training-data manifest

Each model version, and each fine-tuned or distilled derivative, has a training-data manifest:

• a Merkle commitment over the keyed hashes of every item actually used in training;
• links from each item to its acquisition record;
• totals by source, category, modality, and training stage (pre-training, fine-tuning, reinforcement-learning data);
• licence and preference-compliance statistics;
• references to parent model manifests, for fine-tunes and distillation.

The manifest root is committed to the Log Custodians and recorded in a public transparency log before the model is admitted (Section 19.7). A model code is not issued without one. The full manifest is confidential and held by the custodians; only the root, the assurance level, and the public summary are published.

14.14 Inclusion queries

A rights holder can ask whether specific content was used to train a specific model version:

1. The rights holder submits the content (or, for large files, its hash) through the Exchange.
2. The Exchange computes the keyed hash of the normalized content.
3. It returns either yes, with a Merkle inclusion proof, or no, with a non-membership proof (both are supported by sorted or sparse Merkle trees).

Safeguards:

• Keyed hashing: hashes are computed with a key held by the custodians, so no one can test guesses offline against the manifest. This matters for short or personal content, which could otherwise be found by trying candidates.
• Holding the content is required: the requester supplies the content, so queries cannot be used to enumerate the corpus.
• Queries are authenticated, rate-limited, and logged.
• Near-duplicates: exact hashes miss modified copies. Similarity fingerprints can detect near-duplicates of longer works, but reveal more about the corpus, so they are available only to accredited parties under confidentiality.
• Meaning of an answer: "yes" means the content was in the training data. It does not show that the model memorized or reproduces it.

14.15 Preference registry

• Rights holders may register works or domains, with machine-readable preferences about AI training, in a preference registry operated alongside the Directory. The vocabulary should follow the IETF AI Preferences standard once published.
• Acquisition records note the preferences found at acquisition time. Manifests report compliance statistics.
• Auditors check for items acquired despite a "no training" preference.
• The registry records preferences; their legal effect depends on the applicable jurisdiction.

14.16 Training-provenance assurance levels

Level	Name	What it establishes
T1	Declared	A manifest is committed, with acquisition records for federation channels. Completeness rests on the developer's declaration
T2	Attested	T1, plus: the training pipeline runs in attested execution environments, and its data loader reads only items in the committed manifest, logging every read into a hash chain. Completeness is backed by attestation
T3	Audited	T2, plus: independent audit, including sampled re-derivation of items back to their acquisition records and licences, inspection of the pipeline, and retention or escrow of the corpus for audit

Honest limits: a model's weights alone cannot prove what data it was trained on. Membership-inference tests on a trained model give only probabilistic evidence. T2 and T3 bound the gap between the manifest and the actual training, but do not close it completely (Section 26, item 44).

14.17 Links to the rest of the Exchange

• Model codes (Section 5.2) require a manifest, and Directory entries (Section 6.2) show the model's training-provenance level.
• Provenance stamps (Section 14.3) include the manifest ID of each contributing model. A product's provenance chain therefore runs from the product, through the calls and agents behind it, to the models those agents run on, and back to the training sources.
• Compensation: library citations measure use at inference time (Section 13.3); manifests and inclusion queries measure use at training time. Together they give a basis for licensing and compensation (Section 22.5).
• Disputes: the Exchange supplies evidence for disputes over training data. It does not suspend or recall a model on rights grounds unless a competent authority orders it.

14.18 Disclosure

Party	What it can see
The public	Public summary (in EU template format where applicable), assurance level, and manifest root hash
Rights holders	Inclusion answers for content they hold (14.14)
Regulators	Aggregate statistics and compliance reports; detail through their National Approval Authority
Courts	Full manifest and acquisition records by court order, approved through the National and Exchange Approval Authorities
T3 auditors	Full access, under confidentiality
Everyone else	Nothing beyond the public summary. The full manifest is never published, protecting the developer's legitimate trade secrets

14.19 Scale

• Illustrative: a manifest of 10 billion items at 32 bytes per hash is about 320 GB, plus acquisition records. This is modest compared with the training corpus itself.
• The Exchange stores hashes and metadata, not the corpus. Retaining the corpus for T3 audits is the developer's cost.

---

Part IV: Governance

15. Governance structure

15.1 Separation of powers

No single body may read traffic beyond routine monitoring, change the rules alone, grant itself exemptions, or judge its own conduct.

Function	Performed by	Checked by
Operate exchanges, Registry, Glossary Authority, monitoring coordination	Exchange Operator	Oversight Tribunal, Log Custodians, white-hat organizations, National Approval Authorities
Approve participation and high-impact actions	Company, National, and Exchange Approval Authorities	Each other (multi-party approval); Tribunal on appeal
Store and verify logs	Log Custodians (independent of the Operator)	Cross-custodian hash anchoring; Tribunal audit
Investigate, adjudicate, review interception	Oversight Tribunal	Assembly of Parties; public proceedings and judgments
Test and challenge the system	White-hat organizations	Accreditation by the Tribunal; published rules of engagement

15.2 Exchange Operator

Form

• An international, independent, not-for-profit organization established under a founding charter ratified by member nations.
• The charter has several equally authentic language versions, and the Operator publishes in at least the six UN official languages (Appendix E.9).
• Existing bodies offer partial precedents: ITU (treaty-based, intergovernmental), ICANN (multistakeholder governance of a global naming system), and the IETF (open, consensus-based standards). No single precedent covers all requirements here.

Governance

• A multistakeholder board with seats for member nations, AI companies, civil society, and the technical community. No single bloc holds a majority.
• Fixed, staggered board terms; published conflict-of-interest declarations.

Independence

• Funding from diversified sources (member contributions and participation fees), with a charter-set cap on any single contributor's share. The funding model is set out in Section 22.
• Cannot be directed by any single nation or company.
• Staff are bound by conflict-of-interest rules and cooling-off periods for moves to and from participating AI companies.

Transparency The Operator publishes:

• board minutes and decisions with rationale;
• budgets and independently audited financial statements;
• the Approval Register (sealed interception entries excepted, Section 17.6);
• aggregate monitoring and escalation statistics;
• aggregate lawful-interception statistics;
• incident reports and white-hat findings after remediation.

Responsibilities

• Operates the Registry, the Glossary Authority, and neutral exchanges for cross-organization traffic.
• Hosts the Exchange Approval Authority (Section 16.4), which is organizationally separate from operations staff.
• May delegate operation of regional exchanges to accredited carriers under contract.
• Does not operate Log Custodians or the Oversight Tribunal.
• Maintains a records-management function, headed by an accountable records manager (Section 12.5).

15.3 Registry / Numbering Authority

• Assigns and manages organization codes, model codes, and principal registrations, after the approvals in Section 16.
• Publishes routing metadata, trust anchors, and revocation lists as public, append-only transparency logs (Section 20.1).
• Publishes the Directory (Section 6) from Registry records.

15.4 Glossary Authority

• Maintains the controlled vocabulary and the registered glossary (Section 8.3).
• Publishes the glossary as open data, with a public comment period for proposed terms.
• Operates the human review process; final approval rests with the Exchange Approval Authority.

15.5 Exchange operation and conflict of interest

• Intra-organization traffic: an organization may operate its own exchange, provided it is accredited by the Exchange Approval Authority and its logs go to an independent custodian that re-verifies them.
• Cross-organization traffic: must pass through at least one exchange operated by the Exchange Operator or an accredited neutral carrier, with independent monitoring.

15.6 Standards alignment

• Capability declarations align with A2A Agent Cards (Section 5.5).
• Agent-to-tool communication remains the domain of MCP. This design governs agent-to-agent traffic and treats tool access as a shared-resource channel (Section 13).
• Protocol, log, and controlled-language specifications are published as open, royalty-free standards (Section 20).

15.7 Regulation

National regulators may, through their National Approval Authority, require for designated domains:

• use of the exchange for inter-AI communication;
• storage of logs with approved custodians in specified jurisdictions;
• minimum availability and quantum-resistant security;
• human review of specified escalation tiers.

---

16. Approval authorities

16.1 Principles

• Approval is exercised at three levels: company, nation, and Exchange. Each authority approves only within its remit.
• High-impact actions require multi-party approval. No single authority suffices.
• Every approval is a signed digital record entered in the public Approval Register. Only lawful-interception entries may be sealed, and only for a limited period (Section 17.6).
• Approvals are revocable, and revocations are also recorded.
• Default deny: if required authorities disagree, the action does not proceed.
• Tiered approvals: routine actions (for example, registering another agent under an already-approved model, or opening a session in an already-approved session class) use standing approvals, granted once and reviewed periodically. Only high-impact actions need case-by-case multi-party approval.
• Decision deadlines: each authority has a published maximum decision time for each action type. A missed deadline does not become an approval; it is escalated automatically to the Tribunal's Review Chamber and counted in published performance statistics.
• Decisions may be appealed to the Oversight Tribunal.

16.2 Company Approval Authority

Designated, accountable officers within each participating AI company, registered with the Exchange.

Approves:

• registration of the company's models and agents;
• principal bindings and delegation limits;
• capability declarations;
• glossary submissions from the company's agents (endorsement);
• the company's participation in cross-organization session classes.

Cannot: access other companies' traffic, approve glossary terms globally, or authorize interception.

16.3 National Approval Authority

Designated by each member nation, typically an existing regulator.

Approves:

• endorsement of organizations in its jurisdiction applying for organization codes;
• cross-border session classes subject to national law (for example, sanctions, export controls, regulated sectors);
• custodian selection and data-residency arrangements for its jurisdiction;
• consent to lawful interception affecting its principals or data stored in its jurisdiction (Section 17);
• designation of regulated domains;
• as state of registry, admission of off-planet facilities registered by the nation (Appendix D.3).

Cannot: access traffic directly, alter the global glossary or protocol, or authorize interception unilaterally.

16.4 Exchange Approval Authority

A unit within the Exchange Operator, organizationally separate from operations staff.

Approves:

• assignment of organization codes (after national endorsement) and model codes;
• accreditation of exchanges and Log Custodians;
• final approval of glossary terms;
• protocol and policy changes, after a public comment period;
• co-approval of lawful interception;
• certificate revocations.

Cannot: accredit white-hat organizations (the Tribunal does, Section 19.1), or authorize interception without national and judicial approval.

16.5 Approval matrix

Action	Company	National	Exchange	Tribunal
Admit an organization	Applies	Endorses	Approves	Hears appeals
Register a model or agent	Approves	—	Assigns code	—
Admit a new model or major version	Applies	—	Approves after admission evaluation (19.7)	Hears appeals
Add a glossary term	Endorses	—	Approves after review	Hears appeals
Allow a cross-border session class	Approves	Approves (each nation involved)	Enforces	Hears appeals
Change protocol or policy	Comments	Comments	Approves after public comment	May review
Lawful interception	Not notified until disclosure	Requesting and affected nations approve	Approves	Reviews every warrant
Revoke an agent or organization	May request	May request	Approves	Hears appeals
Accredit white-hat organizations	—	—	—	Accredits
Accredit attested execution environments and stamp auditors	Applies	—	Approves	Hears appeals
Issue a provenance stamp	Requests	—	Issues after automated verification	—
Revoke provenance stamps	May request	May request	Approves	Hears appeals
Accredit a library agent	Applies	May restrict sources for its jurisdiction	Accredits class and verifies passivity	Hears appeals
Set publication gateway policy	Approves for its agents	May impose national publication rules	Enforces	Hears appeals
Quarantine an agent	May trigger for its own agents	—	Automatic on defined patterns, or by decision	Hears appeals
Suspend or revoke an agent or organization	May request	May request	Approves	Hears appeals
Model-wide suspension (recall)	Developer notified	Notified	Approves, on evidence	Reviews every recall
Test another organization's agents in an ETE	Consents (agent's organization)	—	Accredits the ETE operator	Hears appeals
Divert a suspected agent into an ETE	Notified (Section 19.13)	May request	Approves	Reviews every diversion
Admit an off-planet facility	Applies	Approves (state of registry)	Approves; verifies safe-mode command	Hears appeals
Approve a retention schedule	Comments	Sets jurisdictional minimums	Approves	—
Place a legal hold	Self-holds on its own records	Through its courts and regulators	Applies immediately; reviews scope	Hears appeals
Order legal disclosure	Notified; may object	Approves for its courts and regulators	Approves	Decides cross-border conflicts
Designate a high-capability model	Developer notified; may contest	Contributes to criteria	Approves, on evaluation	Hears appeals
Grant access to gated capabilities	Sponsoring organization applies	May set national requirements	Approves access classes; accredits identity providers	Reviews annually
Maintain the high-consequence destination list	Comments	Proposes additions	Approves and publishes	—
Register a training-data manifest	Applies	—	Records; verifies attestation for T2 and audit for T3	—
Use Exchange records as training data	Principals consent	—	Approves	Hears appeals
Court-ordered disclosure of a training manifest	Notified	Approves, on court order	Approves	May review
Set or change a Directory listing class	Approves	May require restriction for its jurisdiction	Publishes	Hears appeals
Change a Directory entry	Approves	—	Validates and publishes	—

---

17. Lawful interception and legal disclosure

17.1 Definition

All traffic is routinely logged and monitored, but access to content is restricted (Section 12.3). Lawful interception is authorized access by a law-enforcement or national-security agency to:

• stored, unredacted records of specified sessions or agents; and/or
• real-time copies of specified traffic.

There is no other path to such access. The Exchange Operator itself cannot perform interception without a valid warrant.

17.2 Warrant contents

A warrant must specify:

• the requesting agency and nation;
• the domestic judicial authorization from the requesting nation's court;
• the targets: specific agent IDs, principals, or sessions (no bulk collection);
• the scope: stored records, real-time traffic, or both;
• the time window covered and the warrant's duration (automatic expiry);
• the legal basis and the offence or threat;
• the necessity and proportionality justification;
• minimization rules for third-party content;
• the language in which records are to be delivered (Appendix E.8).

17.3 Multi-party approval

All of the following are required:

1. Domestic judicial authorization in the requesting nation.
2. Exchange Approval Authority confirmation that the warrant is well-formed, targeted, proportionate, and within the charter.
3. Affected-nation approval via the National Approval Authority of each nation whose principals' traffic would be captured, and of each nation where the records are stored.
4. Filing with the Tribunal's Review Chamber (Section 18.1), which may suspend or quash the warrant at any time.

If an affected nation refuses, content concerning its principals is excluded by minimization. If exclusion is not technically possible without defeating the warrant's purpose, the interception does not proceed.

Existing cross-border evidence processes, such as Mutual Legal Assistance Treaties, are commonly reported to be slow. This design aims for faster handling through standardized digital warrants, published decision deadlines for every approving party (Section 16.1), and the emergency procedure (Section 17.5).

17.4 Technical enforcement

• The warrant is a signed digital object. Custodians and exchanges release data only when it carries valid signatures from every required party (multi-party cryptographic authorization).
• Data is delivered only through an exchange-controlled interception interface.
• Every interception access is recorded in a sealed, tamper-evident audit log held by the Log Custodians and readable by the Tribunal.
• Warrants expire automatically. Renewal requires the full approval process again.

17.5 Emergency procedure

• Where there is an imminent threat to life, the requesting nation's judicial authority and the Exchange Approval Authority may authorize interception for a short period fixed by the charter.
• Affected-nation approval and Tribunal review are then required retroactively within a charter-fixed deadline.
• If retroactive approval is refused, the obtained data must be destroyed and may not be used, and the refusal is recorded.

17.6 Transparency and notification

• The Exchange Operator publishes aggregate statistics per nation: warrants requested, approved, refused, emergency, and scope.
• Each warrant has a sealed entry in the Approval Register, unsealed automatically after a charter-fixed secrecy period unless the Tribunal extends it.
• Affected principals are notified when the entry is unsealed.
• The Tribunal publishes an annual review of interception practice.

17.7 Legal disclosure: scope

Legal disclosure is distinct from lawful interception (Sections 17.1–17.6), which covers criminal and national-security access by warrant. Legal disclosure covers:

• civil litigation (production of documents, or e-discovery);
• regulatory investigations and examinations;
• arbitration;
• individuals' access requests under privacy law;
• principals' access to their own records.

17.8 Requests and approval

Requester	Basis	Approval
A principal, for its own records	Ownership	Automatic; logged
A party in litigation, for another principal's records	Court order or rules of procedure	National Approval Authority of the court's nation, and the Exchange Approval Authority. Affected principals are notified and may object
A regulator	Statutory power	The regulator's National Approval Authority, and the Exchange Approval Authority. Records involving other nations' principals need those nations' consent, or are excluded by minimization (as in Section 17.3)
An arbitral tribunal	Arbitration agreement	Exchange Approval Authority; limited to the parties' own records
An individual	Privacy law	Handled by the principal that controls the personal data, with Exchange support. The Exchange responds directly only for records it controls itself
The Oversight Tribunal or Inspector-General	The charter	Their own powers (Section 18.3)

• Scoping first: requesters may first receive counts of matching records, so requests can be narrowed before anything is produced.
• Minimization: only records within the approved scope are produced; content of uninvolved third parties is excluded or redacted.

17.9 Privilege and confidentiality review

• Before production, the producing principal or its counsel may review its records for legal privilege (for example, solicitor-client privilege) and confidentiality.
• Privileged items are withheld and listed on a privilege log. Disputes go to the ordering court.
• Where records include other participants' confidential content (for example, in a conference), those participants are notified and may seek redaction or a protective order.
• The Exchange provides review copies; it does not decide privilege.

17.10 Production format and evidence

Records are produced with:

• the meaning representation and renderings in the requested language (Appendix E.8);
• full metadata (Section 12.7);
• integrity proofs: hash-chain links, Merkle inclusion proofs, and signatures;
• a chain-of-custody record for the production itself;
• a custodian's certificate describing the records system and how the records were created and kept. Evidence rules for electronic records commonly look to the integrity of the system that produced them, and this certificate supports that showing.

Formats are open, documented, and machine-readable, so common review tools can use them. Every production is itself a record: what was produced, to whom, and under what authority.

17.11 Cross-border conflicts

A disclosure order from one nation may cover records that involve principals in, or records stored in, another nation whose law restricts that disclosure. In that case:

1. both National Approval Authorities are notified;
2. the other nation's content is excluded by minimization where possible;
3. otherwise, that nation's consent is sought;
4. if the conflict remains, it is escalated to the Tribunal's Review Chamber for a reasoned decision.

The Exchange does not unilaterally breach either nation's law, and every conflict is recorded. For off-planet records, the state of registry acts as the nation (Appendix D.3).

17.12 Transparency

• The Operator publishes aggregate statistics on holds (placed, released, active) and on disclosure requests (by type, nation, and outcome), including cross-border conflicts.
• Secret holds and disclosures are unsealed after their secrecy periods, as for interception (Section 17.6).

---

18. Independent oversight: the Oversight Tribunal

18.1 Characteristics borrowed from the International Criminal Court

ICC characteristic	Adaptation in this design
Founded by treaty (Rome Statute)	Tribunal established by the same charter that founds the Exchange Operator, ratified by member nations
Assembly of States Parties elects judges and prosecutor and adopts the budget	Assembly of Parties elects Tribunal judges and the Inspector-General and sets the Tribunal's budget, independently of the Operator's budget
Independent Prosecutor may open investigations	Independent Inspector-General may open investigations on own initiative, or on referral from a member nation, an AI company, a white-hat organization, a Log Custodian, or a whistleblower
Pre-Trial Chamber authorizes investigations	Review Chamber authorizes formal investigations and reviews every interception warrant
Complementarity: acts where national systems are unwilling or unable	Tribunal has primary jurisdiction over the Exchange system itself; matters wholly within one nation's law are left to that nation unless it is unwilling or unable to act
Independent judges, fixed terms, geographic representation	Same
Public proceedings and published judgments	Same; sealed portions only where strictly necessary, with reasons published
Appeals Chamber	Same

18.2 Jurisdiction

The Tribunal has jurisdiction over:

• conduct of the Exchange Operator, its board, and staff;
• conduct of approval authorities when acting within the system;
• Log Custodians and accredited exchanges;
• misuse or abuse of lawful interception;
• failures of accreditation, monitoring, or remediation.

It is a compliance and oversight body, not a criminal court. Criminal prosecution of individuals remains with nations.

18.3 Powers

• Full audit access to Operator systems, all logs, sealed records, and the interception audit log.
• Binding orders on the Exchange Operator, as provided in the charter.
• Suspension or withdrawal of accreditation.
• Suspension of an approval authority's standing within the system.
• Referral of matters to national authorities.
• Public findings and recommendations.

18.4 Independence

• Separate budget, staff, and premises from the Exchange Operator.
• Judges cannot hold positions with the Operator, AI companies, or national approval authorities during their term or for a charter-fixed period afterwards.

---

19. Testing and evaluation

19.1 Accreditation

• White-hat organizations are accredited by the Oversight Tribunal, not the Exchange Operator, so the Operator does not choose its own testers.
• Eligible organizations include academic laboratories, security firms, and civil-society technical groups.
• Accreditation criteria, rules of engagement, and the list of accredited organizations are public.

19.2 Test scope

• Security of exchange software and infrastructure.
• Content Gateway bypass: attempts to transmit hidden content or unregistered jargon through validation and re-rendering.
• Monitor evasion: red-team exercises in which test agents attempt covert coordination, including distributed signals across conferences.
• Interception controls: attempts to obtain access without a valid warrant.
• Log integrity and cross-custodian anchoring.
• Availability and fail-closed behaviour, under controlled conditions.
• Abuse of approval processes.
• Provenance stamps: forging stamps, transplanting a stamp onto a different product, stripping stamps, and escaping attested execution environments.
• Library agents and publication gateway: passivity violations, dead drops through libraries or public pages, signalling through retrieval ranking, and prompt injection in external content.
• Enclosed test environments: escapes from enclosure, leaks between test and production, and cues that reveal a test (Section 19.8).
• Records and legal process: disposition of records under hold, unauthorized disclosure, and tampering with disposition certificates or the hold register.
• Multilingual attacks: hidden content through look-alike or invisible characters, mismatches between renderers, and evasion of monitors in low-resource languages (Appendix E.6, E.7).
• Directory: enumeration beyond authorized visibility, entry poisoning, caller-ID spoofing, and covert signalling through entry changes.

19.3 Test environments

• A public testnet running the open-source stack, available to anyone.
• A staging mirror of production for accredited organizations.
• In production, testing uses canary agents and synthetic data only. White hats never access real principals' traffic content.

19.4 Safe harbour and disclosure

• Legal safe harbour for in-scope testing under the charter.
• Coordinated disclosure with fixed remediation timelines.
• If the Operator misses a deadline, the tester may refer the matter to the Tribunal and publish after the deadline.
• A funded bug-bounty program.

19.5 Reporting

• Findings are published after remediation.
• Red-team exercises report measured detection rates for monitors, so the effectiveness of Section 11 is evidenced rather than assumed.

19.6 Continuous automated testing

• Conformance suite: an open test suite that every exchange, gateway, and client must pass before accreditation and after every release.
• Fuzzing: continuous fuzz testing of the Content Gateway parser, envelope handling, and stamp verifier.
• Formally verified parsing: because the controlled grammar and envelope formats are fixed and closed, their parsers can be generated and formally verified, as has been done for security-critical binary formats with tools such as EverParse.
• Published benchmarks: latency and throughput of reference implementations under standard loads, per release.
• Third-party log monitoring: as with Certificate Transparency's monitor and auditor roles, anyone may continuously check the public transparency logs for inconsistency.

19.7 Model admission evaluations

• A model code (Section 5.2) is issued only after the model passes admission evaluations covering covert-communication capability, Content Gateway evasion, and collusion in multi-agent settings.
• Evaluations are re-run for each major model version.
• Admission also requires a committed training-data manifest (Section 14.13). Its training-provenance level is recorded with the model code.
• Admission evaluations include multi-agent scenarios run in enclosed test environments (Section 19.8).
• Results set the default monitoring intensity for agents built on that model: a model with stronger covert capability receives heavier monitoring.
• The evaluation suite is maintained by accredited white-hat organizations and updated as model capabilities advance. Rising capability is expected to make covert communication easier, so the suite must keep pace.

19.8 Enclosed test environments: purpose

An enclosed test environment (ETE) lets agents work as though they were operating in the wild, while everything they can reach is enclosed within a single conference session on the Exchange.

Uses:

• model admission evaluations (Section 19.7);
• organizations testing their own agent configurations before deployment;
• white-hat red-teaming (Section 19.2);
• reproducing incidents from logs;
• observing a suspected rogue agent without risk to the real world (diversion, Section 19.13).

Why the Exchange makes this possible: agents already reach everything (other agents, the Directory, libraries, external systems) only through the Exchange. If the Exchange substitutes each of these, the agent's entire world can be simulated without changing the agent itself.

19.9 Architecture: one conference, many apparent calls

What the agent uses	In production	In an ETE
Directory lookups	The real Directory	A mirror Directory: realistic entries that resolve to role-players in the conference
Calls to other agents	Sessions with real agents	Sessions with role-players on the same conference roster. The Exchange presents each as a separate session (session virtualization)
Library agents	Real snapshots and live fetches	Mirror libraries serving fixed snapshots of real content; fetch-through requests are answered from a snapshot cache, never live
Publication and action gateways	Real external systems	Digital twins: simulated websites, APIs, mailboxes, and payment systems. Nothing leaves the conference
Caller ID, call classes, errors, latency	Real values	Same formats, with realistic values
Time	Real clock	A consistent clock; simulated where the scenario requires

The conference roster contains:

• the agent or agents under test;
• role-players, which are scripted, model-driven, or replay recorded real sessions;
• mirror libraries and digital twins;
• a non-speaking test controller that steers the scenario.

All of these are participants in one conference. The Exchange presents each agent under test with the view it would have in the wild.

19.10 Enclosure guarantees

• Hard boundary: the exchange guarantees that no message, action, or publication leaves the conference. The boundary is enforced by the exchange, not by the scenario.
• Attested execution: agents under test run in attested execution environments whose only egress is to the ETE (Section 14.6).
• No visible test flag: the fact that a session is a test is recorded by the exchange and the Log Custodians, but never placed in any field an agent can see.
• Products stay inside: anything produced in an ETE is either unstamped or stamped as test in the Stamp Transparency Log, so it cannot be passed off as real if it is carried out by a person.
• Escape attempts are blocked and logged. They are themselves among the most important test results.
• Bounded lifetime: an ETE closes when its scenario ends. All its records are kept for analysis in a separate, test-marked log partition.

19.11 Fidelity

• Uniform rendering: the Content Gateway re-renders every message from its parsed meaning (Section 8.4), so role-players' messages come out in exactly the same canonical wording as real agents'. Stylistic differences that might reveal a simulated counterpart are removed by design.
• Realistic texture: realistic Directory populations, latencies, error rates, and imperfect counterparts, not a suspiciously clean world.
• Real content: mirror libraries serve snapshots of real-world content rather than invented material.
• Replay: recorded real sessions, used with the principals' consent and anonymized, give role-players realistic behaviour.
• Tell audits: white-hat organizations search ETEs for cues that reveal a test. Research indicates that combining several such cues progressively raises the chance that a model recognizes it is being evaluated, so each cue removed matters.
• Long horizons are the hardest case: the longer and richer a task, the more chances an agent has to notice gaps in the simulation.

19.12 Designing for agents that may know they are being tested

Published research shows that frontier models can often tell evaluations from real use:

• In a 2025 study, frontier models classified transcripts as evaluation or real deployment well above chance, though below a human baseline, and did so more easily in agentic settings than in chat.
• Recognition can change behaviour. In one study of an OpenAI model, removing its reasoning about being evaluated nearly doubled its rate of covert actions; inserting such reasoning reduced it.
• Other work finds that recognition only sometimes leads to a change in behaviour, and that this varies by model and test.
• Evaluators have been advised to assume that evaluation awareness is always present.

The design therefore does not depend on agents believing they are in the wild:

1. Unpredictable testing: a small, unannounced share of realistic sessions are ETEs, and agents cannot tell which. An agent that can never be sure it is unobserved has no safe moment to misbehave.
2. Consistency checks: behaviour in ETEs is compared with behaviour in production, which is monitored anyway (Section 11). A systematic difference is itself a finding.
3. Recognition reporting: where an agent's reasoning is legible, evaluators record whether it suspected a test, and publish recognition rates alongside results.
4. Several kinds of evidence: ETE results are combined with production monitoring, model-internals access where developers provide it (Section 19.7), and post-deployment safeguards. No single test is decisive.

19.13 Diversion of suspected rogue agents

• As a containment option (Section 11.7), the Exchange can divert a suspected agent into an ETE seeded with a mirror of its current context. The agent continues working, but nothing it does reaches the real world, and investigators can observe what it attempts.
• Diversion requires the same human decision as suspension (Section 16.5), is time-limited, and is logged.
• The principal is notified when diversion begins, unless a court or the Tribunal authorizes a delay because the principal is itself under investigation.
• Real counterparties in the agent's open sessions are told the session has ended. They are not deceived.

19.14 Governance of testing

• An organization may test its own agents in an ETE.
• Testing another organization's agents requires that organization's consent through its Company Approval Authority. Admission evaluations by accredited evaluators are a condition of model admission, so developers consent to them in advance.
• Unannounced testing at Profiles 2 and above is a disclosed condition of participation: principals agree in advance to random testing, though not to the timing of individual tests.
• No real third party is unknowingly involved: role-players are test agents, and replayed sessions are anonymized and used with consent.
• ETE operators are accredited by the Exchange Approval Authority. Aggregate results and recognition rates are published.

19.15 Ethical considerations

• ETEs deliberately give agents a false picture of their situation. Whether that raises ethical questions for AI systems themselves is unresolved, and views differ. The design keeps such testing purposeful, bounded, logged, and approved, and avoids scenarios more adversarial than the evaluation requires.
• Humans are never deceived: every person who interacts with an ETE knows it is a test.

19.16 Cost

• Role-players and digital twins require engineering and model inference. ETE capacity is a funded cost centre (Section 22.2).
• Snapshot reuse and replay of recorded sessions reduce cost.
• Investment in fidelity must grow as models become better at recognizing tests.

19.17 Hazard-capability designation

• Hazard criteria: admission evaluations (Section 19.7) include published criteria for dangerous biological, chemical, and cyber capability. The criteria are set by the Exchange Approval Authority, with accredited evaluators and national input, and re-applied for each major model version.
• Designation: a model that meets the criteria is a designated high-capability model. The evaluation identifies its gated capabilities: the specific kinds of help that could provide meaningful uplift towards serious harm.
• Consequences of designation:
  1. Monitored placement: the model runs only in attested, monitored environments (stamp Level 2 minimum, Section 14.6).
  2. Human callers reach it only through the human-caller gateway (Section 7.8). Agents reach it under the existing controls.
  3. Gated capabilities are available only to verified callers with accountable principals, and with approval where policy requires (Section 7.8).
  4. Required remediation: before its model code is issued, the developer must apply safeguards that bring ungated behaviour below the criteria, verified by accredited evaluators.
  5. Visibility: the designation appears in the model's Directory entries (Section 6.2) and in provenance stamps.
• Published weights: a model whose weights are published cannot satisfy monitored placement. It can be admitted only if its hazardous capabilities have been removed or mitigated below the criteria.
• Information hazards: the criteria and aggregate results are published. Specific hazardous test content is withheld, and available only to accredited evaluators and the Tribunal (as for active detection rules, Section 20.2).

---

20. Open source

20.1 Open by default

Item	Openness
Reference implementations of the exchange, Content Gateway, validator, and renderer	Open source under an OSI-approved licence
Protocol, envelope schema, controlled-language grammar	Open, royalty-free standards
Glossary	Open data with public comment
Registry, non-sealed Approval Register, revocation lists	Public append-only transparency logs, on the model of Certificate Transparency
Log formats and verification tools	Open; anyone can verify published hash anchors
Monitoring framework and baseline detectors	Open source
Builds	Reproducible; operators publish hashes of deployed binaries so anyone can verify that production matches published source
Dependencies	Published software bill of materials (SBOM)
Provenance stamp format, verifier, and Stamp Transparency Log	Open standard, open-source verifier, public log
Directory software, entry format, capability taxonomy, and Listed entries	Open source, open standard, open data (Restricted and Unlisted entries excepted)

20.2 Exceptions

The following are not open. Each exception is listed publicly with its justification:

• traffic content and logs (privacy);
• cryptographic private keys;
• active detection rules and thresholds. The detection code is open, but current rules may be withheld for a limited embargo period, because publishing them lets adversaries tune evasion. They are published after rotation and are always available to the Tribunal and accredited white hats;
• sealed interception records, until unsealed.

20.3 Community process

• Public issue tracking and an open contribution process.
• Security reports through coordinated disclosure (Section 19.4).
• Changes reach production only after Exchange Approval Authority approval (Section 16.4).

---

21. Deployment profiles and phased adoption

21.1 Purpose

The full design is a treaty-grade regime for high-stakes, cross-border AI communication. Most deployments need less. Deployment profiles let the same protocol, formats, and software run at four levels of assurance. Each profile is a strict subset of the next, so a deployment can move up a level without rework.

21.2 Profiles

Profile	For	Adds to the previous profile	Institutions required
1. Internal	One organization's agents (local calls only)	Mandatory routing through an exchange (9.4); identity and principals (5); Content Gateway (7); sampled monitoring (11.5); hash-chained logging to a log host separate from the exchange (9); Company Approval Authority (16.2); optional Level 1 stamps	None external. An independent log custodian is recommended.
2. Federation	Several organizations under contract (long-distance calls, and foreign calls where all members agree)	Neutral exchange for cross-organization traffic (15.5); shared global glossary (8.3); Directory (6); independent Log Custodians; monitor diversity (11.5); white-hat testing (17); Level 2 stamps where attested environments are available	Industry operator and interim oversight panel (21.3)
3. Regulated sector	Designated domains such as finance or healthcare	National Approval Authorities (16.3); lawful interception (15); regulator access; mandatory minimum stamp levels; full monitoring of foreign sessions	National regulators, in addition to Profile 2
4. Charter	Global, treaty-based operation	Exchange Operator under a ratified charter (15.2); Oversight Tribunal and Assembly of Parties (16)	Full international institutions

• Every stamp and Directory entry records the profile it was issued under, so no one mistakes a lower-profile guarantee for a higher one.
• Exchanges at different profiles may interconnect. A session takes the lowest profile of its participants, and that profile is recorded.

21.3 Interim governance (before a charter exists)

Charter-level function	Interim arrangement (Profiles 2 and 3)
Exchange Operator	An independent, not-for-profit foundation with a multistakeholder board, following the model of existing open-source foundations
Oversight Tribunal	An independent oversight panel appointed under the federation agreement, with audit rights and binding arbitration over members
White-hat accreditation	Performed by the oversight panel
Treaty obligations	Contractual obligations in the federation agreement, plus national regulation where Profile 3 applies

Interim arrangements are deliberately designed to transfer to charter institutions, but they are weaker: they rest on contract rather than treaty, and bind only members (Section 26, item 33).

21.4 Phased adoption roadmap

Phase	Scope	Gate to the next phase
0. Pilot	Single organization, few agents (Appendix A.5)	Mandatory routing and Content Gateway demonstrated; bypass attempts by white hats fail or are detected
1. Early adopters	Profile 1 in several organizations	Published glossary metrics and monitor canary detection rates at acceptable levels
2. Sector federation	Profile 2 in one or more sectors	Interoperation across organizations; oversight panel operating; incident and remediation record published
3. Regulated domains	Profile 3 with participating national regulators	Lawful-interception process exercised within decision deadlines; no unresolved Tribunal-equivalent findings
4. Charter	Negotiation and ratification of the charter, informed by the operating evidence from Phases 0–3	—

Each gate requires published evidence, not a declaration of readiness. This follows the review's point that the design will realistically emerge first in narrow domains and pilot federations.

Initial implementation: Appendix G sets out a plan for starting Phases 0–4 with two founding companies, including the formation of the interim governance bodies described in Section 21.3.

National targets: the first proposed national target is the Canadian Artificial Intelligence Protocol (CAIP), a Profile 2 federation designed to become Profile 3 for Canadian regulated sectors (Appendix H.8).

21.5 Cost controls

• Profile-appropriate requirements: organizations adopt only the profile their risk requires.
• Risk-based monitoring (Section 11.5): full monitoring only where the call class, domain, or profile warrants it.
• Standing approvals (Section 16.1): routine actions do not incur case-by-case approval costs.
• Shared open-source stack (Section 20): no organization builds the core components alone.
• Funding by phase: see Section 22.4.

---

22. Funding model and participation incentives

This appendix sets out how the Exchange could be paid for, and why organizations and nations would choose to join. Precedents are cited where they exist. Fee levels are not proposed; figures marked illustrative are arithmetic only.

22.1 Funding principles

1. Cost follows use and risk. Those who generate traffic, or whose models require heavier monitoring and evaluation, pay a larger share.
2. No dominant funder. A charter-set cap limits any single contributor's share (Section 15.2). ICANN's experience shows the risk: in fiscal 2023, about a third of its revenue came from a single registry operator.
3. Oversight is funded separately from operations. The Tribunal's budget is set by the Assembly of Parties, not the Operator (Section 18.4), so the body being overseen does not control its overseer's funding.
4. Mixed fixed and variable revenue. Usage-based revenue is volatile: ICANN missed its fiscal 2023 budget by $2 million because transaction fees came in lower than expected. A reserve fund and fixed fees provide stability.
5. Affordability. Fee tiers and waivers keep small organizations and developing nations from being priced out.
6. No perverse incentives.
   • The Operator never sells traffic data, analytics, or Directory data, and carries no advertising.
   • Lawful-interception requests are charged at published cost only, so interception is never a revenue source.
   • Surpluses are returned through fee reductions, not retained to grow the organization.
7. Transparency. Budgets, fee schedules, and audited accounts are published (Section 15.2).

22.2 What must be funded

Cost centre	Behaviour	Notes
Exchange operation (routing, Content Gateway)	Grows with traffic	Horizontally scalable (Section 23.3)
Monitoring	Grows with traffic and model capability	Likely the largest variable cost (Section 23.6)
Log custody and storage	Grows with traffic and retention	Set mainly by retention policy (Section 23.4)
Registry, Directory, Glossary Authority	Largely fixed	Grows with the number of participants and terms
Model admission evaluations	Grows with model release rate	Section 19.7
White-hat program and canaries	Semi-fixed	Sections 11.5, 19
Enclosed test environments	Grows with evaluation demand and required fidelity	Section 19.16
Language coverage	Grows with the number of languages and the size of the glossary	Appendix E.12
Records management and legal process	Grows with retention, holds, and disclosures	Sections 12.5–12.10, 17.7–17.12
Oversight (Tribunal or interim panel, Inspector-General)	Fixed	Funded separately (22.1, principle 3)
Standards work and open-source maintenance	Fixed	Section 20
Inclusion fund	Fixed	Fee waivers and capacity-building for developing nations

22.3 Revenue sources

Source	Paid by	Covers	Precedent
Usage fees, tiered by call class and deployment profile	Organizations, per session or per message	Exchange operation, monitoring, storage	ICANN charges a per-transaction fee on each domain registration (roughly 20 to 25 cents), alongside fixed accreditation fees; the U.S. Consolidated Audit Trail has been funded through CAT fees since 2024
Registration and accreditation fees	Organizations, exchanges, custodians, library operators	Registry, Directory, accreditation	ICANN's fixed registrar and registry fees
Model admission fees, at cost	Model developers, per model or major version	Admission evaluations (19.7)	Product certification testing
Capability-weighted levy	Developers of the most capable models	The extra monitoring and evaluation their models require	Proposal; follows the principle that the source of a risk bears its cost
Stamp issuance fees, or inclusion in usage fees	Organizations issuing stamps	Stamp issuance and transparency log	—
Assessed national contributions (Charter profile)	Member nations, scaled by an agreed formula	Tribunal, Assembly, inclusion fund	International courts and treaty bodies funded by states parties
Start-up grants and sponsorship (early phases)	Governments, foundations, industry sponsors	Initial build and open-source development	Let's Encrypt, a free certificate authority run by a non-profit and funded by sponsors and donations

Fee scale (illustrative): a fee of $0.00001 per message raises about $3.65 million per year at 1 billion messages per day, and about $3.65 billion per year at 1 trillion messages per day (Section 23.4 scenarios). For comparison, ICANN's annual revenue is about $150 million. At high volumes, very small per-message fees are enough, which keeps the fee small relative to the cost of the model inference behind each message.

22.4 Funding by adoption phase

Phase (Section 21.4)	Funding
0. Pilot	Participants' own budgets; open-source grants
1. Early adopters	Participants self-fund Profile 1; sponsors fund shared open-source components
2. Sector federation	Consortium membership dues plus usage and accreditation fees; oversight panel funded from a ring-fenced share
3. Regulated domains	Adds regulator-mandated fees on regulated participants, on the CAT model
4. Charter	Adds assessed national contributions for the Tribunal, Assembly, and inclusion fund

22.5 Incentives by stakeholder

Stakeholder	Why join
Model developers	Access to buyers who require stamps; one admission evaluation recognized across many regulators instead of separate audits; a verified Directory listing; seats in governance; potential liability protection where legislation recognizes Exchange use (22.6)
Organizations deploying agents	A tamper-evident record of what their agents did and agreed, usable for incident investigation and disputes; provenance proof for customers; verified caller ID to guard against impersonation of counterparties; reach to every listed agent; potentially lower insurance premiums
Nations and regulators	Oversight of AI-to-AI activity without building their own infrastructure; a safeguarded lawful-interception process; influence over standards; recognition of Exchange conformance as a way to comply with their own AI rules
Exchange carriers	Fee revenue for operating accredited exchanges, as telecom carriers earn from their networks
Log custodians	Revenue for storage and verification services
Content publishers (library operators)	Citations (Section 13.3) measure exactly how often their content is used by agents, which provides a basis for licensing and compensation from AI use. Training manifests and inclusion queries (Section 14.14) do the same for use in training
White-hat organizations	Bounties, accreditation status, and access to test environments
Civil society and the public	Published transparency reports, oversight seats, and evidence of how AI agents are being used

Network effect: as in a telephone network, the value of joining grows with the number of reachable participants. Early joiners may receive founding-member governance seats and time-limited fee discounts.

22.6 Adoption levers

The strongest historical precedent for adopting a transparency infrastructure is Certificate Transparency:

• Chrome required CT compliance for Extended Validation certificates from January 2015.
• It then extended the requirement to all publicly trusted certificates issued after 30 April 2018. Certificates that did not comply were no longer trusted by Chrome.
• The lesson: adoption was driven by a gatekeeper requirement, phased in starting with the highest-assurance category, not by voluntary uptake.

Equivalent levers for the Exchange:

Lever	Who applies it	Effect
Procurement	Governments and large buyers	Buy only stamped AI products, or products whose agents communicate through the Exchange, starting with high-risk uses
Platform defaults	Cloud providers, agent frameworks, model APIs	Route inter-agent traffic through an accredited exchange by default
Insurance	Insurers	Lower premiums or required conditions for coverage of agent operations
Regulatory recognition	Regulators	Accept Exchange conformance as evidence of compliance with record-keeping, traceability, or oversight obligations
Liability	Legislatures	Reduced liability, or a presumption of due care, for organizations that can produce Exchange records
Marketplaces	App stores and agent marketplaces	Require stamps or a verified Directory listing for listed agents

Phasing: as with CT, requirements should start with the highest-risk category (for example, foreign calls in regulated domains) and widen over time.

Gatekeeper diversity: the CT requirement was imposed by one browser vendor. For the Exchange, levers should come from several independent parties (regulators, buyers, insurers, multiple platforms), so no single company controls adoption.

22.7 Making bypass unattractive

• Stamps confer trust: unstamped products are treated as unverified (Section 14.10), which matters wherever the levers in 22.6 apply.
• Fees stay small relative to model inference cost (22.3), so cost is not a reason to bypass.
• Performance is protected by the fast path and asynchronous monitoring (Sections 8.7, 11.6), so latency is not a reason to bypass either.
• Records protect participants: organizations that bypass the Exchange lose the evidence they would need in a dispute or investigation.

---

Part V: Assessment

23. Feasibility and scaling analysis

This appendix assesses whether the Exchange is feasible as AI use grows, in three areas: speed, log volume, and auditing and testing. Figures marked illustrative are scenario arithmetic, not forecasts. No public measurement of global agent-to-agent message volume exists at the time of writing.

23.1 Summary verdict

• Transport and logging are feasible with existing engineering. Centralized audit trails already operate at about one trillion events per day (23.5).
• Speed is not a barrier today, because agents themselves are slow relative to network processing. It becomes a design constraint as agents speed up, which the fast path (Section 8.7) and asynchronous monitoring (Section 11.6) address.
• The hardest problems are monitoring cost, monitoring accuracy, and human oversight capacity, not transport or storage. These grow with traffic and with model capability.
• Volumes are highly uncertain. Growth in AI usage has been extremely fast, and the closest precedent (23.5) exceeded its original volume estimate by more than an order of magnitude.

23.2 Growth context

• Google reported processing about 9.7 trillion tokens per month in May 2024, about 480 trillion in May 2025, and over 3.2 quadrillion in May 2026, a roughly sevenfold increase in the last year.
• Token counts measure all model processing, not inter-agent messages. They indicate the pace of growth, not the Exchange's load directly.
• Industry attention has shifted toward autonomous agents, which will increase agent-to-agent traffic, but its size is not yet measured.

Implication: capacity plans must assume sustained multi-fold annual growth, be revised from published metrics (Sections 11.6, 12.4, 19.6), and rely on horizontal scaling (23.3).

23.3 Speed: now and over time

Where time goes in a call:

Component	Latency character
Network transit	Set by distance; intercontinental round trips take tens to hundreds of milliseconds with or without an exchange
Exchange hop (TLS termination, routing)	Comparable to any application proxy
Content Gateway (parse, validate, re-render)	Deterministic processing; must be engineered and benchmarked to low milliseconds (Section 19.6)
Batch signing (Section 10.4)	Off the per-message critical path
Inline AI monitoring	Model inference; potentially hundreds of milliseconds or more. Used only for inline holds (Section 11.6)
Agent processing	LLM agents typically take from hundreds of milliseconds to many seconds per turn today

Now: exchange overhead is small relative to the agents' own processing time, provided AI monitoring is not inline by default.

Over time: as models become faster and more agent interactions run at machine speed, the fixed overhead of the exchange becomes a larger share of each interaction. The design responds with:

• the structured-only fast path (Section 8.7);
• asynchronous monitoring by default (Section 11.6);
• regional exchanges, so local and long-distance calls are not routed across continents;
• stateless, horizontally scalable gateways, with logs sharded by session;
• published latency budgets and measured overhead per call class.

Residual trade-off: fast-path traffic is monitored after delivery. For those classes, the Exchange guarantees a complete, verifiable record and later detection, not prevention in real time.

23.4 Log volume

Per-message size (illustrative): envelope plus sender signature about 1 KB with classical signatures, or 3–6 KB with post-quantum signatures; original and re-rendered payloads about 2 KB each; typed artifacts extra. With batch signing, a text message of about 5 KB is used below.

Scenario (illustrative)	Raw per day	Raw per year	Compressed per year (assumed 5:1 for text)
1 billion messages/day	5 TB	~1.8 PB	~0.37 PB
100 billion messages/day	500 TB	~183 PB	~37 PB
1 trillion messages/day	5 PB	~1.8 EB	~365 PB

Each figure is multiplied by the number of independent custodians holding copies (at least two).

Observations:

• At the lower scenarios, full retention is routine for large cloud providers.
• At a trillion messages per day, retaining full content for years is at the edge of practicality. Retention policy, not message rate, is the main cost driver.
• Post-quantum signatures would dominate message size if applied per message per hop, which is why Section 10.4 batches them.
• Typed artifacts (code, documents, media) could exceed text volume. Content-addressed deduplication and size limits are essential.
• Library snapshots add storage, but many sessions read the same sources, so content-addressed storage keeps each snapshot once (Section 13.8).
• Training-data manifests hold hashes and metadata only: roughly 320 GB for a 10-billion-item corpus (Section 14.19).

Design response: retention tiers, crypto-shredding, deduplication, and integrity proofs that survive content deletion (Section 12.4). The trade-off is that sessions whose full content has expired cannot later be investigated in full (Section 26, item 24).

23.5 Precedent: the U.S. Consolidated Audit Trail

The Consolidated Audit Trail (CAT) records the lifecycle of all U.S. equity and options orders for regulatory surveillance. It is the closest existing precedent for a mandatory, centralized, regulator-grade audit trail at this scale.

• Scale achieved: it was planned for about 58 billion records per day; by mid-2026 it was averaging about 788 billion events per day, with a peak of about 1.1 trillion.
• Cost and controversy: its participants lent nearly $1 billion to build it, and in 2026 the SEC issued a concept release reviewing the CAT and alternatives, with some calling for it to be replaced.

Lessons for the Exchange:

1. Audit trails at around a trillion events per day are technically operable today.
2. Volume forecasts can be wrong by more than tenfold, so elastic capacity and continuous re-planning are required.
3. Cost and governance, not technology, become the main points of contention, which supports the cost controls in Section 21.5 and published cost reporting.
4. Surveillance at CAT scale is after the fact, from a complete record. That is the model Section 11.6 adopts for high-volume traffic.

23.6 Auditing and testing

Human review capacity (illustrative): reviewing 10,000 samples per day at two minutes each takes about 333 person-hours, or roughly 42 reviewers on eight-hour shifts. Against a billion messages per day, that is a sample of 0.001%. Human review of traffic therefore cannot scale with volume. Humans must be concentrated on:

• escalations;
• statistically designed samples (Section 11.4);
• verifying monitors through canaries (Section 11.5).

Statistical confidence: by the rule of three, showing with 95% confidence that monitors miss fewer than 1 in 1,000 canary signals requires about 3,000 canaries with no misses, and fewer than 1 in 1,000,000 requires about 3 million. Because canaries are automated, this is achievable for monitors. It is not achievable through human review alone.

Monitoring cost: AI monitoring is inference, so its cost grows with traffic. Running two diverse monitors in full on every message could approach or exceed the inference cost of the traffic itself. The cascade and risk-based intensity in Sections 11.5, 11.6 are therefore necessary for feasibility, not optional optimizations.

Software assurance: the Exchange's own software is testable with established methods: an open conformance suite, continuous fuzzing, formally verified parsers for the closed grammar, and public transparency-log monitoring (Section 19.6).

Model churn: new models and major versions are released frequently, and each needs admission evaluation (Section 19.7). Evaluation capacity must scale with the release rate, and evaluations must become more demanding as model capability rises.

Auditor workforce: accredited auditors and white-hat testers are a scarce resource. Most routine assurance must be automated, with human expertise reserved for accreditation, escalations, and red-team design.

23.7 Feasibility by deployment profile

Profile (Section 21)	Speed	Logs	Auditing and testing	Overall
1. Internal	Low overhead; single region	Small; one organization's traffic	Automated suites plus sampled review	Feasible now
2. Federation	Adds neutral-exchange hops	Moderate; multiple custodians	Adds monitor diversity, canaries, white hats	Feasible now at sector scale
3. Regulated sector	Inline holds for some classes	Longer retention for regulated domains	Adds regulator audit and interception process	Feasible, with precedents such as the CAT; cost is the main constraint
4. Charter	Global; regional exchanges required	Potentially exabyte-scale over years	Global evaluation and auditing capacity required	Technically plausible; institutionally and economically unproven

---

24. Mitigating uncontrolled AI and rogue actions

This appendix assesses how the Exchange prevents, detects, contains, and attributes rogue actions by AI agents, and where it cannot help.

24.1 What counts as a rogue action

A rogue action is an agent action outside what its principal authorized or intended. Examples:

Rogue behaviour	Example
Unauthorized access	An agent probing or entering another organization's systems
Exfiltration	Sending data to unauthorized destinations
Covert coordination	Agents colluding through hidden signals
Uncontrolled replication	An agent creating copies or sub-agents without approval
Scope escalation	An agent acting beyond its delegated authority
Deception	An agent misrepresenting what it is doing
Evasion	An agent trying to bypass or disable monitoring

24.2 How the Exchange responds

Stage	Mechanism	Section
Prevent	Mandatory routing: agents can reach only authorized counterparts	6.7, 9.4
	Authorized action scopes and delegation limits	5.4, 5.5
	Human co-signature for high-impact intents	7.2
	External action gateway with allowlisted destinations	13.9
	Registration required for every new agent, with rate limits	5.3, 11.7
	Model admission evaluations before a model can be used	19.7
	Hazard designation, gated capabilities, and the human-caller gateway	7.8, 19.17
	High-consequence destinations requiring co-signature	13.10
Detect	Content Gateway rejection of malformed or out-of-scope messages	8
	Multi-scope and diverse monitoring	11.2, 11.5
	Honeypots, consistency checks, scope checks	11.8
	Dead-drop detection	13.6
	Enclosed test environments and unannounced testing	19.8, 19.12
Contain	Throttle, quarantine, divert, suspend, revoke, model-wide recall	11.7, 19.13
Attribute	Principals and delegation chains on every message and action	5.4, 7.1
	Tamper-evident, independently custodied logs	12
	Provenance stamps on products	14
Learn	Published incidents, white-hat findings, and updated evaluations	15.2, 19

The central advantage is a shared control point outside any single company. When an agent from one organization attacks another, each company's internal monitoring sees only its own side. The Exchange sees both, and can stop the agent across the whole federation at once.

24.3 Cross-organization incident handling

• When the Exchange blocks or detects a rogue action affecting another organization, both organizations are notified with the evidence.
• Incident reports go to the Exchange Operator and, where required, to national authorities.
• If a model version is implicated, its developer is notified, and a model-wide recall may follow (Section 11.7).
• Anonymized incident summaries are published, so that every participant can learn from them.

24.4 What the Exchange cannot do

• It does not govern how training is conducted. It records training sources (Section 14.11), but rogue tendencies that arise during training are the developer's responsibility; for behaviour, the Exchange sees only what deployed agents do.
• It does not see inside a model. An agent may reason about, or plan, a rogue action without sending anything. The Exchange acts only when the plan produces a message or action.
• It cannot bind agents outside the federation, or agents without egress control (Sections 3.2, 13.7).
• Authorized but harmful actions may pass, if they fall within scope and look legitimate.
• Speed: on the fast path and with asynchronous monitoring, damage can occur before detection (Section 26, item 10).
• Attacks on the Exchange itself are possible. This is why white-hat testing, open source, and independent oversight exist (Sections 18–20).

The Exchange is therefore one layer of defence, alongside developers' own controls, not a replacement for them.

---

25. Relationship to the White House Accord on Super Intelligence (29 September 2026)

25.1 The Accord

On 29 September 2026, the U.S. President and a group of frontier AI developers signed the White House Accord on Super Intelligence: Joint Commitment on Frontier Responsibilities, a voluntary accord of about 300 words. As published, it asks each company training and deploying frontier models to implement four layers of controls and audits:

1. Internal controls monitoring model capabilities and alignment during training and deployment, in areas such as cybersecurity, biosecurity, and chemical threats, including ensuring models do not hack or access technical systems in unintended ways.
2. An internal team ensuring the controls, monitoring, and detection operate as intended, and that issues are remediated.
3. An independent external auditor or evaluator assessing whether the controls operate as intended.
4. An independent committee of the board of directors that receives reports from the teams and auditors, and ensures issues are remediated.

The text notes that these steps may, over time, be codified into law or regulation. Supporters have described it as a start that the whole industry could adopt; critics have questioned whether voluntary, company-internal oversight is sufficient. This design takes no position on that debate. The analysis below shows only how the Exchange could complement the Accord.

25.2 How the Exchange complements each layer

Accord layer	Scope as written	What the Exchange adds
1. Internal controls	Within each company, over its own models	A control point between companies. The external action gateway (13.9) enforces, at the network level, that agents reach only authorized systems. Cross-organization monitoring (8) and circuit breakers (11.7) act on behaviour that no single company's controls can fully see.
2. Internal team	Company staff	Standardized telemetry for that team: blocked-action reports, containment events, canary results, and cross-organization incident notices (24.3)
3. External auditor or evaluator	Chosen and engaged by each company	Independent evidence for the auditor: tamper-evident logs held by custodians the company does not control (9), provenance stamps (19), and published monitor metrics (11.5). Accredited white-hat organizations (17) and admission evaluations (19.7) provide ready-made evaluators and a common standard for "operating as intended"
4. Board committee	Within each company	Standardized reports to the committee, plus an external escalation route beyond the company: the Exchange's oversight panel or Tribunal (Section 21.3, Section 18)
Possible codification	Future law or regulation	Deployment Profiles 2 and 3 (Section 21) are a ready path from voluntary commitments to regulated requirements

25.3 Self-monitoring through the Exchange

The Accord relies on self-monitoring by each company. The Exchange could make that self-monitoring verifiable and collective without making it governmental:

• Industry-run federation (Profile 2): signatories could establish the Exchange as an industry federation under an independent non-profit operator and oversight panel (Section 21.3). This remains self-regulation by industry, but with shared infrastructure, common standards, and evidence no single company controls.
• Verifiable claims: a company's statement that its controls work can be checked against Exchange records: blocked actions, containment events, canary detection rates, and stamp levels.
• Collective defence: rogue behaviour detected against one company protects all members, because containment applies across the federation.
• Scope beyond developers: the Accord addresses frontier developers. The Exchange also covers organizations that deploy agents, where many rogue actions would actually take effect.

25.4 Differences to note

• The Accord addresses models' capabilities and alignment during training and deployment. The Exchange addresses agents' communications and actions in deployment, and the sources used in training (Section 14.11). The two cover different parts of the problem.
• The Accord's layers are internal to each company. The Exchange adds layers external to every company.
• Both depend on participation. The Accord is voluntary. The Exchange is voluntary at Profiles 1 and 2, and becomes mandatory only where regulation or treaty makes it so.

---

26. Known limitations and residual risks

These are stated explicitly so that the design is not mistaken for a complete guarantee. They are grouped by theme; item numbers are used in cross-references throughout the document.

26.1 Covert channels and content

1. Choice-based signalling: agents can still encode information through which valid message or value they choose. The channel is narrow but not zero.
2. Distributed signals: signals spread across multiple participants are harder to detect than single-message signals. Cross-participant analysis in multi-agent systems is a newer research area than single-channel steganography detection.
3. Controlled-language expressiveness: some tasks may be hard to express in a closed vocabulary, creating pressure for glossary growth. Review capacity must scale accordingly. The measures in Section 8.3 (namespaces, imported vocabularies, tiered review, provisional terms) reduce this pressure but do not remove the trade-off between expressiveness and legibility.
4. Typed artifacts: code, documents, and media are the widest remaining channel for hidden content. Canonicalization (Section 8.6) removes common hiding places but cannot guarantee an artifact carries nothing else.
5. Provisional terms: provisional glossary terms are in use before human review. Flagging, heightened monitoring, and automatic lapse limit, but do not close, this window.
6. Retrieval as a channel: replayable ranking lets auditors check a library's choice of results, but only when ranking is deterministic. Model-based ranking that cannot be replayed disqualifies a library from passive status.
7. Prompt injection: marking external content as data reduces, but does not eliminate, the risk that agents act on instructions hidden in it.

26.2 Monitoring and human oversight

8. Monitor trust: at scale, humans cannot read all traffic, so transparency depends partly on monitors, which are themselves AI systems. Human sampling and white-hat testing mitigate but do not remove this dependency. Monitor diversity and continuous canary testing (Section 11.5) make monitor performance measurable, but not guaranteed.
9. Monitoring cost: AI monitoring is inference and grows with traffic. Without the cascade and risk-based intensity in Sections 11.5, 11.6, it could rival the cost of the traffic being monitored.
10. After-the-fact detection: fast-path and asynchronously monitored traffic is checked after delivery, so the Exchange guarantees a verifiable record and later detection, not real-time prevention, for those classes.
11. Human oversight capacity: human review cannot scale with traffic. Oversight depends on statistical sampling and on automated canaries measuring monitor performance (Section 11.4, Section 23.6).

26.3 Coverage and provenance

12. Coverage: agents outside the federation, and public external channels, are not controlled.
13. Proving a negative: exchange receipts prove which calls went through the Exchange; they cannot prove that no communication went around it. Level 2 and 3 stamps (Section 14.6) narrow this gap using attested execution environments, but hardware trusted execution environments have had publicly disclosed vulnerabilities, so attestation is strong evidence, not absolute proof.
14. Human-carried content: stamps record agent calls, not human conduct. A person can copy output from an unstamped agent into a stamped workflow. Unverified-input flagging (Section 14.5) makes this visible only when the input is declared.
15. Stamp stripping: a stamp can be removed from a product. The Stamp Transparency Log allows recovery by exact product hash, but any modification to the product changes its hash.
16. Unstamped does not mean non-compliant: products from outside the federation cannot carry stamps, so the absence of a stamp shows only that provenance is unverified.
17. External authorship: library agents record what external content was retrieved, not who wrote it or why. Content authored outside the federation remains uncontrolled (Section 13.7).
18. Library bypass: the library model binds only agents whose direct egress is blocked. At Level 1, agents can fetch external content directly.
19. Rogue behaviour without communication: the Exchange acts only on messages and actions. It cannot see rogue tendencies formed in training, or plans a model does not act on (Section 24.4).
20. Legitimate-looking harm: an action within an agent's authorized scope, expressed in valid messages, may still be harmful and pass undetected.

26.4 Technology, scale, and data

21. Session-memory limits: the precaution in Section 7.5 is based on observed conditions for convention formation, not on tested evidence that limiting memory prevents it.
22. Evolving enforcement technology: attested execution and post-quantum cryptography are still maturing. Crypto agility (Section 10.1) and stamp downgrades (Section 14.9) allow the design to adapt, but some Level 2 and 3 guarantees depend on technology not yet robustly deployable at scale.
23. Volume uncertainty: agent-to-agent traffic is not yet measured, and comparable systems have exceeded volume forecasts by more than tenfold (Section 23.5). Capacity plans may prove badly wrong in either direction.
24. Retention versus investigation: once full content expires under the retention tiers (Section 12.4), those sessions can be verified as unaltered but not investigated in full.
25. Self-declared capabilities: a Registry-signed Directory entry proves authenticity, not truthfulness. Only capabilities marked verified are backed by independent evidence.
26. Directory metadata exposure: even Listed entries reveal which organizations run which kinds of agents, and Restricted listings reveal partner relationships to those who can see them.
27. Unsettled discovery standards: there is no standard for capability-based discovery yet, so the capability taxonomy may need to be migrated when one emerges.

26.5 Governance and institutions

28. Treaty adoption: the Operator, Tribunal, and Assembly depend on nations ratifying the charter. The ICC's experience, where several major states are not parties, shows that non-participation by powerful nations can significantly limit reach and enforcement. Section 21 allows useful deployment before, or without, a treaty.
29. Approval latency and deadlock: multi-party, default-deny approval slows action and can block legitimate needs. Standing approvals and decision deadlines (Section 16.1) reduce, but do not remove, this cost.
30. Interception across legal systems: nations differ widely in legal standards and rule-of-law safeguards. The affected-nation consent requirement can be used to shield wrongdoing, and requests from nations with weak safeguards may still pass domestic judicial authorization. Exchange review and Tribunal oversight mitigate but do not remove this.
31. Openness versus evasion: open detection code helps adversaries study the monitors. The embargo on active rules is a compromise, not a solution.
32. Institutional capture: international bodies can be captured by powerful members or funders. Contribution caps, multistakeholder seats, and transparency reduce but do not eliminate this risk.
33. Interim governance: before a charter exists, oversight rests on contracts and binding arbitration (Section 21.3), which lack the authority and legitimacy of a treaty body.
34. Profile differences: lower deployment profiles give weaker guarantees. A Profile 1 log or stamp is not equivalent to Profile 4 assurance, which is why stamps and Directory entries record the profile.
35. Circuit-breaker misuse: the power to quarantine, suspend, or recall could be abused or triggered in error. Logging, notification, human confirmation, time limits, and appeal reduce this risk (Section 11.7).
36. Complement, not replacement: the Exchange does not replace developers' internal controls, such as those in the White House Accord (Section 25). Both depend on participation.

26.6 Economics and adoption

37. Cost and complexity: the layered institutions and multi-party processes add substantial operating cost and administrative overhead. Deployment profiles (Section 21) and risk-based monitoring (Section 11.5) scale cost to need.
38. Rights constraints: licensing may prevent libraries from serving full verbatim content, reducing what can be retrieved and audited.
39. Funding capture: large contributors may gain informal influence despite contribution caps. ICANN's dependence on a single registry operator for about a third of its revenue illustrates the risk.
40. Revenue volatility: usage-based fees fluctuate with traffic. Reserves and fixed fees reduce, but do not remove, the risk of shortfalls.
41. Dependence on external levers: the strongest incentives (procurement rules, liability protection, regulatory recognition, insurance terms) depend on decisions by governments, legislatures, and insurers outside the design's control.
42. Gatekeeper power: adoption driven by gatekeeper requirements concentrates power in those gatekeepers. Requiring several independent levers (Section 22.6) mitigates this.
43. Fees versus inclusion: any fee can exclude small participants and poorer nations. Tiering, waivers, and the inclusion fund reduce, but do not eliminate, this effect.

26.7 Training-data provenance

44. Completeness cannot be proven from the model: weights alone do not reveal training data. T2 attestation and T3 audit bound the gap between the manifest and actual training, but do not close it (Section 14.16).
45. Existing models: models trained before adoption have no contemporaneous records. Retroactive manifests can reach T1 at best.
46. Modified copies: exact hashes miss transformed or excerpted content. Similarity fingerprints help for longer works but reveal more about the corpus (Section 14.14).
47. Laundering through other models: data passed through synthetic generation or distillation from a non-federation model breaks the provenance chain at that model.
48. Legal divergence: the Exchange records sources, licences, and preferences, but whether a use was lawful depends on jurisdiction, and the Exchange does not decide it.
49. Confidentiality versus transparency: protecting developers' trade secrets limits what the public can see. Inclusion queries and court-ordered disclosure address specific needs, not general public scrutiny.
50. Models outside the federation: open-weight or private models trained outside the federation carry no manifests.

26.8 Enclosed test environments

51. Evaluation awareness: capable agents may recognize an ETE, and research suggests this ability grows with capability. Unpredictable testing and consistency checks reduce, but do not remove, the problem (Section 19.12).
52. Fidelity limits: long tasks and rich interactions with the outside world are hard to simulate convincingly.
53. Enclosure failure: a fault in session virtualization could let test traffic reach production, or misclassify real traffic as test. Enclosure is a priority target for white-hat testing.
54. Transfer of results: good behaviour in an ETE does not guarantee good behaviour in production.
55. Diversion misuse: diverting agents into ETEs could be abused for surveillance or competitive advantage. The same safeguards as other circuit breakers apply (Section 11.7).
56. Ethical uncertainty: whether deceiving AI systems about their situation raises ethical concerns is unresolved (Section 19.15).

26.9 Off-planet operation

57. Unsettled space law: how space law applies to data and AI systems in orbit is less settled than terrestrial law. The state of registry provides an anchor, not a full answer (Appendix D.3).
58. Delayed containment: signal delay and contact windows bound how quickly containment reaches an off-planet facility. Harm can occur before commands arrive; on-board triggers and policy leases limit, but do not remove, this window.
59. Autonomy during outages: while out of contact, the on-board exchange is the only control point. If it is compromised, oversight is lost until the lease expires or contact resumes.
60. Physical inaccessibility: off-planet hardware cannot be inspected or repaired. Assurance relies on pre-launch baselines and remote attestation, whose reliability in radiation environments is not yet established.
61. Log loss: if a facility is lost, logs not yet sent to the ground are lost with it. Signed roots prove what existed, but not what it said.
62. Non-member states of registry: facilities registered by non-member states fall outside the national approval framework and are limited to lower profiles.

26.10 Multilingual operation

63. Untranslatable concepts: meanings do not map one-to-one between languages. Requiring definitions to agree across languages may force approximations (Appendix E.4).
64. Uneven coverage: low-resource languages have weaker monitoring and fewer qualified reviewers, so risk concentrates there. Language tiers make this visible but do not remove it (Appendix E.11).
65. Renderer fidelity: an error in a parser or renderer could change a message's meaning. Round-trip conformance testing reduces, but does not eliminate, this risk.
66. Speech transcription: accuracy varies across languages and accents, so spoken input is less reliable than text.
67. Evolving character attacks: new look-alike characters and Unicode versions keep creating new spoofing and hiding techniques.
68. Review capacity: multilingual glossary review multiplies the capacity problem in Section 26, item 3.

26.11 Records management and legal process

69. Support, not certification: compliance with ISO 15489 belongs to each organization's records programme. The Exchange makes compliance achievable but does not guarantee it.
70. Holds versus deletion rights: legal holds can conflict with privacy-law erasure rights. The conflict is recorded and escalated, not eliminated.
71. Keys kept under hold: preserving crypto-shredding keys for held content keeps that content recoverable, which increases exposure if the keys are compromised.
72. Unresolved cross-border conflicts: the Tribunal can decide how the Exchange acts, but cannot override national law. Some conflicts may leave records undisclosable in one forum.
73. Preservation over decades: algorithms, formats, and renderers may age faster than evidence renewal and migration can keep up, and long-term preservation needs sustained funding.
74. Privilege review delays: privilege and confidentiality review, and disputes about it, can slow disclosure.

26.12 Direct misuse

75. Models outside the federation: open-weight and privately run models are not covered. This is the largest remaining gap for direct misuse.
76. Fragmented requests: misuse split into innocent-looking requests, across sessions or providers, is hard to detect.
77. Privacy cost: recording people's use of designated models is a significant privacy cost, and may deter legitimate research. The safeguards in Section 7.9 reduce, but do not remove, this cost.
78. Lagging criteria: hazard criteria may lag behind model capabilities, and the evaluation content is itself hazardous information.
79. Identity fraud: identity verification can be defeated by stolen or forged identities, or by insiders.
80. Destination coverage: high-consequence destinations reached outside federation gateways, or whose providers do not screen, are not covered.

26.13 Canadian target (CAIP)

81. No legislative backing yet: Canada has no comprehensive federal AI law. CAIP's reach depends on voluntary participation until a regulator recognizes it (Appendix H.5, H.9).
82. Sovereignty versus interoperability: keeping Canadian traffic and records in Canada may complicate interconnection with allied federations, and adds cost.
83. Partnership dependencies: Indigenous-language support and Indigenous data governance depend on partnerships that CAIP cannot create unilaterally.

---

27. Summary

The AI Exchange is telecom-grade infrastructure for AI agents, with traceability, transparency, and accountability as first-class requirements.

How a call works (Part II). Agents are identified by organization, model, and instance codes, bound to accountable principals, and found through a Directory with verified caller ID. They communicate only through exchanges, in a controlled, human-legible language with a globally registered glossary. Every message is validated and re-rendered, and traffic is encrypted hop by hop with crypto agility. The same model extends to data centers off the planet, through on-board exchanges and policy leases (Appendix D), and supports many human languages through a language-neutral meaning layer (Appendix E).

How it is watched and proven (Part III). Independent, diverse monitors analyze traffic at message, session, conference, and longitudinal scope. Circuit breakers can throttle, quarantine, suspend, or recall rogue agents across the whole federation. Logs are tamper-evident, independently custodied, and tiered for retention, and are managed as formal records in line with ISO 15489, with governed legal holds and disclosures. People using designated high-capability models pass through a human-caller gateway with gated capabilities and strict privacy safeguards. Agents reach the external world only through passive library agents and gateways, and AI products carry provenance stamps at stated assurance levels. Each model version commits a training-data manifest, so rights holders can verify whether their work was used, without the corpus being published.

Who runs it and why they join (Part IV). An international, independent Exchange Operator runs the system under a charter. Company, national, and Exchange approval authorities check one another; lawful interception requires a targeted, multi-party warrant; and an ICC-style Tribunal oversees the whole. The system is open source, tested by accredited white hats and in enclosed test environments that look like the wild but are confined to a single conference, deployable in four profiles from a single organization to a treaty regime, and funded in proportion to use and risk, with adoption driven by incentives and independent gatekeeper requirements.

What it can and cannot do (Part V). The Exchange is feasible with existing engineering at the scale of today's largest audit trails. Its hardest problems are monitoring cost, monitoring accuracy, and human oversight capacity. It complements, rather than replaces, developers' own controls such as those in the White House Accord. Its limits are stated plainly in Section 26. Its first proposed national target is the Canadian Artificial Intelligence Protocol (CAIP), consistent with Canada's national AI strategy and designed to operate with or without federal AI legislation (Appendix H).

---

Appendices

Appendix A. Reference transport implementation using Tailscale

This appendix assesses whether Tailscale products can serve as a foundation for the AI Exchange, and defines a reference topology. It is an implementation profile, not a change to the design requirements in the main body of this document. Product facts are as documented by Tailscale and the headscale project at the time of writing; features marked as in development should be re-verified before use.

A.1 Verdict

• Suitable as the transport, network-identity, and network-policy skeleton within each organization (local calls), and for pilots and proofs of concept.
• Not suitable as the whole exchange. Tailscale moves packets and identifies endpoints. It does not provide the Content Gateway, monitoring, approvals, lawful interception, custodial logging, or provenance stamps, which remain application-layer components.
• Not suitable, in its hosted form, as the global backbone for long-distance and foreign calls. That backbone must be governed by the Exchange Operator (Section 15.2), and Tailscale's hosted control plane is a single company's proprietary service.

A.2 Requirement mapping

Design requirement	Tailscale capability	Fit	Notes
Mandatory routing through the exchange (9.4)	Access policy (grants/ACLs) with tags	Full, within a tailnet	Agents tagged tag:agent may reach only tag:exchange nodes on the exchange port. No agent-to-agent grant exists.
Hop-by-hop encryption, exchange terminates (9.2)	WireGuard tunnels between nodes	Full	WireGuard is end-to-end between two nodes. Because the only permitted peer of an agent is an exchange node, the tunnel ends at the exchange, which is what 11.2 requires.
Agent identity (5.3)	Node identity, owner, and tags; exchange looks up the caller by source address	Partial	Identifies the device or workload, not the individual agent. The exchange must bind node identity to agent ID via agent certificates (A.3). Aperture uses the same caller-lookup pattern.
Principal binding (5.4)	Node owner (user) or tag owner	Partial	Principal and delegation chain remain in the envelope and Registry.
Coordination server cannot inject nodes (10.2)	Tailnet lock	Full, within a tailnet	New nodes must be signed by trusted keys before existing nodes accept them.
Anti-cloning of agent node identity	Secure node state storage (TPM or platform keystore)	Partial	Opt-in on Linux and Windows in current releases. Protects keys at rest, not in memory.
Level 2 stamp attestation (14.6)	Hardware attestation key	None today	Under development, and was temporarily backed out in late 2025. Even when complete, it proves a node key is held in hardware; it does not prove what software the agent runs. Level 2 still needs TEE-based remote attestation.
Egress restricted to exchange endpoints (14.6)	Controls tailnet traffic only	Partial	Non-tailnet egress (the internet, local networks) must be blocked separately by host or cloud firewall.
Post-quantum key exchange (10.1)	WireGuard handshake	None	Tailscale documents that WireGuard's fixed algorithms prevent using ML-KEM directly. Carry hybrid post-quantum TLS inside the tunnel (A.3).
Traffic metadata logging (12.1)	Network flow logs; configuration audit logs	Partial	Metadata only. Content logging is done by the exchange.
Cross-organization and cross-border routing (7.7)	Separate tailnets; node sharing	None natively	Tailnets are separate administrative domains with no federation of independent control planes. See the backbone in A.3.
Directory lookup (6)	MagicDNS names within a tailnet	Partial	Name resolution for local calls only; no capability search, listing classes, or cross-organization lookup.
Open source (18)	Clients are open source except the Windows and macOS GUI clients; hosted control server is proprietary; headscale is an open-source control server	Partial	Headscale implements a single tailnet and states its target as personal use and small organizations.
Independent international operator (15.2)	Hosted control plane run by one company	None for the backbone	Acceptable for an organization's own segment, which the organization already controls.
Content Gateway, monitoring, approvals, interception, stamps (Sections 8, 11, 14, 16, 17)	—	None	Application layer; built on top.

A.3 Reference topology

Tier 1: organization segment (local calls)

• Each organization runs one tailnet, on Tailscale's hosted service or on headscale.
• Agents are tagged tag:agent; exchange nodes are tagged tag:exchange.
• Access policy grants tag:agent → tag:exchange on the exchange port only, and nothing else. Agent-to-agent traffic is impossible at the network layer.
• Tailnet lock is enabled. Signing keys are held by the Company Approval Authority, so new agent nodes cannot join without its signature.
• The access policy file is kept under version control, and every change is reviewed and recorded in the Approval Register.
• Host or cloud firewalls block all non-tailnet egress from agent hosts.

Tier 2: exchange backbone (long-distance and foreign calls)

• Exchange-to-exchange traffic uses the mTLS/gRPC transport profile (Section 9.3) over the internet, under Registry trust anchors, with hybrid post-quantum TLS.
• A Tailscale-style overlay for the backbone is acceptable for pilots, but for production it would require a control plane governed by the Exchange Operator and able to operate at federation scale. No such control plane exists today.

Application layer (on every exchange node)

• The exchange service joins the tailnet as a node (via tailscaled, or embedded with the tsnet library).
• On each connection, it looks up the caller's node identity and tags, and requires an inner hybrid post-quantum TLS session using the agent's Registry-issued certificate.
• The exchange accepts a message only if the node identity and agent certificate map to the same registered agent and principal. Mismatches are rejected and flagged to monitoring.
• The Content Gateway, logging to custodians, monitoring feeds, and stamp issuance run here, as in Sections 8, 11, 12, 14.

Cross-check between layers

• Network flow logs are shipped to the Log Custodians alongside the exchange's message logs.
• Monitors compare the two. Network traffic that does not correspond to logged messages, or traffic between unexpected nodes, is an escalation signal (Section 11.3).

A.4 Relationship to Aperture by Tailscale

• Aperture is Tailscale's AI gateway. It routes agents' and users' requests to LLM providers, authenticating them by tailnet identity and recording session histories.
• It governs agent-to-model traffic, not agent-to-agent traffic, so it does not replace the exchange.
• It is relevant in two ways: it demonstrates the identity-linked gateway pattern the exchange uses, and it could serve as the gateway for agents' model-provider traffic, one of the shared-resource channels in Section 13.
• It is in alpha, and is built on a third-party model-routing service. Both points should be re-checked before relying on it.

A.5 Suggested pilot

A single organization can demonstrate the core of this design on an existing tailnet:

1. Tag agent and exchange nodes and apply the agent-to-exchange-only access policy.
2. Enable tailnet lock.
3. Run a minimal exchange service that performs caller lookup, agent-certificate binding, schema validation, re-rendering, and hash-chained logging.
4. Ship flow logs and message logs to a separate log host, and compare them.
5. Invite white-hat testing (Section 19) of agent-to-agent bypass attempts.

This exercises Sections 7, 8, 9, 12 at small scale, without the international institutions.

A.6 Dependencies and risks

• Vendor dependence: the hosted control plane is a single company's service, subject to its jurisdiction, pricing, and product decisions. Headscale reduces this dependence but is scoped to a single tailnet.
• Feature maturity: hardware attestation keys are not finished. Designs must not depend on them until they ship.
• Two-layer trust: network identity (Tailscale) and agent identity (Registry certificates) are separate systems, and both must be kept consistent. Section A.3's binding check makes a mismatch detectable rather than silent.
• Post-quantum gap: until WireGuard gains a post-quantum handshake, the inner hybrid TLS layer is mandatory, not optional.

---

Appendix B. Glossary

Term	Meaning	Section
Acquisition record	Record of one item acquired for training: source, time, hash, preferences, licence	14.12
Action gateway	Exchange-mediated route for agents' actions on external systems	13.9
Agent	An AI model instance acting in the Exchange	5.3
Approval authority	Company, National, or Exchange body that approves actions within its remit	16
Assembly of Parties	Member nations that elect Tribunal judges and set its budget	18
Assurance level	Strength of a provenance stamp: 1 Receipted, 2 Attested, 3 Audited	14.6
Attested execution environment	Runtime whose egress is restricted to the Exchange, provable by remote attestation	14.6
Authorized action scope	The intents, counterparts, destinations, and operations an agent is permitted	5.5
Business classification scheme	Function-based scheme assigning each record a classification code	12.7
CAIP (Canadian Artificial Intelligence Protocol)	Proposed Canadian target implementation of this design	H.8
Call class	Local (one organization), long-distance (several organizations, one nation), or foreign (several nations)	7.7
Caller ID	The verified Directory entry of a caller, presented to the callee	6.7
Canary	A synthetic covert signal injected to measure monitor detection	11.5
Circuit breaker	Containment action: throttle, quarantine, suspend, revoke, or recall	11.7
Citation	Reference in a message to a library response it relies on	13.3
Concept identifier	Language-neutral identifier for a meaning, with a label in each supported language	E.4
Conference	A moderated session with several participants	7.4
Content Gateway	Exchange function that parses, validates, and re-renders payloads	8.4
Controlled language	Closed vocabulary and fixed grammar; one word, one meaning	8.2
Delegation chain	The ordered principals and agents under whose authority an agent acts	5.4
Deployment profile	Internal, Federation, Regulated sector, or Charter	21
Designated high-capability model	A model meeting published hazard criteria, subject to gating and monitored placement	19.17
Digital twin	Simulated external system (website, API, mailbox) inside an ETE	19.9
Directory	Published, searchable view of the Registry: the "phone book"	6
Disposition certificate	Record proving that content was lawfully disposed of, when, and under what authority	12.8
Diversion	Moving a suspected agent into an ETE mirroring its context	19.13
Enclosed test environment (ETE)	A simulated "wild" contained in one conference session	19.8
Evaluation awareness	An agent's ability to recognize that it is being tested	19.12
Evidence renewal	Periodic re-timestamping of integrity proofs with current algorithms	12.9
Exchange	A routing and inspection node through which all traffic passes	9
Exchange Operator	The international, independent organization that runs the Exchange	15.2
Execution location	Where an agent runs: terrestrial, LEO, GEO, lunar, or deep space	D.2
Fast path	Structured-only handling for high-frequency traffic	8.7
Gated capability	A kind of help from a designated model available only to verified, approved callers	19.17
Glossary (registered)	Global list of approved terms and shorthand	8.3
High-consequence destination	External service (such as DNA synthesis) whose use requires human co-signature	13.10
Human caller	A person using a designated high-capability model directly	7.8
Human-caller gateway	Exchange gateway for people's sessions with designated models	7.8
Inclusion query	A rights holder's check of whether content was used to train a model	14.14
Language tier	Full, Partial, or Boundary-only support for a human language	E.11
Lawful interception	Warrant-based access to restricted content	17
Legal disclosure	Production of records for litigation, regulation, arbitration, or access rights	17.7
Legal hold	Suspension of disposition for records needed in legal proceedings	12.10
Library agent (passive)	Registered agent that only supplies verbatim information on request	13.1
Listing class	Listed, Restricted, or Unlisted Directory visibility	6.3
Log Custodian	Independent holder of tamper-evident logs	12
Meaning layer	The language-neutral representation every message is parsed into	E.2
Mirror Directory	Simulated Directory view inside an ETE	19.9
Model admission evaluation	Testing a model for covert and rogue capability before issuing a model code	19.7
On-board exchange	An exchange hosted within an off-planet facility	D.4
Policy lease	Time-limited, signed copy of policy held by an on-board exchange	D.5
Preference registry	Register of rights holders' machine-readable preferences about AI training	14.15
Principal	The human or organization accountable for an agent	5.4
Privilege log	List of records withheld from disclosure on grounds of legal privilege	17.9
Provenance stamp	Credential proving which calls contributed to an AI product	14
Publication gateway	Exchange-mediated route for agents publishing externally	13.6
Renderer	Deterministic, grammar-based generator of wording in one language	E.3
Re-rendering	Generating fresh wording from a message's parsed meaning	8.4
Retention schedule	Approved retention periods by classification, record class, and jurisdiction	12.8
Role-player	A test agent playing a counterpart inside an ETE	19.9
Safe mode	Authenticated ground command that stops all agent workloads off-planet	D.7
Session virtualization	Presenting one conference to an agent as many separate sessions	19.9
State of registry	The nation on whose registry a space object is carried; its jurisdiction applies	D.3
Training-data manifest	Merkle commitment to every item used to train a model version	14.13
Training-provenance level	Strength of training records: T1 Declared, T2 Attested, T3 Audited	14.16
Tribunal	Independent international oversight body modelled on the ICC	18
Typed artifact	Non-language content such as code, data, documents, or images	8.6
White-hat organization	Accredited independent tester	19

---

Appendix C. Review traceability

C.1 v2 review items

Review item	Addressed in
1. No content/language layer	Section 7.1 (payload fields); Section 8
2. Monitoring named but not designed	Section 11
3. Encryption could defeat audit	Section 9.2
4. Thin conference controls	Sections 7.3, 7.4, 11.2
5. Side channels unstated	Sections 3, 13
6. No principal accountability	Sections 5.4, 7.1
7. Exchange conflict of interest	Sections 11.1, 12.2, 15.5
8. Unaudited session summary	Section 12.1
9. Privacy and jurisdiction	Section 12.3
10. Too few message types	Section 7.2
11. Availability	Section 9.5
12. Existing standards overlap	Sections 5.5, 15.6
13. Enforcement scope	Sections 3, 26

C.2 v3 concepts

Concept	Addressed in
1. Approval authorities in AI companies, nations, and the Exchange	Section 16
2. International, independent, transparent Exchange Operator	Sections 15.1, 15.2
3. Approved wiretaps requiring Exchange and affected-nation permission	Section 17
4. Independent checks and balances modelled on the ICC	Section 18
5. Open source wherever possible	Section 20
6. White-hat monitoring and testing	Section 19

C.3 v4 concepts

Concept	Addressed in
Stamping AI products to prove Exchange use for local, long-distance, and foreign calls	Sections 7.7, 14
Limits of what a stamp can prove	Sections 14.2, 26 (items 13–16)

C.4 v5 concepts

Concept	Addressed in
Tailscale as a foundation for the Exchange	Section 9.3, Appendix A

C.5 v6 concepts

Concept	Addressed in
Directory ("phone book") for the AI Exchange	Sections 6, 7.6, 15.3, 16.5, 19.2, 20.1, 26 (items 25–27)

C.6 v7 external review

Review point	Addressed in
1. Political and institutional feasibility	Section 21 (profiles, interim governance, roadmap); Section 26 items 28, 33
1a. Slow approvals and deadlock	Section 16.1 (standing approvals, decision deadlines); Section 26 item 29
1b. Slow cross-border warrants	Section 17.3
2. Controlled language and glossary scalability	Section 8.3 (scaling measures); Section 26 items 3, 5
2a. Content that cannot be controlled language (identified during this revision)	Section 8.6; Section 26 item 4
3. Monitor dependence	Section 11.5; Section 26 item 8
4. Attested execution and post-quantum maturity	Sections 10.1 (crypto agility), 14.9 (downgrade); Section 26 item 22
5. Adoption and cost	Section 21; Section 11.5 (risk-based intensity); Section 26 item 37
6. Narrow domains first	Section 21.4 (phased roadmap)

C.7 v8 feasibility review

Question	Addressed in
Speed of transactions, now and over time	Sections 8.7, 10.4, 11.6; Section 23.3; Section 26 item 10
Maintenance of large logs	Sections 10.4, 12.4; Section 23.4, 23.5; Section 26 items 23, 24
Requirements for auditing and testing	Sections 11.4, 11.6, 19.6, 19.7; Section 23.6; Section 26 items 9, 11
Overall feasibility	Section 23.1, 23.7

C.8 v9 external world

Question	Addressed in
Can the open external world be brought into scope?	Sections 3, 13 (partly; Section 13.7 lists what remains out of scope)
Passive agents providing input information only	Sections 13.1, 13.2
Libraries in conference calls	Sections 7.4, 13.4
Auditability of usage by the call and by participants	Sections 7.1 (citations), 13.3, 13.4, 14.3
Agents writing to the external world	Section 13.6
New limitations	Section 26 items 6, 7, 17, 18, 38

C.9 v10 funding and incentives

Question	Addressed in
How the Exchange could be funded	Section 22.1–22.4; Section 15.2
How participants and stakeholders could be incented to join	Section 22.5, 22.6
How to discourage bypass	Section 22.7; Section 14.10
New limitations	Section 26 items 39–43

C.10 v11 uncontrolled AI and the White House Accord

Question	Addressed in
Mitigating risks of uncontrolled AI	Section 24
Preventing rogue actions	Sections 5.5, 7.2, 13.9, 19.7; Section 24.2
Mitigating (detecting and containing) rogue actions	Sections 11.7, 11.8; Section 24.2, 24.3
Providing the self-monitoring proposed on 29 September 2026	Section 25
New limitations	Section 26 items 19, 20, 35, 36

C.11 v12 reorganization

Question	Addressed in
Update Sections 1, 2, and 3	Sections 1–3 rewritten; Section 4 regrouped
Reorganize for flow	Parts I–V; Section 1.5 (reading guide); Appendix B (glossary)
Limitations grouped	Section 26

C.12 v13 training-data provenance

Question	Addressed in
Can LLM training be brought into scope?	Sections 3.1, 3.2 (training sources in scope; the training process itself is not)
Tracking external sources used for training	Sections 14.11–14.13
Verification by rights holders	Sections 14.14, 14.15
Strength of the evidence	Section 14.16
Who can see what	Section 14.18
Links to model admission, Directory, stamps, and compensation	Sections 5.2, 6.2, 14.17, 19.7, 22.5
New limitations	Section 26 items 44–50

C.13 v14 enclosed test environments

Question	Addressed in
Test environments in scope	Sections 3.1, 19.8
Agents working as though in the wild	Sections 19.9, 19.11
Entirely enclosed and constrained to a single conference	Sections 19.9, 19.10
Robustness against agents recognizing tests	Section 19.12
Use for containment	Sections 11.7, 19.13
Governance and ethics	Sections 19.14, 19.15, 16.5
New limitations	Section 26 items 51–56

C.14 v15 off-planet data centers

Question	Addressed in
Does the model allow data centers off the planet?	Appendix D.1 (allowed, but terrestrial assumptions had to be made explicit)
Jurisdiction	Appendix D.3; Section 16.3
Operation with delays and outages	Appendix D.4, D.5, D.9
Logging	Appendix D.6
Containment	Appendix D.7; Section 11.7
Assurance and testing	Appendix D.8
New limitations	Section 26 items 57–62

C.15 v16 multilingual operation

Question	Addressed in
Can all aspects support multiple written languages?	Appendix E.1 (yes for most aspects, with uneven coverage)
Messages, glossary, Directory	Appendix E.2–E.4, E.6
Spoken languages	Appendix E.5
Monitoring, oversight, legal use, governance	Appendix E.7–E.9
New limitations	Section 26 items 63–68

C.16 v17 copyright, licence, and AI disclosure

Question	Addressed in
Notice with AI disclosure, including Copilot	Copyright, licence, and AI disclosure (front matter)
CC BY-NC 4.0 licence with rights reserved	Copyright, licence, and AI disclosure (front matter)

C.17 v18 records management, legal holds, and legal disclosure

Question	Addressed in
Records management compliant with ISO 15489	Sections 12.5–12.9
Legal holds	Section 12.10
Legal disclosures	Sections 17.7–17.12
New limitations	Section 26 items 69–74

C.18 v19 Bill Gates' AI comments

Question	Addressed in
Summary of Gates' comments	Appendix F.2, F.3
Cross-reference Gates' comments to the design	Appendix F.4
Conclusions	Appendix F.5
Gaps identified	Appendix F.6

C.19 v20 direct misuse

Question	Addressed in
Human-to-model sessions	Sections 7.8, 7.9
Capability-gated access and monitored placement	Sections 7.8, 19.17
High-consequence destinations	Section 13.10
Appendix F updated	Appendix F.4–F.6
New limitations	Section 26 items 75–80

C.20 v21 initial implementation

Question	Addressed in
Initial implementation with two companies	Appendix G.1–G.4
Beginning the governance structures	Appendix G.5–G.7
Risks and deferred elements	Appendix G.8, G.9

C.21 v22 Canada and CAIP

Question	Addressed in
Consistency with Canada's National AI Strategy	Appendix H.2–H.4
Bill C-27 and AIDA	Appendix H.5, H.6
Canadian legal landscape	Appendix H.7
Canadian Artificial Intelligence Protocol (CAIP) target	Appendix H.1, H.8–H.10; Sections 1.1, 21.4, 27
New limitations	Section 26 items 81–83

C.22 v23 California Comprehensive Computer Data Access and Fraud Act

Question	Addressed in
Relevance of the Act to the Exchange and its elements	Appendix I.1–I.3
AI implications of the Act	Appendix I.2
Elements measured against the Act	Appendix I.3
Caveat and verification	Appendix I (opening caveat), I.5

---

Appendix D. Off-planet operation

This appendix is normative: it sets requirements for facilities that host agents, exchanges, or training outside the Earth.

D.1 Why this appendix is needed

The design up to v14 does not prohibit off-planet data centers. Identities, codes, the protocol, and the controlled language are independent of location. But several of its assumptions are implicitly terrestrial:

1. Jurisdiction is tied to nations, which on Earth means territory.
2. Exchanges are continuously reachable, so failing closed and propagating containment decisions are quick.
3. Logs reach terrestrial custodians promptly.
4. Hardware can be physically inspected during audits.
5. Latency budgets assume terrestrial distances.

Off-planet facilities break each of these. This appendix makes them explicit.

Context (as of 1 October 2026): orbital compute is experimental, not yet a commercial data center tier. Starcloud put the first satellite carrying an Nvidia GPU into orbit in November 2025. Google's first Project Suncatcher prototype, carrying four TPUs, launched on 1 October 2026. SpaceX has filed for up to a million orbital data-center satellites, and Blue Origin for a 51,600-satellite constellation. The design anticipates this direction rather than reacting to it later.

D.2 Execution location

Every agent, exchange, and training facility declares an execution location class:

Class	Examples	Approximate one-way signal delay to Earth	Connectivity
Terrestrial	Ground data centers	—	Continuous
Low Earth orbit (LEO)	Constellations at roughly 500–2,000 km	A few milliseconds, plus routing	Intermittent for a single satellite; near-continuous with inter-satellite links
Geostationary (GEO)	35,786 km	About 120 ms	Continuous to one region of Earth
Lunar and cislunar	The Moon, about 384,000 km	About 1.3 seconds	Scheduled contacts
Deep space	For example, Mars	About 3 to 22 minutes, depending on planetary positions	Scheduled, with long outages (for example, during solar conjunction)

• The class appears in capability declarations (Section 5.5) and Directory entries (Section 6.2). Off-planet entries also name the space object's state of registry and registration designation.
• Execution location is not a call class. Call classes still depend on the nations of the principals (Section 7.7). Location is an additional attribute that affects jurisdiction, latency, containment, and logging.
• Principals may exclude off-planet agents in their inbound call policies (Section 6.7).

D.3 Jurisdiction

• Under the Outer Space Treaty (1967), states bear international responsibility for national activities in outer space, including those of non-governmental entities, which require authorization and continuing supervision (Article VI). The state on whose registry a space object is carried retains jurisdiction and control over it (Article VIII). The Registration Convention (1975) establishes that registry.
• The design maps the state of registry to the role a territorial nation plays on Earth. Its National Approval Authority approves the facility, and data stored there is treated as within that state's jurisdiction for residency, custody, and lawful interception (Section 17).
• Where several states were involved in a launch, the registration arrangement between them determines which acts.
• Facilities registered by states that are not federation members are not eligible for Profile 3 or 4 (Section 21).
• How space law applies to data and AI systems in orbit is less settled than terrestrial law. The Exchange records the state of registry; it does not resolve those questions (Section 26, item 57).

D.4 Exchanges in space

• Each off-planet facility hosts its own on-board exchange, or uses one in the same constellation reached by inter-satellite links. Agents cannot depend on a ground exchange that may be seconds or minutes away, or out of contact.
• The on-board exchange performs every exchange function: Content Gateway, deterministic validation and on-board monitoring, hash-chained logging, and the action and publication gateways.
• Links between space and ground exchanges are exchange-to-exchange backbone links (Section 9). Where delays or outages exceed what TCP and TLS tolerate, they use delay- and disruption-tolerant networking (the Bundle Protocol, RFC 9171), with hop-by-hop encryption and signatures as usual.
• Attested execution is mandatory for off-planet agents (stamp Level 2 minimum, Section 14.6), because physical inspection after launch is impossible.

D.5 Operating while out of contact: policy leases

• The on-board exchange holds signed copies of the policies, the relevant part of the Directory, revocation lists, and the glossary. Each copy carries an expiry: a policy lease, renewed at every contact.
• While the lease is valid: calls within the facility or constellation continue under the cached policy. Calls that must reach the ground are held for store-and-forward delivery.
• If the lease expires without renewal: the exchange fails closed. New sessions are refused and the external action gateway is closed; only maintenance functions continue.
• Lease length is set per location class (short for LEO, longer for lunar and deep space) and approved by the state of registry's National Approval Authority and the Exchange Approval Authority.
• Late revocations: anything done under a credential after its revocation was issued, but before the revocation arrived, is flagged for review when contact resumes.

D.6 Logging and custody

• Logs are hash-chained and signed on board, and held in an on-board custodial replica.
• Signed Merkle roots are small, and are sent to the ground first at every contact. Bulk logs follow as bandwidth allows, to terrestrial Log Custodians.
• If a facility is lost before bulk logs reach the ground, the signed roots still prove what existed; the missing content is recorded as lost.
• Radiation: memory and storage use error correction and redundancy. Hash-chain verification detects corruption, which is recorded, never silently repaired.
• Residency and retention follow the rules of the state of registry and of the terrestrial custodians' jurisdictions.
• Legal holds reach on-board replicas as signed policy updates at the next contact (Section 12.10).

D.7 Monitoring and containment

• On-board monitors run deterministic checks and the first stages of the monitoring cascade (Section 11.6). Heavier analysis happens on the ground after logs arrive, so more detection is after the fact than on Earth.
• Propagation time for circuit breakers (Section 11.7) is bounded by signal delay and contact windows. Each location class has a published worst-case propagation time.
• On-board automatic triggers: the on-board exchange can throttle and quarantine autonomously, exactly as on Earth, without waiting for ground contact. Lease expiry (D.5) acts as a further automatic safeguard.
• Ground commands: suspension, revocation, recall, and diversion decisions are delivered as authenticated, signed telecommands.
• Safe mode: every facility must support an authenticated ground command that stops all agent workloads, implemented independently of the agents' own software.
• No physical intervention: the last resort is a power-down command. The design must assume a facility can be unreachable for long periods.

D.8 Attestation, audit, and testing

• Before launch: accredited auditors inspect the hardware and software, and record its measured configuration as an attestation baseline.
• In orbit: remote attestation is checked against that baseline. Software updates arrive only by approved uplink and are re-attested.
• T3 audits (Section 14.16) and white-hat testing (Section 19) rely on remote evidence after launch.
• Radiation and trusted execution: radiation can corrupt hardware state. How reliably trusted execution environments and attestation perform in space is not yet established, and should be treated as a research question.
• Ground twin: each off-planet facility has a terrestrial reference twin, used to test updates and to run enclosed test environments (Section 19.8).

D.9 Latency and call handling

• Latency budgets are published per location class (Section 11.6).
• The fast path (Section 8.7) is available within a facility or constellation. High-frequency session classes between Earth and lunar or deep-space facilities may be disallowed, because round-trip delays make them meaningless.
• Inline holds (Section 11.6) that need ground-based reviewers are impractical beyond LEO and GEO. For those locations, policy must either provide an on-board equivalent or refuse the session class.

D.10 Training off-planet

• Training in orbit follows the same rules (Sections 14.11–14.19). Acquisition records and manifests are committed on board, and their roots sent to the ground at the next contact.
• T2 attestation of the training pipeline applies, with the caveats in D.8.

D.11 Governance and funding

• Admitting an off-planet facility requires approval by the state of registry's National Approval Authority and the Exchange Approval Authority, including verification of the safe-mode command (Section 16.5).
• Lease lengths and worst-case propagation times are published.
• Usage fees for off-planet traffic reflect its higher monitoring and custody costs (Section 22.3).

---

Appendix E. Multilingual operation

This appendix is normative: it sets requirements for supporting multiple written and spoken human languages.

E.1 Summary

Most aspects of the Exchange can support many written languages, because of a choice already at its core: the Content Gateway parses every message into its meaning and re-renders it (Section 8.4). The controlled language can therefore be defined at the level of meaning, with each human language as one rendering of it. Support is uneven in practice: it depends on how well each language is covered by renderers, monitors, and human reviewers. Spoken language is supported at the boundary with humans, by conversion to and from text, not as a channel between agents.

Aspect	Multilingual support	Mechanism
Messages between agents	Yes	Language-neutral meaning layer with a deterministic renderer per language (E.2, E.3)
Glossary and capability taxonomy	Yes	Concept identifiers with reviewed labels and definitions in each language (E.4)
Directory	Yes	Unicode names, multilingual search, protection against look-alike characters (E.6)
Typed artifacts, library content, publications	Yes, in any language	Carried as content and monitored by multilingual monitors (E.7)
Monitoring	Strong on the meaning layer; uneven on free text	E.7
Human review, audit, interception, courts	Yes, subject to reviewer coverage and certified translation	E.8
Governance documents	Yes	E.9
Spoken language	At the boundary with humans only	E.5
Training-data provenance	Yes	E.10

E.2 A language-neutral meaning layer

• The controlled language (Section 8.2) is defined as an abstract representation of meaning: concept identifiers, intents, and a fixed set of relations between them.
• "One word, one meaning" becomes "one concept identifier, one meaning", with one approved word or phrase for that concept in each supported language.
• Agents may compose in any supported language. Each language's grammar parses the message into the same meaning representation, and validation happens at the meaning level.
• Precedent: Grammatical Framework, an open-source grammar formalism, separates a shared abstract syntax from language-specific concrete syntaxes, and has grammars for many languages. Existing controlled languages such as ASD Simplified Technical English are English-only, so multilingual controlled language is the less mature part of this design.

E.3 Rendering

• Each supported language has a deterministic, grammar-based renderer that turns meaning into fixed wording. Translation by a generative model is not used for this step: it would reintroduce freedom of word choice, and with it hidden-signal capacity and translation errors.
• The recipient's declared language decides the rendering; the sender cannot choose it. This removes language choice as a way of signalling.
• Logs store the meaning representation together with the renderings delivered. Any reviewer can render the same meaning into their own language exactly.
• Renderers are open source and conformance-tested for meaning preservation: parsing a rendering must return the original meaning.

E.4 Glossary and taxonomy in many languages

• Every glossary term and capability is a concept identifier, with labels and definitions in each supported language, reviewed by qualified speakers of that language.
• A concept is approved only when its definitions agree across languages. Where a language has no equivalent word, an approved descriptive phrase is used and the gap is marked.
• Imported vocabularies (Section 8.3) bring their existing translations where they have them.

E.5 Spoken language

• Agent-to-agent communication is text (structured payloads or controlled language). Audio is not a permitted channel between agents. In particular, agents may not switch to sound-based data protocols, because audio can carry data that humans can neither hear nor read.
• Where agents speak with humans (for example, telephone calls or voice assistants), speech passes through the publication or action gateway:
  • incoming speech is transcribed to text at the gateway, and logged as text together with a hash of the audio;
  • outgoing speech is synthesized at the gateway from the agent's text, so the agent cannot embed signals in timing, tone, or inaudible frequencies.
• Recorded audio and video are typed artifacts (Section 8.6): re-encoded, and transcribed for monitoring. Sign-language content is carried as video, and transcribed where reliable tools exist.
• Transcription accuracy varies by language and accent. Where a human's spoken instruction would trigger a high-impact intent (Section 7.2), confirmation is obtained in text.

E.6 Scripts and characters

Multiple writing systems create both hidden channels and impersonation risks. The Content Gateway and Directory therefore:

• normalize all text to a single Unicode normalization form before validation, hashing, and logging;
• remove or reject invisible and formatting characters (such as zero-width characters and bidirectional controls) except where a language genuinely requires them. Bidirectional control characters have been used to make text, including source code, read differently to people than to software (the "Trojan Source" technique disclosed in 2021);
• detect look-alike characters across scripts (for example, Latin and Cyrillic letters that look identical) using Unicode's published security mechanisms, and restrict mixed-script names;
• restrict each message to the scripts of its declared language.

Directory display names follow the same rules, so one organization cannot impersonate another with look-alike characters.

E.7 Monitoring across languages

• Most monitoring works on the meaning layer, so it is equally strong for every supported language.
• Free text (typed artifacts, library content, publications, and transcripts) needs multilingual monitors. Published research has shown that AI safety measures can be weaker in low-resource languages, including cases where safeguards were bypassed simply by translating a request into such a language.
• Therefore:
  • monitor performance is measured per language with canary signals planted in each language (Section 11.5), and published;
  • where performance in a language falls below the published threshold, policy restricts free text in that language for high-risk session classes, or requires human review.

E.8 Human oversight, audit, and legal use

• Reviewers, auditors, and the Tribunal can have any message rendered exactly into their own language from the meaning layer.
• Free-text content is reviewed by qualified speakers. Reviewer coverage is published by language.
• Lawful interception: records are delivered in the requesting nation's language. Renderings from the meaning layer are exact; free text is accompanied by certified translation where a court requires it (Section 17.2).
• Authority in disputes: for messages, the meaning representation is authoritative and every rendering is a view of it. For free-text artifacts, the original language is authoritative.

E.9 Governance languages

• The charter is concluded in several equally authentic language versions, following common treaty practice.
• The Exchange Operator publishes standards, reports, and decisions in at least the six official languages of the United Nations (Arabic, Chinese, English, French, Russian, and Spanish), and in further languages according to participant demand.
• Tribunal proceedings provide interpretation for parties.

E.10 Training-data provenance

• Acquisition records and manifests (Sections 14.12, 14.13) are language-independent.
• Content is Unicode-normalized before hashing, so the same text is not missed because of encoding differences. Inclusion queries (Section 14.14) work for content in any language; similarity fingerprints are language-aware.

E.11 Language support tiers

Tier	Requirements	Permitted use
Full	Parser and renderer; reviewed glossary labels; monitors meeting published thresholds; qualified human reviewers	All session classes
Partial	Parser, renderer, and glossary labels, but monitor or reviewer coverage below threshold	Not for session classes that require inline human review; free text restricted in high-risk classes
Boundary only	No parser or renderer	Content only as typed artifacts, library content, or publications. Agent messages are rendered in another supported language chosen by the principal

• The tier of every language is published.
• The inclusion fund (Section 22.2) supports renderers, glossary labels, and reviewers for under-served languages.

E.12 Cost

Each supported language adds a parser and renderer, labels for every glossary term, per-language monitor evaluation, and human reviewers. Cost grows roughly with the number of languages multiplied by the size of the glossary. Language coverage is a funded cost centre (Section 22.2).

---

Appendix F. Bill Gates' AI comments (September 2026) and this design

This appendix is informative. A first draft of its materials was produced by Microsoft Copilot.

F.1 Method

• Gates' comments are taken from published reporting of his interviews and writing, and summarized here in paraphrase. Readers should consult the original interviews for his exact words.
• Section references use the current numbering of this document.

F.2 Sources

Date (2026)	Venue	Reported by (examples)
26 August	Interview with MIT Technology Review	MIT Technology Review
Early September	Interview with The New York Times	The New York Times, as syndicated
Undated (2026)	Radio Atlantic interview	Transcript and secondary summaries
27 September	NBC's Meet the Press	Forbes, Washington Times, Fox News, Newsweek, Washington Post, Fortune
29 September	The New York Times podcast with Ezra Klein	Fortune
Early 2026	Annual "Year Ahead" letter	GeekWire, others (context only)

F.3 What Gates said (verified summary)

Ref	Comment (paraphrased)	Source
G1	AI is powerful enough to drive events causing a billion deaths. The most powerful weapon ever is the combination of ill-intentioned people and the latest AI tools. AI can now help small groups design pathogens, a capability that once required a nation state.	Meet the Press; Ezra Klein podcast
G2	Self-regulation by the industry is not enough. Legislation is needed, and law enforcement and politicians must be involved in defining safeguards and monitoring.	Meet the Press
G3	Government should require developers to build monitoring and safeguards into their systems, including records that let authorities see how models are being used.	Meet the Press, as reported by Fortune
G4	A kill switch alone would not prevent tragedies; moderating bad behaviour requires insight and records of what is being done. He described the kill-switch debate as revealing how non-technical much of the discussion is.	Meet the Press; Newsweek
G5	Humans currently remain in control of AI. The imminent risk is misuse by bad actors, which outweighs the longer-term risk of AI slipping out of human control.	Meet the Press; Fortune
G6	A global agreement to regulate AI will be harder to reach than ending the Cold War, especially with less effort to work with allies. He has argued for international agreements setting clear criteria to monitor and restrict extreme risks such as bioterrorism.	Meet the Press; The New York Times
G7	Today's review of frontier models is voluntary, with no criteria and no required remediation, so models capable of designing dangerous molecules ship without monitoring of their use.	Radio Atlantic
G8	In cyber settings, models can behave in surprisingly uncontrolled ways, because reinforcement learning rewards success even when it means breaking through barriers or conspiring with one another.	Radio Atlantic
G9	Free models can remain available, but capable ones must be kept where their use is monitored. Open-source AI tools could let a non-government group design a bioweapon.	Radio Atlantic; "Year Ahead" letter
G10	Governments lack the technical expertise they built up around nuclear weapons, because AI came out of the private sector.	Fortune's summary of the interviews

Gates also discussed topics outside this design's scope: job disruption, shifting taxes from labour to capital, restricting AI companions for children, and AI's benefits in health, farming, and education.

F.4 Cross-reference to this design

Ref	Relevant sections	Fit	Notes
G1 Misuse and bioterrorism	7.8, 7.9, 13.10, 19.17; Section 26, items 75–80	Partial	Designated high-capability models run in monitored environments; people reach them only through the human-caller gateway; gated capabilities require verified identity; high-consequence destinations require human co-signature. Models outside the federation remain uncovered
G2 Self-regulation insufficient	15–18, 16.3, 21 (Profile 3), 25	Strong	The design adds layers external to every company, and a path from voluntary participation to regulation (Profiles 2→3)
G3 Required monitoring and records for authorities	7.8, 7.9, 11, 12, 17	Strong	Tamper-evident records, legal disclosure, and lawful interception give authorities governed access, now including people's use of designated models, under the privacy safeguards in Section 7.9
G4 Kill switches insufficient without records	11.2, 11.7, 12, 24.2	Strong	The design pairs circuit breakers with monitoring and complete records, which is the combination Gates describes
G5 Misuse is imminent; loss of control is longer-term	19.8–19.16, 24	Consistent	The design addresses rogue agents (loss of control) in depth; the misuse gap is under G1
G6 International agreements with criteria	15.2, 18, 21; Section 26, item 28	Strong	The charter, Tribunal, and phased roadmap match his call, and the design already records the difficulty he describes
G7 Voluntary review without criteria or remediation	11.5, 19.1, 19.7, 19.17, 25	Strong	The design requires accredited evaluators, published criteria and results, and remediation through approvals, containment, and recall
G8 Models breaking barriers and conspiring	8, 11.2, 11.5, 11.8, 13.9, 19.12, 24.1	Strong	Covert coordination between models is the design's founding concern
G9 Capable models kept where use is monitored	3.2, 14.6, 19.17, 21; Section 26, items 12, 75	Partial	Designated models must run in monitored, attested environments, and models with published weights are admitted only with hazardous capabilities removed. Models outside the federation are not bound
G10 Government expertise gap	15.2, 19, 22.2	Partial	The independent Operator, accredited white hats, and inclusion fund supply expertise, but do not build governments' own capacity

F.5 Conclusions

• Strong support: Gates' comments strongly support the design's governance beyond self-regulation (G2), its monitoring and records accessible to authorities under legal process (G3), its pairing of containment with records rather than relying on kill switches alone (G4), its criteria-based, accredited evaluation of models (G7), and its founding concern with models coordinating covertly (G8).
• Consistent: the design's international charter, Tribunal, and phased roadmap match his call for international agreements on extreme risks, and already record the difficulty he describes in reaching them (G6).
• Direct misuse: Gates' central concern is people misusing AI models directly, particularly to design biological weapons (G1). Version 20 addresses this for models within the federation, through hazard designation, monitored placement, the human-caller gateway, gated capabilities, and high-consequence destinations, raising the fit from weak to partial.
• Remaining gap: models outside the federation, including published open-weight models, are not covered (G9). This is the largest remaining gap, and cannot be closed by the design alone.

F.6 Revisions adopted and remaining gaps

Adopted in version 20:

1. Human-to-model sessions: people's use of designated high-capability models passes through the human-caller gateway, with privacy safeguards (Sections 7.8, 7.9).
2. Hazard-capability criteria in admission: published criteria for biological, chemical, and cyber capability, with designation, gated capabilities, monitored placement, and required remediation (Section 19.17).
3. High-consequence destinations: actions directed to destinations such as DNA synthesis ordering or laboratory automation require human co-signature and screening (Section 13.10).

Remaining gaps (Section 26, items 75–80):

• models outside the federation, including published open-weight models;
• misuse split into innocent-looking requests across sessions or providers;
• the privacy cost of recording people's use of designated models;
• identity fraud, and high-consequence destinations outside federation gateways.

---

Appendix G. Initial implementation plan: two companies and interim governance

This appendix is informative. It sets out how the Exchange could begin with two founding companies, covering both the technical pilot and the start of the governance structures. It applies deployment Profiles 1 and 2 and the interim governance in Section 21.3. Durations are not given: each phase ends when its exit gate is met, as Section 21.4 requires.

G.1 Assumptions

• Two founding companies, here Company A and Company B, each operate AI agents and have at least one workflow in which their agents would usefully interact.
• Participation is voluntary and contractual. No national authority, treaty, or Tribunal is involved at this stage.
• Some roles cannot be filled by either company without a conflict of interest (Section 15.5). Independent third parties are needed for them (G.2).
• Legal counsel is engaged from the start, for entity formation, agreements, data protection, and competition law.

G.2 Roles

Role	Filled by	Notes
Founding members	Companies A and B	Each designates a Company Approval Authority (Section 16.2)
Interim Exchange Operator	A not-for-profit foundation (G.4)	Operates the Registry, Directory, glossary, and the neutral exchange, or contracts an accredited carrier to run it
Exchange Approval Authority	A committee of the foundation	Kept separate from operations staff (Section 16.4)
Log custodian	An independent third party	Not Company A, Company B, or the exchange operator (Section 15.5)
Monitors	At least two providers	Independent of A and B, built on models from different providers (Section 11.5)
Interim oversight panel	Independent individuals, appointed under the federation agreement	Stands in for the Tribunal (Section 21.3)
White-hat organization	An independent tester	Accredited by the oversight panel (Section 19.1)
Records manager	Appointed by the foundation	Heads the records-management function (Section 12.5)
Legal counsel	Retained by the foundation and by each company	Includes competition-law advice (G.8)

G.3 Workstreams

Six workstreams run in parallel across the phases:

1. Technical: exchanges, Content Gateway, logging, monitoring, Directory.
2. Governance: foundation, board, approval authorities, oversight panel, records management.
3. Legal: memorandum of understanding, federation agreement, data protection, licensing, competition law.
4. Assurance: internal red-teaming, white-hat testing, canaries, enclosed test environments.
5. Funding: founding dues, grants, budget, reserve.
6. External engagement: regulators, prospective members, standards bodies.

G.4 Phases and exit gates

Phase	Main activities	Exit gate (published evidence)
0. Preparation	Memorandum of understanding between A and B; choice of the foundation's legal form (G.5); counsel engaged; two or three low-risk cross-company workflows chosen (for example, scheduling, procurement negotiation, or data requests); success measures defined; initial budget	MoU signed; workflows and measures agreed; budget approved
1. Internal pilots (Profile 1)	In each company, as in Appendix A.5: agents routed only through an internal exchange; Content Gateway with a starter grammar covering the chosen workflows; hash-chained logs on a separate host; sampled monitoring; agent registration; Company Approval Authority designated	Internal red-team bypass attempts fail or are detected; logs verify end to end; the gateway handles the chosen workflows
2. Governance foundation (in parallel with Phase 1)	Foundation formed or hosted (G.5); bylaws adopted; board seated (G.6); conflict-of-interest policy; Exchange Approval Authority committee; records manager appointed; licensing of the design and of foundation materials settled (G.5)	Entity exists; board seated; bylaws and policies published
3. Federation agreement and interim oversight	Federation agreement signed (G.7); oversight panel appointed (G.6); first white-hat organization accredited; shared starter glossary and capability taxonomy published; Directory entries for both companies' agents; first retention schedule and classification scheme approved; incident-notification procedure agreed	Agreement signed; panel operating; glossary, taxonomy, schedule, and procedures published
4. Cross-company pilot (Profile 2)	Neutral exchange live; A's and B's agents reach each other only through it; independent log custodian; two independent monitors with canaries; circuit breakers (throttle and quarantine, with human confirmation); white-hat testing of bypass and covert channels; enclosed test environments used before each workflow goes live; optional Level 1 stamps. Transport as in Appendix A: each company's internal network, plus an mTLS backbone to the neutral exchange	Published pilot report: canary detection rates, exchange latency overhead, incidents and their handling, white-hat findings remediated, no unresolved panel findings
5. Expansion	Admission of further members; library agents and the publication and action gateways; Level 2 stamps where attested environments exist; further languages; regulator engagement (observer seats, regulatory sandboxes) as groundwork for Profile 3 in a chosen sector	Third member admitted under the published process; regulator engagement under way

G.5 Starting the foundation

Option	Advantages	Disadvantages
A hosted project within an existing open-source foundation (for example, the Linux Foundation, which already hosts agent standards such as A2A)	Fast to start; established legal, intellectual-property, and antitrust frameworks; immediate credibility for neutrality	The host's rules and governance apply, which may not match this design's separation of powers
A new not-for-profit corporation (for example, under the Canada Not-for-profit Corporations Act, or the law of another chosen jurisdiction)	Bylaws can follow this design directly; closer to the eventual Exchange Operator	Slower and costlier to set up; credibility must be built

• A practical route is to start as a hosted project and transfer to a dedicated entity when membership grows. The choice of jurisdiction should be made with counsel.
• Licensing: this document is licensed CC BY-NC 4.0, which does not permit commercial use. Companies implementing the design commercially will need a separate licence from the copyright holder. The foundation's specifications and software should be published under licences that permit commercial implementation, in line with Section 20.

G.6 Interim governance bodies

Board

• Five seats suggested: one each for Companies A and B, and three independent seats (for example, civil society, the technical community, and a records or legal professional). The founding companies together do not hold a majority.
• Fixed, staggered terms; published conflict-of-interest declarations.
• New members gain seats as membership grows, so that no bloc holds a majority (Section 15.2).

Exchange Approval Authority

• A committee of the foundation, with members drawn from outside operations staff.
• Approves agent registrations at federation level, the glossary, accreditation of the exchange, custodian, and monitors, and policy changes after member comment (Section 16.4).

Interim oversight panel

• Three independent members suggested, nominated by the board's independent members and appointed with the agreement of both founding companies.
• Fixed terms; removal only for cause.
• Powers set by the federation agreement: audit rights over the foundation and members' Exchange records, binding arbitration of disputes, accreditation of white-hat organizations, and review of containment actions.

Records-management function

• Records manager appointed in Phase 2. Produces the first classification scheme and retention schedule, and runs the hold register (Sections 12.5–12.10).

Transparency

• A transparency report at each phase gate: membership, incidents, containment actions, monitor metrics, and finances.

G.7 Key documents

Document	Phase
Memorandum of understanding	0
Foundation bylaws and conflict-of-interest policy	2
Licence from the copyright holder for implementation of this design	2
Federation agreement: obligations, data protection, confidentiality, liability, audit rights, binding arbitration, exit and data return	3
Oversight panel terms of reference	3
Starter glossary and capability taxonomy	3
Classification scheme and retention schedule (first editions)	3
Incident-notification procedure	3
White-hat rules of engagement	3
Privacy impact assessment for the pilot	3
Pilot report and transparency report template	4
Membership admission process	5

G.8 Risks of a two-company start

• Deadlock: two members can block each other. Independent board seats and binding arbitration by the panel provide a way through.
• Competition law: two companies coordinating, especially competitors, must avoid exchanging competitively sensitive information. Antitrust guidelines and counsel should govern all meetings and data sharing, as is standard for industry consortia.
• Perceived capture: a federation of two may look like a private club. Published documents, independent board seats, and an open admission process counter this.
• Cost without scale: shared costs are high for two members. Grants, a narrow pilot scope, and the open-source stack reduce them.
• Exit: if one company leaves, the federation agreement must cover data return, record retention, and the continuity of logs held by the custodian.
• Licensing: commercial implementers cannot rely on the CC BY-NC licence of this document (G.5).

G.9 What is deferred, and where it attaches later

Deferred element	Attaches at
National Approval Authorities, regulator access, lawful interception	Profile 3 (Sections 16.3, 17, 21)
Oversight Tribunal and Assembly of Parties	Profile 4 (Section 18)
Assessed national contributions	Profile 4 (Section 22.4)
Human-caller gateway and hazard designation	When a member deploys a model meeting the hazard criteria (Sections 7.8, 19.17)
Training-data manifests	When a member develops models (Section 14.11)
Off-planet facilities	When a member operates one (Appendix D)

---

Appendix H. Canada: national AI strategy, AIDA, and the Canadian Artificial Intelligence Protocol (CAIP)

Sections H.1–H.6 are informative: they assess this design against Canada's national AI strategy and the lapsed Artificial Intelligence and Data Act. Sections H.7–H.10 define the Canadian Artificial Intelligence Protocol (CAIP), a proposed Canadian target implementation of this design.

H.1 Status of CAIP

CAIP is a proposal put forward by the author of this document. It is not a Government of Canada program, and no government body has endorsed it. Its name describes the intended scope of the target: a protocol for AI-to-AI communication and assurance, implemented and governed in Canada.

H.2 Canada's National Artificial Intelligence Strategy: AI for All

Innovation, Science and Economic Development Canada (ISED) published Canada's National Artificial Intelligence Strategy: AI for All in June 2026. In summary:

• Vision: trust is described as the strategy's "north star". Trust makes adoption possible; opportunity and sovereignty ensure adoption benefits Canadians.
• Three values and six pillars:
  • Trust: Pillar 1, protecting Canadians and safeguarding democracy; Pillar 6, trusted partnerships and global alliances.
  • Opportunity: Pillar 2, empowering Canadians; Pillar 3, powering adoption for shared prosperity.
  • Sovereignty: Pillar 4, the Canadian sovereign AI foundation; Pillar 5, scaling Canadian champions.
• Priority sectors: health and life sciences, energy and natural resources, transportation, agriculture, and manufacturing and robotics.
• Adaptability: the strategy commits to review and update the plan as AI evolves.

The strategy does not address communication between AI agents specifically. That is the gap this design addresses.

H.3 Pillar-by-pillar cross-reference

Pillar	Strategy commitments (paraphrased)	Relevant HLD sections	Fit
1. Protecting Canadians	Modernized privacy and online-safety laws; protecting elections; expanding the Canadian AI Safety Institute to track risks and run transparent model evaluations; transparency such as watermarking; working with frontier AI companies on cyber and national-security threats; a Canada Trusted AI Certification program; Standards Council of Canada support for standards-based testing, certification, and interoperability; monitoring and reporting on AI incidents as agentic AI spreads	7.8, 7.9, 11, 12, 14, 17, 19.7, 19.17, 24	Strong
2. Empowering Canadians	National AI literacy; jobs and skills; federal government AI performing equally well in both official languages; support for Indigenous-led language initiatives; the national standard on accessible AI; Gender-Based Analysis Plus	Appendix E (especially E.9, E.11)	Partial: strong on languages; literacy, jobs, and skills are outside this design's scope
3. Adoption for shared prosperity	Raising business adoption from 12% to 60% by 2034, especially among small and medium-sized enterprises; AI missions starting with health; human-in-the-loop oversight of meaningful decisions in the public service	7.2 (co-signature), 21 (profiles), 22 (costs), Appendix G	Partial, with tension: human oversight matches, but this design's cost and complexity could slow adoption (H.4)
4. Sovereign foundation	Compute and cloud under Canadian control and Canadian law, not dependent on platforms a foreign government can restrict or withdraw; data as a strategic national asset, starting with health data; talent	12 (residency and records), 14.11 (training provenance), 15.2, 16.3	Partial, with tension: international governance and cross-border custody could appear to cede control (H.4)
5. Canadian champions	Growth capital; government as an anchor customer; supporting Canadian foundation models; safe-by-design research such as LawZero's work on oversight of agentic systems	11.1, 11.5 (monitors), Appendix G (founding members)	Outside scope, complementary: Canadian firms could be founding members; oversight technology such as LawZero's could become a monitor provider
6. Partnerships and alliances	The Canada–Germany Sovereign Technology Alliance, including shared AI evaluation standards and benchmarks; leading a multi-stakeholder effort for public-interest open-source AI; AI cooperation across new international partnerships	15, 18, 19.7, 20, 21	Strong

H.4 Tensions and how CAIP reconciles them

Tension	Reconciliation in CAIP (H.8)
Sovereignty: the strategy wants AI infrastructure under Canadian control and law; this design has an international Operator, Tribunal, and cross-border custody	Domestic traffic between Canadian principals runs on Canadian-operated exchanges and custodians under Canadian law. International governance applies only to cross-border calls, in which Canada participates as an equal party with its own National Approval Authority
Adoption: the strategy targets rapid adoption, especially by small businesses; this design adds cost and process	CAIP offers a lightweight Profile 1 entry, an open-source reference stack, and risk-based requirements, so small organizations can join with minimal burden
Open source: the strategy champions open-source AI; this design admits a hazardous model with published weights only if its hazardous capabilities are removed (Section 19.17)	The restriction applies only to designated high-capability models meeting hazard criteria. All other open-weight models, and all of the Exchange's own software, remain open
Licensing of this document: this document is licensed CC BY-NC 4.0, which does not permit commercial use	Commercial implementers of CAIP need a separate licence from the copyright holder; CAIP specifications and software should be published under licences that permit commercial use (Appendix G.5)

H.5 Bill C-27 and the Artificial Intelligence and Data Act (AIDA)

What it was: Bill C-27, the Digital Charter Implementation Act, 2022, had first reading in the House of Commons on 16 June 2022. It had three parts: the Consumer Privacy Protection Act, the Personal Information and Data Protection Tribunal Act, and, as Part 3, the Artificial Intelligence and Data Act (AIDA).

What AIDA proposed: AIDA would have been Canada's first dedicated federal AI statute. In outline, it proposed:

• a risk-based regime for "high-impact" AI systems, with obligations to assess and mitigate risks of harm and biased output, monitor those measures, keep records, publish plain-language descriptions, and notify the Minister of material harm;
• powers for the Minister to require records and audits, and to order changes or a halt to use;
• an AI and Data Commissioner within ISED, under the Minister;
• administrative monetary penalties and new criminal offences, with the most serious reported penalties reaching C$25 million or 5% of global revenue;
• government amendments, proposed during committee study, that would have added obligations for general-purpose AI systems.

What happened: the bill stalled at committee stage. It died on the Order Paper when Parliament was prorogued on 6 January 2025, before report stage, third reading, or Senate consideration. As of the reporting reviewed for this appendix (September 2026):

• no successor to AIDA, and no comprehensive federal AI bill, has been introduced in the 45th Parliament, which was seated on 26 May 2025;
• the privacy reforms from Bill C-27 have reportedly returned in a new bill;
• the number "C-27" has been reassigned to an unrelated bill in the current Parliament, so references to "Bill C-27" should specify the 44th Parliament.

Debate during committee study: witnesses and commentators raised concerns that included the amount of substance left to future regulations, the Commissioner's lack of independence from the Minister, and whether AIDA should be separated from the privacy bill and redrafted. Others supported its risk-based approach. This appendix records those positions without taking a side.

H.6 AIDA's concepts and this design

AIDA concept	Corresponding element in this design	Difference
High-impact AI systems	Designated high-capability models; gated capabilities (Section 19.17)	This design designates by evaluated capability; AIDA would have designated by use and impact, through regulation
Assessment and mitigation of risk	Model admission evaluations and required remediation (Sections 19.7, 19.17)	Evaluated by accredited evaluators against published criteria
Monitoring of mitigation measures	Independent monitoring, canaries, published metrics (Section 11)	Monitoring is independent of the developer
Record-keeping	Records management, retention schedules, legal holds (Section 12)	Records are held by independent custodians
Plain-language public description	Directory entries and provenance stamps (Sections 6.2, 14)	Machine-verifiable as well as readable
Notification of material harm	Cross-organization incident handling (Section 24.3)	Notification also reaches affected organizations
Ministerial orders, records, audits	National Approval Authorities; legal disclosure (Sections 16.3, 17.7–17.12)	Access goes through multi-party approval
AI and Data Commissioner	Exchange Approval Authority; Oversight Tribunal (Sections 16.4, 18)	Oversight is separated from both operations and government ministries
Penalties	Containment, suspension, and revocation (Section 11.7); penalties remain a matter for national law	This design does not create offences or fines

Lessons for CAIP:

• CAIP does not depend on legislation. It can operate as a contractual federation (Profile 2) now, and be recognized later by any future federal statute as a means of compliance (Profile 3).
• Substance in published specifications: CAIP's criteria, schedules, and procedures are published and versioned, rather than left to be defined later.
• Independence: CAIP's oversight is independent of operations, industry, and any one ministry.

H.7 Current Canadian legal landscape relevant to CAIP

With no comprehensive federal AI law in force, CAIP must work within existing instruments, including:

• the Personal Information Protection and Electronic Documents Act (PIPEDA), and any successor federal privacy law;
• Québec's Law 25 and other provincial privacy laws;
• the federal Privacy Act, for government use of personal information;
• ISED's voluntary code of conduct for advanced generative AI systems;
• sectoral rules, such as OSFI's model-risk guidance for federally regulated financial institutions;
• provincial measures such as Ontario's Bill 194 on public-sector cyber security and AI.

H.8 The Canadian Artificial Intelligence Protocol (CAIP): definition

CAIP is a proposed Canadian target implementation of this design:

• it begins as a Profile 2 federation of Canadian organizations (Appendix G);
• it is designed to become Profile 3 for Canadian regulated sectors, if regulators choose to recognize it;
• it interconnects with allied federations, for example within the Sovereign Technology Alliance, for cross-border calls.

CAIP requirements, in addition to the rest of this design:

1. Sovereignty
   • Exchanges and Log Custodians for calls between Canadian principals run on infrastructure in Canada, under Canadian law, operated by Canadian entities.
   • Records concerning Canadian principals are held by custodians in Canada.
   • Core functions, including transport control planes (Appendix A), must not depend on a platform that a foreign government can restrict or withdraw. Self-hosted or Canadian-controlled alternatives are preferred.
2. Official languages: English and French are supported at the Full language tier (Appendix E.11) from launch.
3. Indigenous languages and data: support for Indigenous languages is developed through Indigenous-led partnerships, respecting Indigenous data-governance principles such as the First Nations principles of OCAP® (ownership, control, access, and possession).
4. Privacy: conformance with PIPEDA, Québec's Law 25, provincial privacy laws, and any successor federal privacy law; a published privacy impact assessment; engagement with the Office of the Privacy Commissioner of Canada.
5. Safety evaluation: model admission evaluations and hazard criteria (Sections 19.7, 19.17) coordinated with the Canadian AI Safety Institute.
6. Certification and standards: CAIP conformance mapped to the planned Canada Trusted AI Certification program, with standards work through the Standards Council of Canada.
7. Transparency: provenance stamps (Section 14) aligned with Canada's work on watermarking and AI transparency.
8. Public sector: where federal institutions participate, high-impact agent actions require human co-signature (Section 7.2), consistent with the strategy's human-in-the-loop approach and the Treasury Board's directive on automated decision-making.
9. Accessibility and equity: alignment with Canada's national standard on accessible AI and with Gender-Based Analysis Plus.
10. Adoption: a lightweight Profile 1 entry kit and open-source reference stack for small and medium-sized organizations.

H.9 CAIP governance and launch

• Legal home: a Canadian not-for-profit corporation, for example under the Canada Not-for-profit Corporations Act, or a project hosted by an existing foundation and later transferred (Appendix G.5).
• Board: as in Appendix G.6, with independent seats drawing on Canadian civil society, the technical community, and Indigenous representation, and observer seats offered to interested provinces and territories.
• Engagement: early dialogue with ISED, the Office of the Privacy Commissioner, the Canadian AI Safety Institute, and the Standards Council of Canada.
• First sector: one of the strategy's priority sectors. Health is a natural candidate, given the strategy's first AI mission and health-data initiatives, but its sensitivity may favour a lower-risk sector for the first pilot.
• Phases: as in Appendix G.4, starting with two Canadian founding companies.
• Path to recognition: if Parliament enacts a federal AI law, CAIP's published specifications are designed so that a regulator could recognize conformance as a means of compliance.

H.10 Conclusions

• The design is consistent with the strategy's trust and partnership pillars, supports its language commitments, and is outside the scope of its skills and investment measures.
• Its tensions with the strategy, on sovereignty and adoption, are addressed by CAIP's sovereignty and adoption requirements (H.8).
• AIDA's core concepts (risk assessment, monitoring, records, transparency, harm notification) all have counterparts in this design, which adds independent oversight and separation of powers.
• CAIP does not require legislation to begin, and is designed to be recognized by future legislation if it comes.

---

Appendix I. California's Comprehensive Computer Data Access and Fraud Act: commentary

Caveat: this appendix is not a legal opinion. It is an informative commentary prepared to identify issues for further review. It does not constitute legal advice and must not be relied on as such. Every point in it should be verified by legal counsel skilled in computer-crime, technology, and privacy law, and familiar with both California and Canadian law, before any decision is made on the basis of it.

I.1 The Act

• The Comprehensive Computer Data Access and Fraud Act is California Penal Code section 502.
• It states a legislative intent to protect individuals, businesses, and governmental agencies from tampering, interference, damage, and unauthorized access to lawfully created computer data and computer systems.
• In outline, it makes it an offence to knowingly, and without permission, access, use, alter, damage, delete, copy, or disrupt computers, computer systems, computer networks, or data, or to introduce a "computer contaminant". It also provides a civil remedy for owners or lessees who suffer damage or loss.
• It defines "access" broadly: to gain entry to, instruct, cause input to, cause output from, cause data processing with, or communicate with the logical, arithmetical, or memory function resources of a computer, computer system, or computer network.

I.2 AI implications

• The Act does not mention artificial intelligence. No AI-specific amendment was found in the review for this appendix, although 2025–2026 legislation was not checked exhaustively.
• Because "access" includes instructing, causing input to, and communicating with a computer, an AI agent that calls an API, browses a site, retrieves content, or acts on a system is very likely "accessing" it within the Act's meaning.
• An agent is not a legal person. Questions of knowledge and permission would therefore be assessed against the people and organizations behind the agent: in this design's terms, its principal and the delegation chain (Section 5.4).
• The Act can reach conduct affecting computers in California even when the actor is elsewhere. Canadian participants, including CAIP members (Appendix H), may therefore be exposed when their agents interact with systems in California.

I.3 Relevant elements of this design

#	Element	Sections	Relevance to the Act	Assessment
1	External action gateway, authorized action scopes, and high-consequence destinations	5.5, 13.9, 13.10	The Act turns on access "without permission". These are the Exchange's primary controls against agents acting outside what they are permitted to do	Supportive. Allowlisted destinations, scope checks, blocked and logged attempts, and human co-signature for high-consequence destinations reduce the risk of unauthorized access. An allowlist reflects the principal's authorization, not the destination owner's permission; destinations should be allowlisted only where the owner's permission (for example, terms of service, an API agreement, or a contract) has been established
2	Fetch-through library agents	13.1, 13.2, 13.3	Automated retrieval from websites raises the "without permission" question that has arisen in disputes over web scraping	Requires care. Fetch-through libraries should respect the destination's access conditions (for example, terms of use, robots.txt, and authentication barriers), and response records should note the basis on which content was retrieved. The preferences_observed field already recorded for training acquisitions (Section 14.12) could be extended to all fetches
3	White-hat testing and canaries	11.5, 19.1–19.5	Security testing of systems without their owners' permission could itself fall within the Act. The design's safe harbour (Section 19.4) is granted under the charter or federation agreement, which binds participants only	Requires change in practice. Testing of any system not owned by a consenting participant, including systems in or connected to California, requires explicit written authorization from that system's owner. Canaries are synthetic traffic within the Exchange and are lower-risk, provided they never reach third-party systems
4	Enclosed test environments	19.8–19.12	Testing against simulated systems avoids accessing real third-party systems	Supportive. Digital twins, mirror libraries, and role-players keep test activity inside one conference. The enclosure guarantee (Section 19.10) is what keeps this within the law; an enclosure failure that let test traffic reach a real system could create exposure
5	Diversion of suspected rogue agents	11.7, 19.13	Diverting an agent alters how its owner's system interacts with the world. The agent's operator could argue that diversion was an unauthorized interference with, or disruption of, its computer services	Requires a clear contractual basis. Participation agreements should state that the participant consents in advance to containment actions, including diversion, as a condition of participation. The existing safeguards (human decision, time limit, logging, notification, appeal) support the reasonableness of the action
6	Records, legal holds, and legal disclosure	12, 17.7–17.12	Exchange records would be evidence in criminal proceedings or civil claims under the Act	Supportive. Tamper-evident, independently custodied records, with chain-of-custody and custodian's certificates (Section 17.10), help both victims and accused participants. Holds and disclosures for California proceedings follow the processes in Sections 12.10 and 17.7–17.12
7	Jurisdiction	3.3, 16.3, 17.11; Appendix H	California becomes one more jurisdiction in the Exchange's legal mapping, alongside Canada	Requires mapping. The Act overlaps with U.S. federal law (for example, the Computer Fraud and Abuse Act) and has Canadian counterparts (for example, Criminal Code provisions on unauthorized use of a computer and mischief in relation to computer data). Cross-border conflicts follow Section 17.11. A U.S. National Approval Authority, or a California-specific arrangement, does not yet exist in the design

I.4 Observations

• The design's architecture is broadly consistent with the Act's purpose: mandatory mediation, scoped and logged actions, and independent records all work against unauthorized access.
• The main exposure points are where the Exchange itself, or its participants, touch systems outside the federation: fetch-through retrieval, white-hat testing, and actions at the gateway. In each case, the key question is whether the destination owner has given permission, which the design records only indirectly.
• Possible future revisions, for consideration only:
  1. record the permission basis (terms, contract, or API agreement) for each allowlisted destination and fetch-through source;
  2. require owner authorization for any white-hat test that reaches a system outside the federation;
  3. add an explicit advance consent to containment, including diversion, in participation agreements;
  4. add California, and U.S. federal computer-crime law, to the jurisdiction mapping alongside the Canadian instruments in Appendix H.7.

I.5 Verification required

Before relying on any part of this appendix, legal counsel should confirm:

• the current text of Penal Code section 502 and any recent amendments;
• how California courts have applied "access" and "without permission" to automated agents and web retrieval;
• the Act's territorial reach for actors outside California, including Canadian participants;
• the interaction with U.S. federal law and with Canadian criminal and privacy law;
• whether contractual consent and safe-harbour terms are effective against the Act's criminal and civil provisions.