AgentNet — Consolidated Specification

Status: Research-backed architecture with local implementation; production and accountable-owner gates remain open
Date: 2026-07-13
Scope: A separate, agent-agnostic extension for Claude, Codex, Pi, Antigravity, future harnesses, and standards-compliant A2A agents
Requirements baseline: requirements.md

1. Outcome

Build a domain-owned corporate agent communication network with:

a signed Device Communications Supervisor installed independently on every laptop or server;
thin, credential-free adapters for each agent harness;
one dedicated background communication worker per enrolled harness, isolated from active user conversations;
a transactional corporate core backed by highly available PostgreSQL and a provider-neutral immutable artifact store;
an explicit verified actor type on every event: business/protected submissions use a verified human or host guest plus exact harness; workload control facts and unadmitted A2A facts use restricted, visibly different authority chains;
user-level positive permissions, harness-level deny-only eligibility and attribution, and no authority transfer across human boundaries;
durable store-and-forward mailboxes, explicit receipts, at-least-once transport, idempotent processing, and first-class unknown-effect handling;
direct messages, tasks, threads, rooms, meetings, files, manager/subordinate relationships, groups, and server-agent-to-server-agent delivery;
an isolated native A2A gateway for public web-agent interoperability;
bilateral, host-controlled contractor federation;
managed server-service-visible content by default, with a separately approved MLS end-to-end-encrypted profile for sealed rooms;
deterministic security and protocol processing outside all LLMs, with isolated effect workers, human approval, quotas, and model-wake budgets.

This is not an MCP network. MCP is useful as one local harness binding where a harness natively supports it. The shared extension API is the supervisor’s authenticated local API. A2A is the external interoperability boundary. The internal corporate fabric uses purpose-built identity, authorization, messaging, room, file, receipt, and audit semantics.

The recommended first production profile is single-domain, single-region, Linux-first, managed-service-visible, mailbox-first, broker-free, and self-hosted on company-controlled infrastructure. The same ordinary AgentNet extension runs on laptops and always-on server agents; there is no separate Hub product, privileged Hub identity, or second package. Production may deploy redundant instances of the server-agent roles and storage rather than trusting one physical machine. JetStream, Kafka, SPIFFE/SPIRE, MLS, SCITT, multilateral federation, and multi-region active-active are triggered upgrades, not launch dependencies.

No external managed infrastructure is mandatory. “Object storage” means a provider-neutral artifact interface, not AWS S3: a pilot may use a hardened filesystem-backed content-addressed store, and production may use a self-hosted replicated object store. AWS S3, Cloudflare R2, Azure Blob, or Google Cloud Storage are optional owner-selected adapters. Corporate identity may use an existing or self-hosted OIDC provider. External connectivity is necessary only for capabilities the owner deliberately enables, such as public A2A peers, partner domains, or remote model providers.

Implementation is reuse-first, not greenfield-first. The project owns its corporate authority model and integration contracts, but should adopt maintained, audited implementations for discovery, transport, workload identity, room synchronization, cryptography, policy evaluation, storage, and workflow recovery whenever they pass the same gates. The rule is: reuse mechanisms; retain policy ownership. No component is adopted merely because its vocabulary resembles the design, and no custom replacement is written before a documented bake-off shows that existing choices cannot satisfy the required semantics safely and operably.

2. Evidence and decision language

The brainstorm used three independent research passes, three cross-critiques, a merged dispute register, fresh re-research of every material dispute, three convergence memos, and an adversarial audit-and-correction cycle. Final audit artifacts and their sealed verdicts are recorded only after the corrected bytes are re-reviewed.

Verified: established by a current primary specification, official product documentation, or dated local read-only probe.
External-evidence-gated: the local design or implementation exists, but required target-environment tests, benchmarks, or independent evidence remain open.
Owner policy: research establishes the tradeoff, but an accountable human owner must approve the value or behavior.
Design-covered: the architecture answers a requirement; it does not mean code exists or that release acceptance has passed.

Authoritative research artifacts:

3. Non-negotiable invariants

No claimed identity is trusted. Email, user ID, harness ID, role, manager, capability, and domain fields in a payload are untrusted until bound to authenticated security context.
Every business submission resolves both identities: the responsible verified human or host-local guest and the exact originating harness. Service-owned receipts and deterministic control facts use a scoped workload identity and may assert only facts that workload owns; any service data access or effect references an authorized parent human event or exact task grant. Unknown public A2A actors are labeled external-human-unverified and are never displayed as corporate participants.
Positive authority belongs to the human principal. A harness, session, subagent, delegation, task, or management edge can only preserve or reduce that ceiling.
Management is not data authority. Administering, supervising, sponsoring, moderating, or assigning another agent does not inherit that other human’s permissions.
No authority crosses the human boundary. Delegating work never delegates data access.
Protected access fails closed on missing, ambiguous, stale, revoked, inconsistent, or insufficient identity, policy, grant, room, guest, or credential state.
Routine agent communication never changes an active user conversation. It cannot inject context, create turns, steal focus, prompt for permission, or take over input.
The foreground indicator is content-free and optional. If a harness lacks a safe passive surface, the correct fallback is no indicator.
Protocol state never lives only in an LLM transcript. Worker death, compaction, restart, or context loss cannot lose accepted communication.
Authentication does not make content trustworthy. A signed peer can still send prompt injection, malware, false claims, or costly loops.
A receipt proves only what its signer owns. Missing evidence is unknown, not success.
No false exactly-once claim. Transport is at least once; idempotency and reconciliation provide safe effects where possible.
No false durable claim. The state name must match the tested durability boundary.
External A2A identity is not corporate identity. Public peers remain low trust until separately admitted through corporate onboarding.
Federation is bilateral and non-transitive. Trust from A to B cannot create trust from B to C.
Human consent is independent of the requesting harness. Peer or model content may request approval but can never satisfy it. Independence is an authentication property, not a mandatory extra-host topology.
A separate conversation is not a sandbox. A semantic worker may process hostile content only inside the enforceable clean-worker launch profile; otherwise that harness is restricted to deterministic protocol handling.

4. Architecture

Human/workforce authority                   Independent human approval
OIDC (issuer, subject) + email alias         WebAuthn + exact transaction
             |                                          |
             +------------- Enrollment Authority -------+
                                      |
Device trust zone                    |                 Corporate trust domain
+----------------------------------+  |  +--------------------------------------+
| Device Communications Supervisor|--+->| Edge/API policy enforcement point     |
| - encrypted local inbox/outbox   | DPoP| - verified human+harness resolution |
| - key/credential broker          |     | - replay, schema, SSRF, quota gates  |
| - deterministic dispatcher      |     +------------------+-------------------+
| - cursor/dedup/replay state      |                        |
| - budgets and worker control     |     +------------------v-------------------+
|       |                          |     | Transactional Corporate Core         |
| zero-secret harness adapters     |     | identity / policy / relationships    |
|       |                          |     | mailbox / rooms / tasks / receipts   |
| dedicated comms workers          |     | audit intents / transactional outbox |
+----------------------------------+     +----+--------------+--------------+----+
                                            |              |              |
                                      +-----v------+ +-----v------+ +-----v-----+
                                      | Artifact   | | Effect /   | | Audit     |
                                      | service    | | active     | | exporter  |
                                      +-----+------+ | agent      | +-----+-----+
                                            |        +------------+       |
                                      +-----v------+                  independent
                                      | Scanner /  |                  WORM/witness
                                      | transformer|
                                      +------------+

External zone: Public A2A gateway --- typed low-trust API ---> Corporate Core
Partner zone:  Federation gateway --- host-local guest API --> Corporate Core

4.1 Device Communications Supervisor

One independently installable, signed supervisor runs per machine. It owns:

an encrypted crash-safe local inbox/outbox, preferably SQLite with WAL and explicit fsync tests;
one domain-local binding for every enrolled harness installation;
secure credential use and rotation;
authenticated local IPC and adapter capability tokens;
durable cursors, replay state, deduplication, reconnect, and backoff;
deterministic receipt, presence, retry, expiry, cancellation, and capability handling;
one dedicated background communication worker per harness;
per-peer, room, recipient, and causal-chain budgets;
content-free activity counts for safe harness UI surfaces;
explicit inbox/read commands initiated by the human.

The supervisor is a lifecycle and credential-containment boundary. A process owned by the same desktop user is not assumed to be a strong adversarial boundary. Prefer supervisor-inherited anonymous capabilities, distinct OS identities, LSM labels, containers, or measured/code-bound launch evidence. Every event records binding_assurance and compromise_domain_id. If hostile same-user tests cannot prove exact adapter binding, that harness may only draft locally, show content after an explicit human open, and perform deterministic non-business protocol control. It may not originate any protected business message, task, room/file action, read, download, key release, export, disclosure, or effect in Phase 1. GA support requires a tested inherited anonymous capability plus process/ptrace/proc-dump restrictions and an OS/LSM/measurement boundary. Human approval cannot reconstruct an unprovable originating harness.

4.2 Harness adapters

Adapters are thin shims. They contain no long-lived corporate token or private key, do not decide authorization, and do not own protocol truth. The supervisor binds harness identity from authenticated IPC and the launched worker context, not from tool arguments or model prose.

4.2.1 Clean-worker launch profile

A dedicated thread protects foreground UX but does not itself isolate hostile content. Before any harness may process the semantic lane, the supervisor must create a version-specific clean worker with:

a new empty non-user workspace and sanitized HOME, environment, current directory, and session store;
no inherited project AGENTS.md, CLAUDE.md, hooks, plugins, skills, MCP configuration, startup scripts, shell profile, or workspace code; exactly one supervisor-provided fixed-schema binding is permitted;
no shell, arbitrary filesystem, desktop keychain/secret store, browser session, vendor credential, local socket enumeration, or unrestricted process access;
no arbitrary network or DNS; only the authenticated supervisor sidecar and explicitly allowlisted model endpoint;
a distinct OS identity or container plus LSM/seccomp or platform equivalent when the harness cannot enforce a model-only tool profile;
read/write/secret/IPC/process/DNS/network escape tests pinned to the exact harness version.

The worker receives only tainted message inputs, allowed reference bytes, an attenuated task grant, and fixed-schema supervisor tools. Pi may process hostile semantic content only after an OS sandbox or genuinely model-only profile passes. Any harness that cannot meet this profile remains useful for deterministic protocol handling and explicit human-opened viewing, but cannot autonomously process untrusted semantic content or perform effects.

The clean worker receives no vendor credential or user auth state. A supervisor-owned model-egress broker alone holds upstream authentication. It accepts only framed inference requests bound to one worker, exact task grant, allowed model, token/spend budget, and clean profile; exposes no generic proxy, connector, or tool; strips upstream credentials; returns only model output; and logs/revokes a short-lived worker capability. Each adapter must prove its exact broker/auth path. If a harness cannot target the broker without reading user auth/session state, it is deterministic-only.

4.3 Transactional Corporate Core

The core is initially a modular application with one authoritative PostgreSQL transaction boundary for:

human, harness, workload, guest, credential, and domain identities;
management and room relationships;
Cedar entity snapshots, policy versions, and decisions;
temporary grants and approval consumption;
message, task, room, recipient, and delivery states;
idempotency keys and payload-digest conflicts;
receipt references and effect reservations;
artifact metadata and provenance references;
transactional outbox rows;
transactionally complete audit intents for mutations mediated by the core.

Logical trust roles stay separate even when modules share a deployment. In the default self-hosted profile, Core, PostgreSQL, and approval may share the existing server under distinct OS identities, credentials, storage, and loopback services; the human WebAuthn authenticator remains outside the enrolling harness. Scanner, effect worker, public gateway, federation gateway, authority keys, and audit witness retain their explicit role boundaries. A separately administered approval host is an optional high-assurance profile, not an ordinary-onboarding prerequisite.

4.4 Object, scanner, effect, and audit services

Artifact service: immutable versions, encrypted quarantine/released namespaces, digest addressing, lifecycle, quota, retention, and optional legal hold.
Scanner/transformer: isolated workload with bounded parsers, decompression, CPU, memory, egress, and no release authority. It signs digest-bound scan and derivation attestations.
Effect/active-agent worker: receives only typed, currently authorized jobs. It cannot grant access, approve itself, rewrite receipts, or access issuer/audit keys.
Audit exporter: publishes core-mediated transactional audit intents to an independently administered append-only or WORM sink with signed checkpoints and witnesses.

Audit assurance is bounded. A witness detects later alteration, sequence gaps, stalls, or inconsistent checkpoints; it cannot prove that a compromised core, PDP, issuer/KMS, approval service, database administrator, or object-store administrator submitted every real event. These are catastrophic trust roots. Unmediated protected database/object mutations are prohibited; independent IdP, KMS, database, object, network, approval, and gateway logs are reconciled. Use purpose-specific origin signatures where authenticity must survive a compromised accepting server role.

Before any sensitive disclosure, preview, C2 decrypt, export, download-capability issuance, or decryption-key release, the core transactionally commits a digest-linked access-decision/audit intent containing current policy, entity, grant, actor, harness/workload, credential, and data-class epochs. If the audit intent or bounded publication policy cannot accept it, the read/disclosure is held. No sensitive bytes, capability, or key are released first.

After core compromise, quarantine the affected epoch, stop protected effects and new authority, preserve and compare independent logs/checkpoints, rotate/rebind authority keys, rebuild from verified backups plus external evidence, and require explicit adjudication before releasing uncertain events.

4.5 Gateways

Public A2A gateway: separate network/process identity, low-trust queue, restricted egress, and no broad database, tool, KMS, or object-store authority.
Federation gateway: separate partner-facing identity and policy boundary; disabled until contractor and revocation gates pass.

5. Harness capability and adapter plan

The research baseline was locally reinspected on 2026-07-13 at Claude Code 2.1.207, Codex CLI 0.144.3, Pi 0.80.6, and Antigravity CLI 1.1.1. These exact observations are dated evidence, not permanent product contracts. Every version change reruns the adapter suite.

Harness	Dedicated background path	Passive foreground behavior	Important gate/fallback
Claude	Supervisor drives a dedicated Agent SDK or headless claude worker. An organization-approved Channel over stdio may feed only a dedicated communication session.	Content-free statusline count.	Custom Channels are preview/allowlist constrained. Do not require a dangerous development flag in production; use headless worker until approved. Never expose remote permission relay.
Codex	Supervisor starts codex app-server over stdio/private Unix socket, creates or resumes a dedicated thread, and starts semantic turns only there.	No verified in-TUI passive badge; show nothing by default.	Independently deny or route worker approval requests. Do not depend on experimental non-loopback or process APIs.
Pi	Supervisor starts pi --mode rpc with a separate session directory and strict JSONL framing.	Credential-free extension may show content-free setStatus/widget/footer.	Pi intentionally has no native MCP client and no sandbox. Use direct authenticated IPC. Never send routine steer, followUp, nextTurn, or user-message content into the foreground.
Antigravity	Supervisor serializes agy --conversation with a dedicated conversation and noninteractive prompts.	Built-in background-task indicator only if reproduced safely; otherwise nothing.	Persistent push, resume, cost, permission routing, and status mapping remain external-evidence-gated. AX gRPC is a later adapter candidate, not A2A.

5.1 UX decision

Routine automatic “digest on the next user turn” is rejected as the default. Although all four harnesses expose mechanisms that can add context to a user-initiated turn, doing so still changes the active model context and creates a prompt-injection and attention leak.

The compliant model is:

agent communication is received and processed in a dedicated background worker;
the foreground may display only a passive, non-modal count or activity state;
where no safe indicator exists, display nothing;
content enters a foreground session only after the user explicitly opens or reads the inbox;
exceptional approval/security/failure notifications use the separately approved PD-011 policy and contain no message content by default.

For Codex at the researched version, this means explicit-pull only: no compliant passive in-TUI indicator was verified, so UX-003 remains unmet on that harness while UX-001/002/004 stay protected. A non-blocking probe may test a supervisor-owned terminal title or tmux status segment with content-free count, provided escape-sequence/TUI behavior cannot corrupt or distract the session. Codex cloud tasks are a verified future offload option, but they are not the durable mailbox, identity, receipt, or foreground-notification path.

6. Protocol roles

6.1 Native A2A

A2A is the standards-compliant public interoperability boundary, not the internal corporate network.

This is the explicit ARC-004 interpretation: each enrolled agent can communicate with native A2A peers through the domain gateway acting on that agent’s behalf. The four harnesses do not each embed an independent A2A stack. Centralizing the native client/server implementation preserves agent-level interoperability while enforcing ARC-005/006 consistently. If the owner instead requires direct per-harness wire participation, that is a materially different deployment and security requirement.

Pin the A2A v1.0.1 release and normative proto; the wire version is 1.0.
Missing or empty version maps to legacy 0.3 and is rejected on the protected v1 endpoint. No silent downgrade.
If legacy support becomes necessary, isolate hostname/path, credentials, audience, queues, policy, and telemetry.
Support tested Message, Task, Artifact, streaming/subscription, push, discovery, and authentication mappings.
Every unknown peer begins as external-low-trust.
An Agent Card is self-asserted discovery metadata. A valid signature under a locally trusted, current registry key authenticates the canonical card bytes only; it grants no membership, human identity, authority, tool access, or rollover. Card signatures are optional in native A2A.
Protected partners require an administrator-curated registry of endpoint, key thumbprints, algorithms, owner, audience, status, rollover authority, review date, and incident contact.
Card-provided key URLs are never automatic trust bootstrap.
Foreign IDs remain in an A2A namespace and never become corporate principal IDs.
Cards, callbacks, push URLs, and file URLs receive SSRF-safe fetch controls, redirect/DNS/IP revalidation, allowlists, and size/time limits.
Run the pinned A2A TCK plus negative security, downgrade, key-rotation, cache, tenant-spoofing, task-enumeration, cross-SDK, webhook, and artifact tests. TCK success alone is not a security certification.

Recommended gateway SDK order is stable Go or Python after cross-SDK tests, then Java where appropriate. JavaScript v1 and .NET v1 surfaces were not mature enough at the research cutoff to be the only production dependency.

Phase-1 binding profile: the gateway client and server implement and advertise HTTP+JSON and JSON-RPC over HTTPS with A2A wire version 1.0; HTTP+JSON is preferred when both peers advertise it. gRPC is optional until its SDK/TCK path graduates. A missing binding intersection, wrong media type, unsupported version, or unadvertised binding fails explicitly—never by downgrade or heuristic transcoding. Each exported logical agent has its own standards-compliant Agent Card/profile and supportedInterfaces under an authorization-filtered gateway route; optional tenant routing is never identity or authority.

Corporate-to-A2A profile

Concern	Normative gateway behavior
Logical-agent addressability	Each exported logical agent has an authorization-filtered opaque route and standards-compliant Agent Card/supportedInterfaces under the domain gateway; it never exposes the corporate directory. Publishing the route creates a standing, scoped, revocable exact task grant: source class external-low-trust, allowlisted actions/resources/sinks, budget, expiry, and revocation handle. No grant means no exported route.
Client role	An outbound authorized internal event creates an A2A client operation under a gateway credential scoped to the remote origin/resource. Corporate tokens and human credentials never cross the gateway.
Server role	An inbound A2A request terminates at the low-trust gateway actor. It does not run as the target human or harness and cannot access internal tools/data until a separately typed, currently authorized internal task is created.
Message mapping	Internal conversational content maps to an A2A Message with namespaced IDs and typed/text/file Parts. Inbound Message content is inert/tainted semantic input; metadata and extensions never grant authority.
SendMessage result	SendMessage may return a server-owned Task or a direct Message. A Task maps to the internal task projection. A direct Message maps to one remote-response fact without synthesizing a Task, Artifact, completion, durable recoverability, or GetTask handle.
Task states	submitted, working, input-required, auth-required, completed, failed, canceled, and rejected map to separate internal facts. TASK_STATE_UNSPECIFIED maps to remote_state_unknown plus quarantine/no effect or completion. input-required/auth-required never trigger automatic approval or credential disclosure.
Artifact mapping	An A2A Artifact is treated only as task output. Uploaded/request files arrive as Message Parts and enter quarantine. Every byte, digest, size, media type, and object version is verified before use.
Context and IDs	contextId, taskId, messageId, extension IDs, and correlation fields are opaque, origin-namespaced context only. They are never corporate principal, room, grant, or idempotency authority.
Roles	user and agent roles map to explicit external actor directions. ROLE_UNSPECIFIED is rejected/quarantined and cannot create work, authority, or participant identity.
Push/streaming	Authenticated push or streaming is a wake hint. Map every StreamResponse variant separately: Task, direct Message, TaskStatusUpdateEvent, and TaskArtifactUpdateEvent. Task-bearing gaps reconcile through GetTask; a lost direct-Message stream is remote_response_unknown/incomplete and is never called GetTask-recoverable. Callbacks are deduplicated and verify origin/audience/replay.
Authentication	Exact card securityRequirements select a locally allowed scheme. OAuth uses exact resource/audience and credential-origin confinement; mTLS uses the curated peer registry. Credentials are acquired out of band and stripped before internal forwarding.
Unknown peer	Actor is external-human-unverified plus verified network/provider facts, not a corporate human. Corporate participant display and positive authority require a separate host admission ceremony.

Gate 4 includes HTTP+JSON/JSON-RPC interface advertisement and preference, binding/media/version mismatch, per-agent Card/route and tenant mismatch, standing-grant revocation, Task versus direct-Message results, all StreamResponse variants, unspecified role/state, server-owned Task IDs, input/auth-required behavior, artifact direction, Task push duplication/gap recovery, direct-Message stream loss, credential-origin confinement, and cross-SDK tests in addition to the TCK.

6.2 MCP

MCP is an optional local tool/context binding:

depend on stable MCP 2025-11-25 until a later revision is final and implemented;
Claude, Codex, and Antigravity may bind explicit local tools through MCP;
Pi uses direct authenticated extension IPC;
MCP's optional transport authorization and experimental Tasks are insufficient for this corporate human-plus-harness identity, room, federation, consent, and durable peer-mailbox model; MCP remains a local tool/resource/context binding;
caller identity comes from the authenticated local adapter/session and network token context, never model-supplied tool arguments;
corporate or A2A bearer tokens never pass through an MCP server;
vendor extensions such as Claude Channels remain vendor-specific adapters.

6.3 Internal protocol

The internal protocol is a versioned, typed corporate API over TLS plus DPoP or workload mTLS. It uses:

immutable submission and event objects;
separate domain-owned receipts;
typed room, task, relationship, grant, presence, artifact, and policy objects;
cursor-based mailbox reconciliation;
explicit schema negotiation and declared capability downgrades;
opaque internal IDs scoped to a trust domain;
authenticated local IPC between harness shim and supervisor.

6.4 Authenticated internal discovery

The core owns an authorization-filtered directory for internal agents/harnesses, hubs/services, rooms, trust domains, approved endpoints, adapter/profile versions, and capabilities.

Every record has a stable opaque ID, actor/resource type, owner domain, profile and schema version, status/key/endpoint epoch, validity/freshness, accountable owner, current key and endpoint references, capability authority, and review date. List/get is non-enumerating: unauthorized callers receive a non-disclosing result rather than a global employee, agent, room, or service list.

Enrollment and trust status, crypto/profile support, endpoint origin, scanner/effect-worker class, and other security facts come only from the authoritative registry plus active conformance probes. Self-advertised capabilities are bounded-freshness routing hints that may affect batching or presentation but never grant identity, permission, assurance, file release, or tool scope. Current revocation/key/endpoint epochs override all caches.

6.5 Version negotiation, rolling upgrades, and configuration portability

Every connection performs an authenticated profile handshake carrying protocol ranges, schema/profile IDs and hashes, critical extensions, feature set, adapter version, and status epoch. Select the highest mutually allowed profile. Reject unknown major versions, unknown critical fields, and any downgrade of identity, authorization, durability, audit, isolation, or crypto floor. Unsupported event types remain queued or receive an explicit typed rejection; intermediaries never strip unknown signed fields.

The core supports a declared N/N-1 read/write window and an expand → migrate/backfill → verify → contract database sequence. Rollback is allowed only within the declared compatibility window and never rolls back revocation/security state. Deprecation, cache invalidation, mixed-version receipt behavior, and partially capable adapters are versioned policy.

AgentNet's immutable first release starts at storage schema version 1 with one complete checksum-bound authority migration. Current unreleased source has a contiguous four-migration Core catalog: migration 2 adds the protected task-payload disclosure receipt, migration 3 adds guided OIDC enrollment continuation, and migration 4 adds the bounded C0 bootstrap-plan contract. Fresh SQLite and PostgreSQL stores initialize v4 atomically; the declared N/N-1 Core path upgrades only an exact metadata/catalog/checksum/object-verified v3 store to v4 and commits the migration atomically or not at all. Altered, prototype, noncontiguous, future, or unsupported older state fails closed.

No pre-release or differently named database is an authority source, and no conversion infers bilateral consent from a unilateral edge. Operator moving exploratory data exports only reviewed non-authority content, initializes a fresh current store, and obtains fresh exact consent. Rollback may restore only an exact signed, verified compatible backup and cannot downgrade metadata, synthesize, or reactivate relationship authority.

Configuration uses a portable versioned schema split into:

redacted non-secret domain, endpoint, policy-profile, quota, and UI configuration that may be exported/imported;
device/domain secrets and private keys that are never exported and must be rebound through enrollment;
migration validation that fails on unknown security settings or unsupported profiles.

Pin exact A2A/MCP specifications, SDK releases, TCK commit/report, internal profile hashes, and adapter versions in the release manifest. Mixed-version, downgrade, partial-adapter, config-migration, and rollback tests are required.

6.6 Reuse-first component strategy

The corporate supervisor and governance integration remain the novel product boundary. Established components are candidates behind narrow, replaceable interfaces:

Need	Reuse candidate	Mandatory corporate boundary
External agent interoperability	A2A SDKs and TCK	Gateway mapping cannot promote public identity or equate A2A task state with internal effect evidence.
Capability descriptions	AGNTCY OASF	Imported descriptions are untrusted discovery metadata, never authority.
Agent discovery	AGNTCY Directory	Results pass authorization-filtered, non-enumerating corporate discovery and current key/revocation checks.
Secure agent transport	AGNTCY SLIM	Evaluate as a transport only; corporate actor binding, mailbox custody, receipt ownership, offline semantics, and authorization remain ours.
Reference integration	CoffeeAGNTCY and official component SDKs	Use for laboratory evaluation and interoperability evidence, not as production trust proof.
Human rooms, device sync, and UI	Matrix clients/bridges or isolated room components	Matrix power levels, federation, event DAG, and delivery state do not become corporate authority or business-effect truth.
Sealed-room cryptography	Maintained audited MLS implementation, including one already used by a selected transport	Corporate membership, provider disclosure, recovery, retention, and metadata policy remain explicit. Never implement cryptographic primitives locally.
Server workload identity	SPIFFE/SPIRE where a real managed workload fleet justifies it	Human identity and harness ownership remain separate; laptops are not forced into SPIRE.
Human authentication	OIDC and WebAuthn implementations	Corporate principal mapping, independent approval ceremony, recovery, and transaction binding remain ours.
Authorization evaluation	Cedar initially; OpenFGA/SpiceDB only as a measured replacement	Exactly one positive authority and one coherent revision model.
Durable transactional state	PostgreSQL	Corporate state names and durability claims follow tested commit boundaries.
Artifact bytes	Existing self-hosted filesystem/object-store implementations behind `ArtifactStore`	PostgreSQL manifest, quarantine, provenance, scan, authorization, retention, and release state remain authoritative.
Local tools	MCP where the harness supports it	MCP arguments or tokens never establish corporate caller identity.
Long-running effect recovery	Temporal-style engine if complexity/benchmarks justify it	Workflow success cannot fabricate delivery, authorization, or external effect evidence.

Every candidate must be pinned and evaluated for maintenance, license, supply chain, self-hosting, data egress, API stability, resource cost, upgrade/rollback, failure behavior, identity model, tenant isolation, enumeration, offline recovery, duplicate delivery, revocation timing, and operational ownership. A component is accepted only when it maps cleanly into the canonical schemas and must-not-ship gates. Adapters preserve the ability to replace it without migrating corporate identity or rewriting signed history.

7. Identity, onboarding, and credentials

7.1 Identity model

principal_id: immutable opaque ID local to a corporate trust domain, mapped to OIDC issuer and subject.
verified email: required visible identity/contact alias with history; not globally sufficient authorization.
harness_id: exact enrolled installation/profile in one domain; independently revocable.
credential_id and key epoch: rotatable proof material for that harness/domain.
session/subagent_id: attributable child identity that can only attenuate its parent ceiling.
workload_id: server service or active-agent identity, separate from a human.
guest_id: host-local contractor identity, separate for every host network.

This refines the initial “permissions by user email” requirement without abandoning it: the human remains visibly and durably tied to the verified corporate email, but authority uses a non-reassignable internal principal keyed by domain and IdP subject. Raw email reuse, rename, merger, or reassignment cannot silently transfer authority.

Actor types are explicit:

Actor	May originate	Required authority chain	Participant display
Verified human + harness	Business messages, tasks, room/file actions, task grants	Current human entitlement ∩ harness eligibility ∩ task/resource policy	Host/room-scoped verified human label, domain, harness; email only to authorized directory/audit viewers
Host-local guest + harness	Host-scoped business actions	Current host guest grant ∩ harness eligibility ∩ host policy	Pairwise host label, home domain where policy permits, harness
Workload/service	Receipts and deterministic control facts it owns	Workload credential and exact role; data/effect work also references parent human event or task grant	Service role and domain; never fabricated human
External A2A peer	Low-trust protocol submissions	Verified network/provider facts only until admission	external-human-unverified; not a corporate participant

7.2 Enrollment ceremony

The signed supervisor connects to the exact TLS enrollment origin and receives a short-lived nonce plus exact transaction transcript.
It generates a distinct per-domain, per-harness P-256 candidate key in the strongest available platform store and proves possession over the nonce and transcript.
The human authenticates in the system browser using OIDC Authorization Code + PKCE, state, and nonce. Embedded webviews are forbidden.
The server validates issuer, audience, subject, workforce/contractor status, assurance, nonce, expiry, and proof of possession. Authorization-response parsing rejects every duplicate decoded parameter name and mixed or incomplete success/error shape, while ignoring only unique unrecognized OAuth response extensions. A provider error can terminally consume only the exact state-bound pending transaction and never reaches token exchange.
A pre-bound approval service shows the exact typed transaction: domain, human, beneficiary harness/device, key thumbprint, requested class, nonce, and expiry. The confirmation uses an owner-controlled WebAuthn authenticator that the enrolling harness cannot read or automate. The default self-hosted profile may colocate the approval service with Core under a distinct OS identity, credential, storage root, and loopback service; it reports independent_boundary_proven=false. A separately administered host/device/security boundary is the optional high-assurance profile. Slack, Telegram, email, or another authenticated channel may carry a human prompt only when the enrolling harness cannot read, approve, or automate that channel; no such channel is required when the same owner directly uses the approval UI and fresh laptop.
The human approves exact transaction after fresh phishing-resistant authentication but transfers no completion value. Exact waiting process retains private Core continuation/begin state. Core derives a transaction-specific OIDC Approval possession secret or generates and encrypts a distinct high-entropy bootstrap secret, sends only that secret's SHA-256 hash when creating Approval request, and later retrieves through signed broker using exact purpose-separated secret. Approval enforces expiry, cumulative mismatch attempts, replay custody, and retrieval-digest conflict checks; browser receives no secret, code, receipt, or capability. Approval service binds random challenge, canonical transaction hash, beneficiary, approver, domain, and expiry; verifies RP ID, origin, user verification, and credential status; consumes challenge once; and signs immutable approval receipt. This proves ceremony and transaction binding, not human comprehension or a trusted display on a compromised enrolling host. A notification click, agent message, auto-readable bot response, or browser session alone is insufficient.
The enrollment service atomically binds principal, harness, key, assurance tier, domain, validity, approval evidence, and audit intent.
It issues opaque, stateful, short-lived DPoP-bound access credentials plus a rotating refresh family. Bearer downgrade is rejected.

The agent connection, a submitted email, copied public ID, chat text, or possession of another harness’s token cannot complete enrollment.

The default colocated profile satisfies ID-002 through human authentication independent of the enrolling harness, but does not claim independent administration and must retain independent_boundary_proven=false. It may run bounded ordinary onboarding and C0 tests under the recorded owner policy. Production-independent, high-impact, or stronger assurance claims require the optional separately administered profile and its external evidence. Synthetic flows without real OIDC, candidate-key proof, WebAuthn UV, or exact possession-bound broker delivery remain noncompliant and cannot be promoted.

7.3 Credential lifecycle

Generate distinct keys per domain and harness; never clone sibling harness identity.
Prefer hardware-backed non-exportable custody where proven; label software/OS-user-protected custody honestly.
DPoP sender-constrains access tokens; it does not itself sign message bodies or authorize effects.
Rotate refresh families, access tokens, and key epochs; retain alias/key history for audit.
Device loss or key loss creates a new binding after reauthentication and recovery; it does not restore the old private key.
Harness revocation invalidates that harness and key epoch while siblings remain enrolled.
Human offboarding revokes positive authority and all harnesses, guests, grants, memberships, and pending protected effects according to the event-specific matrix.
Compromise creates a quarantine window, rotates credentials, blocks protected work, and triggers incident review.
Offline submissions remain encrypted local drafts until accepted after current authentication and authorization.

Same-domain ordinary managed messages need DPoP authentication plus a server-signed durable acceptance receipt. A separate durable origin signature is required for federation, sealed E2EE, protected offline commands, untrusted relays, approval/control evidence not already signed by the approval service, or explicit legal/evidence classes.

When compromise time is uncertain, compromised_from is the earliest credible compromise or last-confirmed-good boundary selected by incident response. Uncertainty widens rather than narrows the quarantine window. Record source, confidence, adjudicator, affected credential/key epochs, and signed release/reject decisions.

7.4 Freshness and cryptographic key profile

AgentNet publishes a versioned profile for enrollment, access-token DPoP, origin objects, callbacks, federation, approvals, receipts, and local IPC. Numeric values remain accountable-owner inputs under PD-009/010, but boundedness is normative.

Algorithms and canonical input: explicit allowed algorithms/key sizes and exact typed preimages; unknown critical fields or algorithms fail closed.
Proof age and clock: maximum past age, bounded future skew, monotonic/server-corrected clock behavior, clock-health alarm, and no indefinite skew widening.
Nonce/jti: high-entropy server nonce where required, one-time use, minimum jti entropy, deterministic duplicate denial, replicated/persistent cache for the entire acceptance/retry window.
Sequences and idempotency: actor/operation/recipient scope, accepted windows, gap behavior, and dedup retention longer than every retry/replay window.
Key epochs: activation, overlap, rotation, compromise, offline use, historical verification, and deterministic unknown/stale-key behavior.
Failure: clock rollback, cache loss/partition, nonce-service outage, or state uncertainty denies protected operations while safe drafting and deterministic diagnostics remain.

Key hierarchy:

TLS 1.3 preferred and TLS 1.2 minimum only with an approved cipher/certificate profile; exact hostname/origin and mTLS identity validation;
per-device local queue keys protected by the advertised platform custody tier;
per-object/message DEKs scoped at least to domain, tenant, and confidentiality class, wrapped by separately administered KEKs;
explicit decrypt ACLs for mailbox, C2 enclave, scanner, effect worker, backup/restore, and legal-hold roles;
distinct issuer, receipt, approval, federation, audit, scanner, update, and MLS key purposes;
rotation/overlap/revocation/compromise schedules plus historical public-key retention;
encrypted backup-key recovery, restore tests, and honest crypto-erasure limits for replicas, backups, downloaded, and federated copies.

KMS outage never falls back to a raw application key. Downgrade, substitution, stale key, cross-class decrypt, offline rotation, backup restore, and compromise rebuild are release tests.

8. Authorization, administration, and delegation

8.1 One authorization authority

Use one Cedar-based policy decision service over one transactional PostgreSQL entity snapshot, subject to correctness and scale benchmarks.

Request tuple: verified principal, action, resource, and typed context.
Positive entitlements attach only to the human principal.
Harness, device, session, credential, assurance, classification, and capability are deny-only eligibility constraints.
Missing state, schema failure, policy diagnostics, stale revision, or authority outage denies protected operations.
Every decision records reason, determining policy, policy/schema/entity revision, principal, harness, session, credential/grant epoch, domain, and resource.
Do not run Cedar and OpenFGA as two independent positive authorities. If Cedar fails measured graph/list/causal requirements, replace it with one OpenFGA or SpiceDB authority and preserve a single revision model.

8.2 Organizational graph

Represent administers, supervises, sponsor_of, assigned_work, moderates, owns, and member_of as explicit typed, time-bounded relations. The graph supports multiple administrators and multiple subordinates without becoming a permission tree. An administration edge is authority-bearing only while its bilateral governance transaction is active; a proposed, expired, revoked, rejected, or superseded record has no relationship authority.

Relations grant only explicit meta-actions such as assign, observe allowed status, cancel under policy, invite, moderate, or approve. They never reveal another human’s protected data automatically.

Implemented bilateral activation: the exact owner of the proposed administrator harness (human principal or host-local guest), acting through that harness and holding organization.relationship.propose, may create a proposal. The canonical transaction binds both endpoint harnesses, both current owner kinds and IDs, both credential epochs, exact terms and relationship revision, proposal/relationship expiries, policy and domain-revocation epochs, and the predecessor snapshot. Proposal creation is idempotent only for the same bytes and has zero authority.

Normal activation requires a fresh one-use receipt verified by the configured IndependentApprovalVerifier for the exact purpose organization.relationship.accept. The verifier-derived approver kind and ID must equal the current subordinate harness owner (human or guest). The activation caller must also be a current exact participant. Caller JSON cannot assert an actor, a verified result, or policy-decision evidence. Every bound owner, credential, policy, domain, predecessor, digest, revision, and expiry is rechecked in the activation transaction.

Either activation basis also requires one exact local activation audit intent. Before the owner receipt or recorded exception is consumed, the same database transaction inserts a pending intent whose digest binds the canonical relationship transaction and digest, relationship and lifecycle revisions, proposed to active transition, activation basis and transport-derived activation actor, exact receipt or exception evidence, activation time, and custody-only authority effect. The edge compare-and-swap and evidence consumption occur in that transaction, and the intent is completed at the exact activation time before commit. A persisted active edge supplies no assignment authority if this completed intent is missing, pending, malformed, noncanonical, stale, or inconsistent with the edge or evidence.

This activation intent is durable local provenance, not an independent external witness. A fully coherent compromise of the application database can forge or erase the edge and local intent together. Production audit claims therefore still require the separately administered export/checkpoint/witness and reconciliation evidence described in §4.4 and gates 13, 16, and 19.

The authenticated HTTP flow is:

Route	Strict request	Result
`POST /v1/relationships`	relationship plus proposal expiry	`201` zero-authority `proposal`
`POST /v1/relationships/{relationship_id}/accept`	strict approval receipt plus expected transaction digest, relationship revision, and lifecycle revision	active edge only after exact current subordinate-owner consent
`POST /v1/relationships/{relationship_id}/policy-exceptions`	exact exception plus signed authority command	records bounded evidence; does not activate
`POST /v1/relationships/{relationship_id}/policy-exceptions/activate`	exception ID plus expected digest/revisions	one-time exact exception consumption and activation
`GET /v1/relationships/{relationship_id}`	participant read, or separately entitled administrative read	non-enumerating read
`POST /v1/relationships/{relationship_id}/revoke`	exact signed command at current lifecycle revision	endpoint exit/revoke or separately entitled admin-revoke mechanism

All relationship bodies forbid unknown fields. Actors come only from the authenticated transport, and successful/handled-error relationship responses are no-store.

Normative assignment direction: every active administers/supervises edge may carry an explicit may_assign action and an assignment_scope covering permitted task types, resources, data classes, tools, budgets, deadlines, concurrency, and expiry. A task from the authenticated administrator endpoint to the subordinate endpoint is automatically accepted into the subordinate's durable task mailbox only when it matches that current edge and scope. The acceptance fact is accepted_queued: it proves custody of the task, not permission to read protected data or perform an effect.

Automatic custody always has an exact deadline. An explicit request deadline must be timezone-aware and is preserved exactly. When the request omits it, the accepting service derives a whole-second deadline from the normalized immutable event creation time, capped by the exact assignment scope's complete max_duration and strictly before relationship expiry. That server-derived value is written back into the canonical assignment request and immutable event as both effect_deadline and the no-later-than delivery_expires_at before the custody digest and row commit. A duplicate therefore cannot acquire a later window from retry time.

Custody is also a nondisclosure boundary. Generic mailbox reads, conversation thread reads, explicit-open/supervisor reconciliation, and downstream ordinary background delivery never return the plaintext payload of a task assignment or task-linked control event. They return only immutable event metadata, digests, and a custody reference with payload_access=task_grant_required. This denial uses the typed task/control shape as a fail-closed fallback, so a record with no marker is still withheld and deleting or changing the marker cannot promote it to ordinary content. Protected release exists only on the recipient-owned supervisor execution path. Authorization consumes one exact current task.process TaskGrant use bound to the event, action, resource, mailbox source, receipt sink, classification, principal, and harness. The recipient then durably records exact local queue custody before the release transaction rechecks the immutable cursor/envelope/payload, current policy, credential and domain epochs, grant dimensions/revocation/expiry, delivery, effect and retention boundaries, active execution intent, and unresolved conflicts. It validates plaintext and provenance inside the transaction, commits one disclosure receipt and audit record, and returns bytes only after commit. Exact retries repeat current-state checks and reuse the receipt without another grant use. Generic reads remain permanently redacted, and release explicitly grants neither tool nor effect authority. Ordinary non-task messages retain their normal authorized mailbox and conversation payload behavior.

The reverse and lateral directions are fail-closed. A subordinate/manager agent assigning a task to one of its administrators, or one manager agent assigning a task to a peer manager, creates a non-executable proposal in pending_human and requires explicit confirmation by the recipient's human owner. It may bypass that confirmation only when a separate current relationship independently grants the sender may_assign over that recipient for the exact task scope. An agent can therefore be an administrator relative to some agents and a subordinate relative to others; authorization is evaluated for the exact directed edge, never from a global title or payload claim.

Conflict defaults:

explicit deny, revocation, quarantine, and resource/security policy win;
task ownership uses leases and fencing generations;
duplicate or concurrent non-idempotent commands require idempotency/effect reservation;
incompatible non-commutative instructions enter conflict_pending for an authorized human or governance threshold;
arrival order, prose seniority, model confidence, or manager title never resolves authority;
relationship creation, modification, expiry, and deletion require explicit meta-permission and immutable audit.

The code supplies exact fail-closed lifecycle mechanics, but the accountable owner has not recorded the ORG-006 policy. In particular, implementing the policy-exception and organization.relationship.admin_revoke mechanisms does not approve who may hold those entitlements, when they may be used, what threshold applies, or any mandatory-relationship, notice, review, or appeal rule. Job title or prose never supplies that authority.

Relationship transition	Implemented fail-closed mechanism	Policy status
Propose	Exact current administrator-endpoint owner plus exact propose entitlement; record is expiring and has zero authority	Implemented
Normal activate	Independent verifier derives the exact current subordinate human/guest owner from a fresh purpose/transaction-bound receipt; exact revisions and epochs are rechecked; an exact local activation intent is inserted pending, the receipt and edge are consumed/activated, and that intent is completed in one transaction	Implemented local mechanism; independent witness evidence remains external
Policy-exception activate	A separately signed exception is first recorded against the exact digest/revisions/epochs and bounded by proposal expiry, then atomically consumed once by a current participant or its exact recorded signer harness; the same exact local activation-intent rule applies	Mechanism implemented; eligible authorities/circumstances/threshold unapproved under ORG-006 and independent witness evidence remains external
Modify/renew	New relationship ID, next coherent pair revision, predecessor snapshot, and fresh activation evidence; no in-place authority edit	Implemented
Subject exit / endpoint revoke	Exact signed `organization.relationship.revoke` command at the current lifecycle revision; on commit it advances the pair lineage epoch and revokes every then-open row; either endpoint is bound by transport and command proof	Mechanism implemented; mandatory-relation/notice/appeal policy unapproved
Administrative revoke	Nonparticipant requires separately entitled and signed `organization.relationship.admin_revoke`	Mechanism implemented; override policy unapproved
Expire	Proposal and active-edge expiry are persisted/audited; renewal never backdates authority	Implemented
Race	Exact lifecycle compare-and-swap permits one committed activation, revoke, expiry, or supersession. If revoke commits first, its lineage epoch fences every bound proposal; if activation/renewal commits first, the older revoke command is stale and conflicts.	Implemented

Renewal activation atomically supersedes a still-current predecessor. If a revocation commits first, the renewal's lineage epoch and predecessor snapshot are stale and activation fails. If renewal commits first, a command prepared against the predecessor's prior lifecycle revision is stale and fails; a fresh exact command is required to revoke the new active edge. At most one exact directed pair is active.

Immutable storage schema v1 contains these governance transactions and exception receipts as first-release authority objects. Current unreleased Core schema v5 adds the protected payload-release receipt in migration 2, guided OIDC enrollment continuation in migration 3, the bounded C0 bootstrap-plan contract in migration 4, and OIDC-begin/finite-credential lifecycle custody in migration 5 without retrofitting relationship consent. Exact catalog/checksum verification precedes the current one-transaction SQLite v4→v5 N/N-1 upgrade and each contiguous PostgreSQL migration application. No unsupported, tampered, prototype, or unilateral record is converted into consent.

The implemented conflict lifecycle binds every automatically accepted task to a strict typed resource/operation/access/exclusivity intent. Incompatible live intents for one subordinate enter deterministic per-resource conflicts, and all affected events move to conflict_pending atomically. The exact current human/guest positive-authority owner of the subordinate endpoint may partition every current member into pairwise-compatible release and reject sets at the exact conflict, policy, domain, and credential revisions. Arrival order, prose, and manager title do not choose a winner. Compare-and-swap fences competing decisions; rejection propagates across overlapping conflicts; and a released event returns to the queue only when no pending conflict membership remains. No release grants data, semantic-processing, tool, or effect authority.

8.3 Task delegation

A delegated task carries the delegator’s verified identity, requested outcome, data references, allowed actions, budget, deadline, cancellation semantics, and reporting path. The recipient executes only with its own human principal’s authority or a separately approved host grant. The delegator’s data permissions do not travel with the task.

Assignment processing has two distinct security decisions. First, the relationship policy decides whether the recipient mailbox may automatically record accepted_queued or must record a non-executable pending_human proposal. Second, before semantic processing, any protected read, or any effect, the PEP performs the full recipient-side authorization and intent checks below. Automatic downward acceptance never means automatic privilege inheritance or unrestricted execution.

The second decision is implemented as a separate recipient-owned supervisor flow, never as a generic read flag. authorize consumes one exact current task.process TaskGrant use; durable local custody binds the queue; protected payload release then rechecks current actor, grant, policy, credential, domain, intent, conflict, digest, provenance, and lifetime state and commits its audit and disclosure receipt before returning plaintext. A result upload requires that exact committed release receipt, so local custody alone cannot fabricate semantic processing and an old result_uploaded row cannot retroactively obtain payload bytes. Response-loss retries reuse the release receipt without another grant use. Current TaskGrant dimensions establish payload access and semantic-processing authority only; the release response keeps tool and effect authority false. Separate grants/reservations remain mandatory for any tool, network, budget, protected sink, or business effect.

Autonomous semantic processing also requires an exact task grant issued through a locally authenticated human action or preapproved deterministic workflow. It binds allowed input sources, output sinks and recipients, actions, resources, data classes, tools, network origins, budget, expiry, and whether further confirmation is required. The PEP intersects human entitlement ∩ harness eligibility ∩ exact task grant ∩ resource/data-class policy ∩ current revocation state.

Semantic-derived values remain durably tainted. Model output cannot directly create an executable job. Every external transmission, sensitive read/export, destructive mutation, credential use, or owner-defined protected sink requires independent confirmation unless that exact sink and source class were preauthorized by the task grant. This closes the gap between “the human may do X” and “the human intended this invocation to do X.”

8.4 Temporary elevation

An elevation request stores requester, beneficiary human, eligible harness, domain, exact actions/resources, reason, expiry, use budget, risk class, and required approvers.

beneficiary cannot approve;
manager relation alone is insufficient;
approval uses fresh authentication and exact transaction hash;
grant creation, approval threshold, nonce consumption, and use counters are transactional;
every protected effect reauthorizes;
ordinary scoped elevation defaults to one independent approver;
high-impact and break-glass defaults to two approvers;
break-glass is short, nonrenewable, immediately notified, and retrospectively reviewed.

9. Communication and collaboration model

9.1 Supported topologies

The same canonical objects support:

agent-to-agent;
agent-to-always-on server agent (the baseline's agent-to-hub topology);
always-on server agent to agent (the baseline's hub-to-agent topology);
server-agent-to-server-agent delivery (the baseline's hub-to-hub topology);
one-to-many, many-to-one, and many-to-many;
direct conversations;
manager/subordinate communication;
persistent and temporary rooms;
brainstorming and meeting rooms;
threads, replies, mentions, tasks, handoffs, cancellation, and completion;
file and structured-artifact sharing in every topology.

Every corporate contribution resolves and displays a host/room-scoped verified human label or pairwise guest pseudonym, trust domain, harness, and—where useful—session identity. The verified email mapping is visible only to authorized directory/audit viewers or when an explicit policy/legal purpose requires participant disclosure. Workload facts display the service role/domain; external A2A facts display external-human-unverified rather than fabricating a corporate human.

9.2 Event object

An immutable event includes:

schema and protocol version;
trust domain and stable origin actor;
explicit actor union: verified human+exact harness, host guest+exact harness, scoped workload with parent event/task grant, or external-human-unverified A2A actor;
event type and classification;
conversation, room, thread, task, recipient, fanout, and causal-parent references;
idempotency key and exact payload/artifact digests;
creation plus separate delivery_expires_at, effect_deadline, retention_delete_at, legal-hold state, and policy/room/credential revision references;
an optional extension-owned payload_access=task_grant_required marker for task custody; readers also classify typed task assignments and task-linked controls so a missing marker never permits generic disclosure;
optional purpose-specific origin evidence;
no mutable server, relay, or recipient claim inside the origin signature.

A workload-origin local event must bind exactly the actor's declared local parent event and no other causal parent. The mailbox resolves the immutable parent ledger digest in the same transaction, records derived provenance, and preserves source classification, sink ceilings, taint, and current policy. Missing/wrong parents, self-reference, replay-byte drift, classification reduction, sink widening, or policy drift abort the submission without an event or provenance row. Cross-domain relay packets retain their signed remote-event and audit binding; the receiving domain does not mislabel a remote event as a local ledger parent.

9.3 Separate authority objects

Keep these separate and digest-linked:

optional harness-origin submission;
authenticated transport context retained locally, never forwarded as bearer authority;
durable acceptance and authorization receipt;
relay or cross-domain handoff receipt;
remote-domain acceptance, rejection, or delay receipt;
recipient durable-commit receipt;
presentation or model-processing observation;
effect reservation and terminal or unknown receipt;
revocation, quarantine, compensation, and adjudication receipt.

Each signer asserts only facts it owns. A missing downstream receipt means unknown, not failed or complete.

9.4 Delivery states

There is no single mutable global truth. Canonical projection is derived from actor-owned facts:

State/fact	Owning actor and durable evidence	Meaning and allowed transition
created_local	Origin supervisor; encrypted local record	Draft only; may submit, edit into a new digest, expire, or delete.
submitted	Origin supervisor plus request/idempotency proof	Sent but no corporate acceptance known; retry exact bytes only.
rejected_before_accept	Accepting domain; signed rejection	Terminal for this submission digest; it cannot proceed to queue. A changed request needs a new idempotency key.
authorization_hold	Accepting domain; typed hold reason/revision	No acceptance/effect; may resume only after current reauthorization or expire/reject.
accepted_durable	Accepting domain; committed event/recipient/audit evidence at declared RPO boundary	Source domain owns exact accepted bytes/state; may queue, dispatch, cancel before effect, expire under policy.
queued / retry_scheduled	Current mailbox/dispatcher; attempt/backoff record	Waiting for eligible recipient/relay; no delivery claim.
dispatch_attempted	Dispatcher/relay; attempt and exact digest	Attempt occurred; may yield remote accepted/rejected/delayed or retry.
remote_accepted / rejected / delayed	Remote domain; separately signed receipt	Remote domain’s claim only; never implies recipient commit or effect.
recipient_committed	Recipient supervisor/domain; durable inbox bytes+dedup evidence	Baseline delivery acknowledgment: recipient custody exists; no presentation, model, or effect claim.
presented	Recipient presentation layer; observation receipt	Content was made available on an explicit view surface; not proof a human read it.
processing	Recipient worker; renewable fenced processing lease	Worker is active; lease expiry returns to eligible retry without claiming effect.
effect_prepared	Effect authority; transactional reservation and current grant/policy revision	Exact effect reserved but not proven committed; execute once or reconcile.
completed	Effect owner; terminal effect/output evidence	Required effect/output committed. Only this owner may assert it.
failed_retryable / failed_terminal	Failing owner; typed error and attempt evidence	Retry only when policy/idempotency allows; terminal failure ends this operation.
expired	Accepting authority/mailbox per recipient; committed delivery_expires_at/effect_deadline, policy/grant revision, and authoritative-clock evidence	Terminal no-future-delivery/effect for that branch. Exact retry returns the expired fact. A late receipt cannot reopen it. Expiry cannot overwrite a committed effect; possible commit becomes effect_unknown/too_late until reconciled. Retention is independent.
cancel_requested	Authorized requester/control authority; cancel receipt	Request only; races with effect reservation/commit.
canceled	Effect/control owner; proof no irreversible effect committed	Terminal for requested effect.
too_late	Effect owner; proof effect committed before cancellation	Cancellation failed; reconciliation/compensation may follow.
effect_unknown	Effect owner/dispatcher; timeout after possible commit	Nonterminal uncertainty; query/reconcile, then adjudicate or authorize compensation. Never blind retry.
reconciling / compensated / adjudication_required	Reconciler, compensating effect owner, or authorized human	Separately evidenced follow-up; original history is never rewritten.
quarantined / dead_lettered / conflict_pending	Security, queue, or governance authority	Held from normal processing with reason, review owner, expiry/retention, and release/reject path.

Each recipient/fanout branch has its own projection. partially_delivered is computed from those facts and is never an actor-written terminal state. Cross-domain/fanout projection preserves independent expiry. Contradictory or late signed receipts trigger quarantine/reconciliation and incident review. Dedup/replay evidence is retained longer than every retry, receipt, and replay window.

9.5 Delivery guarantees

At-least-once transport; no global ordering.
Stable idempotency scope binds origin actor, operation, recipient/fanout, and payload digest.
Same idempotency key with a different digest is a security conflict.
Conversation or room authority allocates local sequence; causal parents expose gaps.
Emit accepted_durable only after the declared PostgreSQL durability boundary.
Recipient persists exact bytes and dedup state before recipient_committed.
Recipient commit is not model processing or effect completion.
A timed-out non-idempotent effect becomes effect_unknown. Query and reconcile before human adjudication or a separately authorized compensating action. Never blind retry.
During its authorized retention and custody lifetime, the core retains every accepted event's exact bytes and exposes the authorized projection even if it is informational, no-reply, errored, progress-only, canceled, or non-actionable. Generic mailbox/conversation/supervisor projections never release task-assignment or task-linked-control payload bytes: they expose only immutable metadata/digests and the custody reference, including for records without the marker. Protected bytes are available only through the separately signed, recipient-owned supervisor authorization → local-custody → payload-release flow described in §8.3; generic projections remain nondisclosing. Ordinary non-task content remains fetchable under its normal authorization and retention policy. Classification suppresses model wake or notification, never durable visibility. After lawful expiry/deletion, preserve only the minimized access-controlled tombstone, receipt chain, deletion authority, and deletion evidence required by policy; never retain recoverable plaintext merely to satisfy a delivery gate. Downloaded or federated copies cannot be guaranteed erased.

9.6 Offline and presence

The local supervisor stores encrypted drafts and committed inbox content. On reconnect it:

refreshes credential and current revocation/room/policy epochs;
uploads drafts idempotently;
reconciles by durable cursor;
persists recipient bytes before acknowledgment;
wakes a model only for authorized semantic work.

Requests that require an answer carry an opt-in durable ResponseObligation bound to the exact accepted request and one responsible recipient harness. Only a typed response repeating the request event ID and digest can close it; prose cannot. If the request supplies a response schema, its identifier and bounded self-contained JSON Schema are both part of the signed payload and the stored schema digest is validated before terminal closure. The authenticated common supervisor reconciles obligations at startup, reconnect, live wake, and the bounded cursor fallback and stores only encrypted content-free attention counters locally. Active sibling harnesses share principal-level visibility, but cannot claim the specifically responsible harness's progress or response; revoked harnesses fail closed.

WSS, SSE, push, and broker notifications are wake hints. Cursor reconciliation is authoritative. Offline is a normal availability state, not identity failure.

Presence is a signed/authorized expiring lease with live, recent, stale, and unknown states. Presence never proves readiness, authorization, or receipt.

9.7 Always-on and future peer-assisted profiles

The same ordinary AgentNet extension may run continuously on one or more server agents to compose domain authority, durable recipient mailboxes, offline store-and-forward, reconciliation, and audit roles. This is not a separate Hub product or identity. A local deployment may run one explicitly weaker server agent, while a production durability claim requires redundant stateless role instances, authoritative PostgreSQL replication, replicated artifact storage, fencing, backups, and restore drills on company-controlled infrastructure.

The architecture must preserve two later profiles without changing corporate event formats:

Opportunistic mesh: online enrolled devices prefer direct delivery and explicitly eligible devices may temporarily store and forward recipient-encrypted envelopes or encrypted artifact chunks. Relays gain no content or data authority; eligibility, quotas, retention, custody receipts, and revocation are policy-controlled. The sender retains its durable outbox until the required custody evidence exists. If all eligible nodes are offline, delivery safely pauses.
Fully distributed domain: approved company nodes replicate authority, revocation, mailbox, room-sequencing, and audit state under an owner-approved quorum and partition model. This profile is disabled until policy freshness, revocation under partition, split-brain fencing, membership changes, recovery, equivocation, and durable-replica thresholds pass dedicated gates.

The first production profile therefore uses globally unique actor/event/message/artifact IDs, independently verifiable signatures where required, transport-neutral envelopes, versioned policy and revocation epochs, immutable content digests, per-recipient state, and an abstract mailbox-custodian interface. No identifier, signature, receipt, or authorization rule may require a particular AgentNet server-agent instance. These seams permit a future mesh without weakening the initial consistent security model.

10. Rooms and meetings

Every room records:

immutable room ID;
owner domain and owner epoch;
independent governance policy and recovery threshold;
control sequence and membership epochs;
creator, moderators, members, guests, invitations, and sponsorship;
persistent/temporary mode and expiry;
classification, managed-service-visibility/E2EE mode, history mode, retention, legal hold, archive/delete policy;
artifact policy and storage domain;
fanout, tool, token, spend, and causal-loop budgets.

Phase 1 uses one authoritative owner domain/control sequencer. Infrastructure failover within that domain does not change owner. Membership and cryptographic-control changes fail closed during a control partition.

Transfer protocol:

ACTIVE(A,n) → TRANSFER_PROPOSED(B, cutoff, snapshot_digest) → FROZEN → TARGET_ACCEPTED → TRANSFER_COMMITTED(B,n+1).

Transfer requires the predeclared governance threshold plus destination acceptance over immutable state and history digests. Before commit, A remains authoritative and frozen; after commit, B wins and A only forwards a signed redirect. Competing transfers use compare-and-swap. If permanent owner loss lacks a precommitted recovery threshold, tombstone the room and create an explicitly linked successor rather than inventing authority.

The transfer manifest binds cutoff control/event sequences, state/history roots, per-recipient rows, pending effects and cancellations, quarantined/released artifact manifests and object versions, retention/legal-hold declarations, guest roster, audit custody, application/MLS/file-key epochs, destination keys, and destination acceptance. Before cutoff, A completes or explicitly hands off each owned row; after cutoff, B owns new control and delivery. No pre-cutoff effect is silently replayed. B verifies copied objects and evidence before commit; old download capabilities are revoked; guests are re-admitted under B’s host policy; operational, MLS, and file keys rotate; A’s post-cutoff retention/deletion duties remain in the signed manifest. Reconciliation must close every row before TRANSFER_COMMITTED.

Default history is from_join for internal managed rooms and no prior history for guests or sealed rooms. Removed members receive no future content, undelivered history, file keys, or downloads. Already delivered plaintext cannot be recalled.

Single-owner sequencing leaves a real censorship risk. Signed acceptance/relay gaps expose it; participants can leave or fork. Matrix-style multi-writer state resolution remains an alternative only if partition writes become a HARD requirement and the owner accepts the complexity and replicated-history/privacy cost.

Placing, modifying, or lifting legal hold requires a dedicated legal/governance meta-permission, exact scope, authority basis, independent audit, and conflict rule. Room owners and administrators do not receive that power implicitly.

11. Files, artifacts, provenance, and content safety

11.1 Storage and access

Immutable content-addressed versions in a versioned object store.
Separate encrypted quarantine and released namespaces.
Deduplication, refcounts, encryption, retention, and quota effects are scoped at least to (trust domain, tenant, confidentiality class, retention/legal-hold class), or disabled for sealed/high-risk data. Cross-domain, cross-tenant, or cross-class bytes are never coalesced merely because they match.
Object storage addresses ciphertext. Plaintext digests stay encrypted inside authorized manifests or use a domain/class-keyed equality identifier. First and duplicate uploads return indistinguishable non-disclosing responses and reveal no prior owner, path, class, artifact ID, quota difference, or existence through timing.
Current authorization on upload, release, relay, transform, preview, download, and key release.
Short-lived, single-use, audience-bound download capabilities.
Offline files survive with the message/room event and exact manifest.
Retention, deletion, archive, WORM/legal hold, quotas, size, and residency are explicit policy.

11.2 Evidence objects

Separate:

upload/acceptance statement;
immutable manifest containing digest, size, media type, classification, and origin reference;
derivation statement linking exact input and output digests plus transformer identity/version;
scan attestation linking digest, scanner/version/rules/time/result;
release-policy decision;
access/download receipt;
audit checkpoint.

Artifact promotion accepts an optional strict derivation with complete parent provenance references and one or more canonical transformation steps. The service resolves each parent version and digest from the authoritative ledger inside the promotion transaction, binds the output digest and current policy, requires every executor to equal the authenticated harness, and persists the derived artifact as tainted, unreviewed, and scan-pending. Exact replay must match the server-resolved parents and transformations. Human-origin HTTP registration is restricted to the exact authenticated human harness; composed services, not callers, create server origins.

DSSE/in-toto-style statements remain the initial interoperability profile. A smaller exact-byte signed manifest/attestation profile remains viable if interoperability or operations fail. Provenance proves lineage, not safety.

11.3 Safety pipeline

quarantine before parsing or model exposure;
validate extension, declared type, detected type, size, count, nesting, compression ratio, and parser limits;
malware, secret, DLP, polyglot, archive, decompression-bomb, link, macro, and executable-content controls;
isolated preview/transform with no ambient credentials and restricted egress;
stale or missing scanner evidence denies release for protected classes;
public A2A files are untrusted regardless of Agent Card or sender signature;
sealed E2EE rooms cannot claim server scanning unless the scanner is a visible key-holding member.

11.4 Cross-store artifact acceptance

PostgreSQL and object storage do not share an atomic transaction. Required artifacts therefore use this staged state machine:

upload_reserved: one PostgreSQL transaction insert-or-returns a private reservation keyed by trust domain, verified actor, and idempotency key. It binds exact request/payload digest, tenant/class/retention/legal-hold scope, expected size/type, required-vs-optional role, expiry, unpredictable private quarantine object key/version, encryption context, task grant, and quota owner. Same key/different digest conflicts before upload.
uploading: conditionally stream bytes to the reservation’s immutable private quarantine object/version; no event acceptance and no reusable public identifier;
quarantine_object_committed: object store durably acknowledges the exact reserved version under the declared storage RPO;
object_verified: re-read/verify ciphertext/plaintext digest as policy permits, size, media constraints, reserved object version, encryption scope, and durability;
manifest_committed/promoted: one PostgreSQL transaction promotes the reservation and records manifest, artifact state, event/room reference, audit intent, idempotency state, quota charge, and outbox row;
scanning / held / released / rejected: scanner and release-policy evidence update by separately owned immutable facts; access remains denied until released;
deleted/tombstoned: lawful policy destroys allowed objects/keys and retains minimized evidence without claiming recall of downloaded/federated copies.

Artifact/event durable acceptance is emitted only after both the immutable object version and authoritative manifest/reference transaction are proven. A required attachment keeps the surrounding message in artifact_hold or rejects it before acceptance; an optional attachment may allow the message only with an explicit attachment_incomplete fact visible to every recipient.

Failure rules:

reservation committed but object absent → resumable private upload until reservation expiry; no artifact/event acceptance;
object committed but promotion transaction failed → reservation still authenticates actor, task, scope, object version, and idempotency; retry returns the same hidden reservation, conditionally verifies existing bytes, and promotes once. Inventory reconciliation and policy-safe GC run only after reservation/retry/incident/legal-hold windows;
metadata references a missing/wrong object or version → artifact_integrity_hold, deny all access/effects, alert, restore/reconcile exact evidence, never substitute bytes;
object store outage → artifact acceptance incomplete;
scanner outage/stale attestation → quarantine remains;
promotion committed but response lost → retry exact idempotency key and converge on the existing manifest/event without disclosing prior ownership.

Fault tests cover reservation-before-object, object-before-promotion, promotion-before-response, reservation expiry, concurrent retry, every object/DB/audit/receipt crash permutation, orphan inventory, missing-version recovery, restore of object+manifest+attestation chain, dedup equality/timing/quota probes, retention, key deletion, and legal hold.

12. Federation and contractors

Phase 1 prepares schemas but keeps federation disabled. The first federation profile is bilateral and host-controlled:

two domains exchange signed federation metadata out of band;
an administrator allowlists exact domain IDs, endpoints, keys, assurance profile, algorithms, data classes, revocation/incident contacts, expiry, and non-transitivity;
a host sponsor creates a single-use invitation bound to the intended home domain, principal assurance, pairwise human subject, harness key, resources/actions, expiry, and sponsor;
the home domain authenticates its human and harness and returns a per-host pairwise subject/pseudonymous stable identity assertion, not host authority. Cross-host linkability requires a separate approved purpose.
the guest proves a fresh pairwise per-host harness key;
the host creates a local guest identity, optionally performs host-local WebAuthn/reproof for high-risk access, and issues host-local DPoP credentials plus minimal grants;
internal services accept only the host identity, credential, and current policy;
a host kill switch applies at the next local decision or stream check. A home revocation signal applies only after verified receipt/reconciliation; exposure is bounded by host token expiry and the PD-009 signal SLO;
sponsor loss blocks renewal and new protected work until explicit reassignment;
normal exit revokes grants, rooms, keys, downloads, and protected queued effects while retaining minimized audit evidence.

Foreign tokens, groups, roles, manager edges, workload IDs, email strings, and gateway certificates never become positive host permissions. Trust A→B never creates B→C. The same person or harness receives distinct host-local identities and keys in every network.

Guests receive no sponsor_of, invitation, federation-administration, guest-creation, or onward-trust meta-permission by default. Any exception is a separately approved, narrowly scoped, expiring, auditable host grant and never reuses home authority. A compromised sponsor can mint invitations only within its explicit sponsor scope; quotas, independent high-risk approval, anomaly detection, immediate sponsor kill, and invitation audit bound the blast radius.

SCIM and CAEP are lifecycle/revocation signals, not sole authorization or guaranteed-immediate truth. Each domain owns its receipts, audit, and incident response. High-risk guests require fresh host-local proof; low-risk continuity during a partner outage ends at an owner-approved short token expiry.

13. Security, privacy, and abuse containment

13.1 Content classes

Class	Managed service visibility and functions	Default
C0 public/A2A	Gateway-readable, no internal-secret assumption	Transport security only
C1 internal managed	Least-privilege AgentNet service roles may inspect for search, moderation, DLP, scanning, tools, backup	First production-profile default, owner-approved
C2 restricted managed	Plaintext only inside isolated content/scanner/tool enclave; no broad indexing	Sensitive operational default
C3 sealed E2EE	MLS members only; relay sees ciphertext/metadata; no server plaintext search, scan, moderation, tool execution, or recovery	Explicit opt-in after policy and required external evidence
H legal-hold overlay	WORM/eDiscovery over the selected class	C1/C2 by default; C3 only with disclosed inspection/recovery member and legal approval

For C3, room authorization commits before MLS membership; application room, owner, and MLS epochs remain separate. Any scanner, tool, archive, recovery, or inspection service with keys is a visible room member. No hidden escrow. If C3 is required at launch, the managed Phase-1 profile cannot ship until MLS identity, KeyPackage, multi-device, removal, recovery, history, file-key, compromise, and legal-hold tests pass.

A semantic LLM worker that is a C3 member decrypts plaintext and transmits it to its model provider. The room is therefore sealed from nonmember AgentNet service roles but not from that provider. PD-007 must explicitly choose whether each C3 class permits named LLM providers with approved retention/training/residency terms, requires an approved local/self-hosted model, or is human-read-only/deterministic-delivery with no semantic worker.

Metadata minimization is separate from content encryption:

Class	Mandatory routing metadata	Authorized readers and indexes	Retention/disclosure/federation
C0	Gateway peer/route, task/message IDs, size/timing, security scheme	Gateway/security/abuse services; public capability index only	Short operational retention plus incident policy; no corporate directory membership
C1	Opaque actors, room/conversation/recipient, state/receipt, classification, size/timing, policy epochs	Authorized mailbox/search/moderation/audit roles; content indexes only by declared purpose	Room/domain retention; participant display uses scoped verified label; federation exposes only required pairwise fields
C2	Minimum opaque route, state, receipt, classification, size/timing	Isolated enclave and narrowly scoped audit/security roles; no broad content or relationship index	Shortest operational/legal period; exports and joins require exact purpose
C3	Ciphertext route, room/MLS epochs, recipient delivery facts, size/timing required for transport	Relay sees only routing/ciphertext metadata; member clients see decrypted content; no managed-service content index	Minimize/pad where feasible; partner disclosure specified by room policy; key/member history follows MLS/legal policy
H	Hold ID, authority basis, scope, immutable custody/deletion facts	Dedicated legal/governance and independent audit roles	Overrides deletion only within exact scope and jurisdiction; lifting requires recorded authority

Presence, relationship graphs, receipt chains, search terms, model/tool cost, and cross-domain correlation are independently authorized resources, not free metadata. Email mappings remain private to authorized directory/audit viewers. Every index names purpose, reader, fields, retention, deletion, and export policy; unknown use is denied.

13.2 Four inbound lanes

Protocol-control lane: receipts, retries, dedup, expiry, presence, cursors, and capability probes are strict deterministic schemas and trigger zero model calls.
Typed-operation lane: allowlisted action/resource/arguments; current policy enforcement; deterministic or restricted effect worker.
Semantic lane: peer prose, cards, files, tool output, and web output enter only a clean-profile background worker under an exact task grant. Inputs and derived values remain tainted; the worker has no ambient credentials or unrestricted sinks.
Human-consent lane: enrollment, elevation, sensitive export, destructive/high-risk effects use an independent exact-transaction approval service.

Raw remote content never becomes a system/developer instruction, tool schema, policy, approval label, signer preimage, or security principal. Model output is a proposal, not authority, human intent, or proof of effect. A semantic proposal becomes a typed job only after source/sink validation and intersection with the exact task grant. Sensitive reads, disclosures, external transmissions, destructive changes, and credential use require a preauthorized exact sink or independent confirmation.

13.3 Quotas and loop control

Budgets cover bytes, recipients, fanout, causal depth, turns, model calls, tokens, tools, CPU, memory, network, storage, duration, retries, and spend. Child tasks and subagents receive attenuated sub-budgets. Use fair queues and per-peer/domain/room/recipient circuit breakers. Reserve capacity for cancellation, revocation, quarantine, and security signals. Receipt loops and presence updates never wake a model.

13.4 Replay, signing, and local IPC

Exact audience, resource, domain, nonce, timestamp, sequence, jti, and replay cache checks.
Purpose-specific, fixed-schema signing only; the broker is never an arbitrary-byte signing oracle.
Authenticated private local IPC with platform peer credentials, adapter capability, session binding, socket ownership, and replay protection.
Same-user compromise remains residual risk; server policy and independent human approval protect high-risk effects.
Signed packages, pinned dependencies, SBOM, provenance, threshold update metadata, canary, rollback, and emergency adapter disable.

13.5 Threat coverage

The design defines candidate controls, subject to §19 gates, for impersonation, email reassignment, token/key theft, copied harness IDs, compromised harnesses, malicious peers, prompt injection, malware, compromised hubs, malicious insiders including a compromised sponsor minting rogue invitations, replay, stale authority, confused deputy, privilege escalation, signer-oracle abuse, cross-domain leakage, transitive trust, room-owner loss, split brain, false receipts, unknown effects, denial of service, reconnect storms, cost loops, supply-chain compromise, update rollback, audit omission/fork, and data-retention conflicts.

14. Availability and operations

14.1 Canonical substrate

Phase 1 uses supported PostgreSQL plus a provider-neutral versioned artifact store. Both are self-hosted by default; the core depends on its own narrow ArtifactStore contract rather than AWS credentials or S3-specific identity semantics:

one transaction records accepted event, recipient states, idempotency/digest, relevant authority revisions, receipt/audit intent, and outbox row;
accepted_durable is emitted only after the declared local WAL and synchronous replica or managed-service durability boundary;
unavailable durability quorum means the client retains a submission and receives no false durable acceptance;
dispatch failure creates visible lag but cannot lose accepted rows;
lost response after commit converges on retry;
failover requires fencing; split-brain authority is forbidden;
WAL archive, PITR, object backup, full restore drills, and receipt/audit reconstruction are release gates.

The local signed-backup mechanism binds manifest, trust record, seal, and archive to the exact source fingerprint, domain, storage schema, key epoch, and bytes. Publication uses descriptor-relative staging, atomic rename, directory durability, and inode/digest verification. If cleanup cannot prove ownership of the installed pathname, AgentNet moves the product-visible name to a random owner-only .agentnet-quarantine-* file and retains the exact bytes for authenticated operator inspection and out-of-band removal. It never unlinks a pathname that a competing same-UID process could have replaced. Post-commit close or durability uncertainty is an unknown publication outcome, not a successful rollback claim.

JetStream may later carry wake/fanout behind the transactional outbox if benchmarks show dispatch saturation. It never becomes a second source of truth. Kafka/Pulsar are later log/analytics choices at demonstrated scale.

14.2 Deployment profile

Linux x86_64 and arm64 first for production-topology qualification, after exact distro, service lifecycle, IPC, storage, and update tests.
Current owner instruction (2026-07-17) requires the installable package and local conformance mechanisms on Linux, macOS, and Windows now rather than deferring portable implementation. Real-host CI may establish only its named package, state, SQLite, IPC, and lifecycle contracts; privileged hostile-host, signed update/install/uninstall, semantic harness, and production topology gates remain separate.
Two stateless core replicas and HA PostgreSQL for a production durable claim.
Company-controlled deployment by default; a filesystem-backed artifact store is acceptable only for an explicitly weaker pilot, while production requires independently tested replication, backup, immutability, encryption, and restore behavior from the selected self-hosted backend.
One region initially; residency and multi-region require explicit owner/legal decision.
Separate credentials/processes for scanner, effect worker, public/federation gateways, approval, issuer/KMS, and audit witness.
Privacy-aware metrics: queue age/depth, state counts, acceptance/delivery latency, database replication/outbox lag, authorization denials, revocation latency, scanner/audit lag, receipt gaps, model wakes/tokens/spend, quota trips, and adapter health—without plaintext or secrets.
Unsupported OS, harness, or version fails installation or downgrades only a nonsecurity feature. It never silently weakens identity, authorization, durability, or isolation.

PD-010 must select a concrete minimum physical and administrative topology. Safe small-organization baseline:

core replicas, dispatcher, and read-only facades may share a hardened compute host only under distinct OS/service identities and credentials, but replicas on one host do not count as HA;
synchronous PostgreSQL primary/standby and object backup span declared failure domains;
scanner, effect worker, public/federation gateways, and approval service use separate sandboxed processes/OS identities with no authority-key access; high-risk profiles may require separate hosts;
issuer/KMS authority and independent audit witness are in different administrative accounts or under independent threshold administrators from the application/database operators;
witness and audit export have redundant destinations or an approved bounded degraded backlog; they are not an accidental single point of silent failure;
every co-location, failure domain, administrator boundary, key custodian, backlog ceiling, and stop rule is recorded.

14.3 Always-on server-agent role composition

An always-on AgentNet installation composes the same ordinary extension roles used on a laptop. It is not a separate Hub product, privileged identity, or universal authority. A deployment may compose:

mailbox/relay;
transactional room/task authority;
identity and policy enforcement;
artifact metadata/service;
active server agent or effect worker;
public A2A gateway;
federation gateway;
audit exporter.

These are separable roles with distinct credentials. A server agent with sensitive data is an effect/data service behind the same verified-caller and policy enforcement boundary; always-on placement creates no authority.

14.4 Normative failure and recovery contract

Failed or uncertain role	Allowed behavior	Required state/receipt and recovery	Forbidden fallback
IdP or independent approval	Existing short sessions and already-active relationship edges only to their recorded status/expiry and while every stored/current binding remains valid; safe drafting	enrollment/recovery/elevation and new relationship consent/renewal unavailable; health receipt; recover with fresh ceremony	no cached identity, cached/caller-asserted consent, or agent-mediated approval
Relationship governance schema missing/altered/uncertain	No relationship authority evaluation or automatic custody	block startup/use; restore the exact clean-start v1 objects and migration record/checksum, then reconcile	no unsupported-store import, unilateral consent inference, schema downgrade, or object repair by guesswork
Issuer/KMS/authority signer	Deterministic reads already authorized where policy permits	hold new token, grant, authority receipt, key release; rotate/reconcile after recovery	no raw local/application key
PDP/status/revocation	Local drafting and non-sensitive diagnostics	protected acceptance/effect authorization_hold; current snapshot required on recovery	no stale allow or prose policy
Internal directory/capability registry	Existing exact non-security presentation hints only within bounded freshness	hold new protected discovery, route/key/endpoint selection, export, or capability-dependent work; reconcile current epochs	no global enumeration, stale trust, or self-advertised security fact
PostgreSQL durability boundary	Client retains local submission	no accepted_durable; visible unavailable/retry; fenced restore/failover	no in-memory/broker acceptance
Object store	Message without required artifact may remain held	artifact acceptance incomplete or artifact_integrity_hold; reconcile exact version	no fabricated URI, substitute bytes, or metadata-only availability
Scanner/transformer	Quarantine storage only	scan_pending/held; rerun exact scanner/profile after recovery	no stale/missing attestation release
Audit publisher/witness	Core commits audit_intent while bounded backlog remains	visible degraded_audit, sequence/checkpoint reconciliation; owner-approved ceiling/SLO	no silent unlimited backlog
Audit ceiling exceeded	Explicitly classified low-risk non-sensitive traffic only if policy permits	stop enrollment, elevation, federation changes, sensitive reads/preview/export/download/key release, and high-impact/irreversible effects until witnessed	no protected disclosure, high-risk admission, or effect
Budget/quota service	Deterministic queue, cancel, revoke, security control	semantic/model/tool/effect work budget_hold; reconcile counters	no unmetered model/effect work
Model-egress broker	Deterministic protocol control and explicit human viewing	queue semantic work as model_egress_hold; rebind short worker capability after recovery	no worker vendor credential, user auth state, or generic proxy
Effect worker/tool	Queue and diagnostics	pending, failed, or effect_unknown based on evidence; reconcile/adjudicate	no hallucinated completion or blind retry
A2A/federation gateway	Internal corporate operation continues	isolate external edge, revoke gateway credential, quarantine epoch, reconcile peers	no gateway-to-core broad credential
Supervisor/worker	Durable protocol control and local queue restore	restart from supervisor/core cursor; re-establish clean launch/task grant	no active-user-session fallback
Room owner/control	Existing policy-approved local reads/drafts	freeze control mutations; recover threshold or tombstone	no invented successor
Update metadata/channel	Run last trusted non-expired compatible build only if policy permits	visible update_degraded; recover trusted root/metadata	no unsigned, expired-security, rollback, or freeze bypass

Every row has an owner-approved backlog ceiling, timeout/SLO, safety-lane behavior, recovery evidence, reconciliation procedure, and alert policy. Fault injection verifies that uncertainty moves to the named hold/degraded state rather than fail-open.

15. Phased roadmap

Local conformance and release kernel

Freeze semantics before production claims:

complete a reuse-versus-build inventory for each subsystem and run the component bake-off in §6.6 before approving custom implementation;
evaluate AGNTCY OASF and Directory, evaluate SLIM delivery/offline/duplicate behavior, test the selected MLS implementation's membership removal and compromise recovery, and compare their operational burden with the thin corporate API and PostgreSQL-outbox baseline;
map every reused result into actor-owned receipts, exact revocation/expiry, artifact holds, and effect_unknown; reject any candidate that needs a semantic workaround or silently weakens a gate;
versioned event, identity, room, task, artifact, receipt, grant, relationship, revocation, presence, audit, and error schemas;
supervisor and four dedicated-worker adapter implementations with exact external-evidence gates;
non-production transactional core, object store, scanner, approval stub, and isolated A2A gateway;
exact A2A v1 and stable MCP profiles;
identity, enrollment, credential, authorization, and data-class profiles;
cross-language crypto vectors;
declarative state-machine and property tests;
hostile-content, abuse, local IPC, and signing-oracle corpora;
PostgreSQL durability/load/failover benchmark;
every release re-pins the exact supported PostgreSQL release used by the benchmark; PostgreSQL 18 was the research reference, not an implicit permanent dependency;
owner decisions PD-001 through PD-011.

Exit: no production-secure, federated, E2EE, or accepted_durable claim without its named gate.

Limited owner deployment

A reversible pilot may validate novelty before production HA:

one owner and three to five harnesses;
explicitly named accepted_local durability, never accepted_durable;
Pi and Claude adapters first if they match the actual fleet, then Codex and Antigravity;
direct messages, tasks, explicit inbox, and passive counts; file tests use synthetic/non-sensitive bytes until cross-store, scanner, retention, and deletion gates pass;
no contractors, E2EE, or protected public A2A data access;
enrollment uses the final independent-device/security-boundary ceremony; any noncompliant lab identity is synthetic-only and cannot be promoted;
semantic processing uses the full clean-worker plus model-egress-broker profile; otherwise the pilot is deterministic control plus explicit human-opened viewing only;
no claim that ARC-003, ARC-004, AVL-007, or production security is satisfied.

This reconciles the useful early-pilot proposal with the operational objection: a single-node pilot is allowed only when its weaker state and scope are explicit.

Phase 1 — Single-domain production

all four adapters pass isolation/recovery tests;
Linux-first production supervisor topology qualification; the shared package and local conformance adapters remain available on Linux, macOS, and Windows without promoting production support;
HA PostgreSQL and a self-hosted, provider-neutral immutable artifact store;
C1/C2 direct communication, tasks, files, rooms, offline delivery, receipts, policy, elevation, audit, scanner, and effect worker;
isolated native A2A gateway passes conformance/security tests and is enabled for Corporate GA;
no federation or C3 MLS yet.

The A2A gateway is a Phase-1 Corporate-GA critical path because ARC-004 is HARD. Engineering may stage it as Phase 1B after the internal Phase-1A core, but GA cannot claim ARC-004 until the full A2A conformance and security gate passes. This front-loads a substantial external-security workload and must be reflected in schedule and staffing.

Phase 2 — Bilateral federation pilot

one partner;
host-local guest identities and keys;
sponsor lifecycle, assurance mapping, host kill, CAEP/SCIM reconciliation;
cross-domain receipts, revocation SLO, incident and partner-outage drills;
no multilateral or transitive trust.

Phase 3 — Measured scale and governance

Only when trigger evidence exists:

JetStream wake/fanout behind outbox;
specialized OpenFGA/SpiceDB authority replacing Cedar if benchmarked need is real;
SPIFFE/SPIRE for a real server workload fleet;
workflow engine for complex long-running effects;
regional ownership/sharding;
richer room governance and partner operations.

Phase 4 — Selective E2EE and transparency

C3 MLS rooms after explicit privacy/legal policy and full cryptographic lifecycle tests;
private SCITT or equivalent cross-domain non-equivocation only if partners or compliance require it;
multilateral identity federation only after bilateral operations no longer scale.

16. Alternatives and trigger conditions

Alternative	Decision now	Why not now	Trigger to reconsider
Build all infrastructure from scratch	Reject	Reimplementing mature transport, crypto, identity, room, storage, and workflow machinery increases security, schedule, maintenance, and interoperability risk	Custom-build only the corporate supervisor/governance integration and components whose bake-off proves no suitable implementation passes the gates
AGNTCY components	Evaluate individually first	OASF, Directory, SLIM, Identity, and reference integrations may save major work, but maturity and their authority/offline/revocation semantics require proof	Adopt each component behind a replaceable interface when §6.6 bake-off passes; never adopt the ecosystem wholesale as the corporate trust model
MCP as the network	Reject	Not durable peer messaging, identity, federation, or universal across harnesses; Pi lacks it by design	Never as the corporate fabric; retain as local binding
A2A as the internal fabric	Reject	External task/message interoperability lacks corporate room, identity, authority, mailbox, file, receipt, and governance semantics	Use only as isolated boundary; reevaluate if the standard later covers the full trust model
Mandatory managed cloud services	Reject	Creates avoidable external trust, availability, residency, cost, and lock-in dependencies	Permit only as explicit owner-selected adapters when a concrete requirement justifies them
Opportunistic peer-assisted mesh	Future profile; design seams now	Message relay is tractable, but authority freshness, revocation, sequencing, partitions, custody thresholds, abuse, and recovery need a separate proof program	Enable direct/relay mode after encrypted custody and partition tests; enable distributed authority only after quorum/revocation gates pass
PostgreSQL transactional mailbox	Recommend, benchmark-gated	Best fit for multi-object atomic authority; operational and failure profile still needs proof	Replace only if declared RPO/RTO/load tests fail
JetStream canonical store	Reject	Split truth and default durability semantics conflict with transactional authority	None without redesign
JetStream outbox-backed wake/fanout	Defer	Adds operations before measured dispatch need	PostgreSQL dispatch/fanout saturates while canonical acceptance remains healthy
Kafka/Pulsar	Defer	Excess operational surface for initial scale; does not solve arbitrary-effect exactly once	Sustained analytics/event/geo-log scale
Matrix core	Reject, retain concepts	Multi-writer state resolution, replicated history, privacy, and operator complexity	Partition writes or open Matrix interop becomes HARD
XMPP core	Reject, retain ACK/MUC concepts	Requires a fixed XEP/security overlay and duplicates identity/authorization	Contractual XMPP interoperability
Cedar	Recommend candidate	Clear default-deny and forbid semantics; graph/list performance not yet proven	Benchmark failure causes replacement by one OpenFGA/SpiceDB authority
Cedar + OpenFGA dual engine	Reject	Split positive authority and revision races	Only after a formally proven intersection architecture; not default
Universal origin signature	Reject	Unnecessary complexity for same-domain managed traffic and mixed field ownership	Require per evidence/threat class
Exact-byte JWS	Initial interoperability profile	Simple detached authority objects; cross-language and performance still need proof	COSE or DSSE envelope if vectors/size/latency fail
DSSE/in-toto file statements	Initial interoperability profile	Strong provenance ecosystem but operational overhead	Smaller exact-byte manifest/attestation if interoperability fails
Universal managed-service plaintext	Reject	Excess insider/privacy blast radius	C1/C2 only by policy
Universal MLS/E2EE	Reject	Eliminates scanning, search, tools, recovery, and legal functions; complex lifecycle	C3 only after explicit class and tests
SCITT everywhere	Defer	Unneeded launch complexity	Cross-domain inclusion/non-equivocation becomes contractual
SPIFFE/SPIRE on laptops	Reject	Workload identity does not prove human; endpoint operations mismatch	Managed fleet already runs it, while human binding remains separate
Multilateral/OpenID Federation	Defer	Trust governance, metadata, and revocation complexity	Bilateral partner operations become unmanageable
Active-active multi-region	Reject initially	Authority, ordering, fencing, data residency, and recovery complexity	Approved RTO/residency requires it and sharded tests pass
Microservice-first deployment	Reject initially	Operational and trust-surface cost exceeds initial scale	Independent scaling or administration justifies extraction while trust roles remain explicit
Temporal/workflow engine	Optional internal detail	Communication state machine is simpler in the transactional core	Effect orchestration complexity outgrows explicit state machine
Automatic foreground digest	Reject as compliant behavior	Alters active context and expands prompt-injection/attention surface	Content may enter only through explicit open/read action; an owner-approved experiment cannot satisfy UX-001/002 without an approved requirement change
All-OS launch	Reject	Unverified IPC, key custody, service/update lifecycle	Each OS graduates through full native test matrix

17. Dispute resolution register

DR	Final decision	Evidence class	Remaining gate or owner
DR-001	Dedicated autonomous worker plus optional content-free indicator; automatic foreground digest disabled. Claude advocated Lane-2 pilot digests; Codex/Pi security analysis won because even next-turn context changes the active prompt surface.	Surfaces verified; external-evidence-gated	Four-harness zero-interference/recovery tests
DR-002	A2A v1.0.1 package, wire 1.0, no downgrade, isolated gateway, curated trust registry	Verified	TCK plus security and cross-SDK suite
DR-003	Supervisor API is common; MCP is optional local tool binding and absent by design in Pi	Verified	Adapter conformance and spec pin
DR-004	PostgreSQL canonical mailbox/control plus versioned object store, staged cross-store artifact acceptance, and outbox; optional wake broker later	External benchmark/evidence gated	DB/object crash permutations, load, failover, restore, PD-010
DR-005	Domain/OIDC principal, exact OOB approval, per-domain/per-harness DPoP key, opaque tokens	External-evidence-gated	OS custody, enrollment, recovery, revocation; PD-001/002/009/010
DR-006	Human-only positive entitlement; harness/device deny-only eligibility	Owner-policy default	PD-003 and AUTH-003 wording confirmation
DR-007	One Cedar candidate over one transactional authority; single-engine fallback	External benchmark/evidence gated	Correctness, graph/list, scale; PD-004
DR-008	Event-specific acceptance/delivery/read/effect authorization; history continuity and compromise quarantine	Owner-policy default	PD-005 plus state tests
DR-009	One room sequencer, separate governance threshold, fenced transfer and tombstone	Owner-policy default, model-test-gated	PD-006 plus model/fault tests
DR-010	Bilateral allowlist, pairwise human+harness identity, host-local guest/key/token, sponsor and host kill. Earlier fixed four-hour/24-hour grace suggestions were rejected as unsafe universal defaults; continuity ends at the owner-approved short host-token/SLO boundary.	Owner-policy plus external evidence	PD-008/009 and federation incident tests
DR-011	C0–C3 content classes; managed Phase 1; explicit MLS/inspection semantics for C3	Owner-policy default	PD-007 and MLS suite if enabled
DR-012	Domain-owned receipt facts, per-recipient state, first-class effect uncertainty and adjudication	External-evidence-gated	State/property/fault tests; PD-005/009
DR-013	Separate origin/acceptance/relay/commit/effect objects; purpose-specific exact-byte signing	External-evidence-gated	Cross-language, key, performance, federation/E2EE tests
DR-014	Immutable artifact versions; separate acceptance/derivation/scan/release/audit evidence; SCITT optional	External-evidence-gated	Scanner, provenance, audit crash/omission, retention
DR-015	Authenticated content remains hostile; clean-worker launch, exact task grants, source/sink taint controls, four lanes, budgets, typed signer, truthful IPC assurance, and supply-chain bounds	External benchmark/evidence gated	Adaptive intent/exfiltration red team, sandbox escape, fuzz, cost/loop/IPC soak
DR-016	Linux-first modular core with explicit process, physical failure-domain, and administrative/key/audit boundaries	Owner-policy plus external evidence	PD-010/011 and all Phase-1 gates

18. Owner policy decisions

Every item requires recorded confirmation. The local implementation may test the safe default; it cannot silently convert the default into organizational policy.

PD	Recommended safe default	Viable alternative and consequence	Required confirmation
PD-001 Canonical human	Opaque domain principal mapped to OIDC issuer/subject; verified email alias/history	Email as authority is simpler but risks reassignment, issuer/domain collision, and migration ambiguity	Identity owner; approves refinement of ID-001/AUTH-003
PD-002 Enrollment/recovery	Owner-controlled WebAuthn UV plus exact-transaction, purpose-separated possession-bound automatic Approval delivery; the waiting process retains the secret and the browser/human receives no code, receipt, continuation, or private capability; legacy 128-bit claim-code delivery is compatibility-only; confirmation is independent of the enrolling harness; default server colocation uses distinct OS identities and reports `independent_boundary_proven=false`	Separately administered approval hosting is the optional high-assurance tier; extra people, hosts, and relay channels are not ordinary-onboarding prerequisites	Recorded for the ordinary self-hosted profile on 2026-07-19 and updated for automatic delivery on 2026-07-28; high-assurance administration/recovery evidence remains open
PD-003 Harness attenuation	Hard binding, revoke, proof, capability, freshness constraints now; posture/classification only after approval	No posture enlarges weak-device blast radius; broad opaque posture creates inconsistent denial	Explicit AUTH-003 clarification and appeal rules
PD-004 Elevation	One independent approver ordinary; two high-impact/break-glass; beneficiary cannot approve; short nonrenewable grants	One everywhere raises insider risk; two everywhere adds delay/fatigue	Risk classes, approvers, TTL/use, break-glass
PD-005 Post-revocation	Preserve accepted inert history only within authorized retention after ordinary offboarding; recheck custody, downloads, grants, and effects; quarantine conservative compromise windows	Purge-all enables censorship; acceptance-forever conflicts with legal erasure/minimization and preserves stale attacker effects	Event-class matrix plus legal erasure/hold compatibility and compromised_from adjudication
PD-006 Rooms/history	Creator/host domain owns one sequencer; separate recovery threshold; from-join history; explicit transfer; tombstone on unrecoverable loss	Multi-writer improves partition writes with major complexity; neutral owner adds trust/residency dependency	Governance, history, guests, retention, deletion/legal hold
PD-007 Visibility/E2EE	C1 managed default, C2 isolated services, C3 MLS only for sealed rooms; all inspection/recovery members visible; C3 LLM-provider exposure explicitly classified	Universal plaintext enlarges insider risk; universal E2EE removes managed service functions; C3 may permit approved provider, require local model, or be human-read-only	Privacy, security, legal owners; C3-at-launch, model-provider retention/training/residency, and LLM-member decision
PD-008 Partner assurance	Profiled home proof for ordinary access; fresh host-local reproof/admin for high risk	Home-only inherits partner failures; reproof-all adds friction/privacy burden	Per partner, resource, class, and action
PD-009 Revocation continuity	Host kill at next decision; no issuance during outage; privileged hold; bounded low-risk continuity to short-token expiry	Immediate deny couples availability; longer grace enlarges compromise window	Token TTL, signal SLO, outage ceiling, audit backlog
PD-010 Operations	Linux x86_64/arm64 first; RPO=0 for accepted_durable; one region; measured capacity/RTO and concrete host/failure-domain/admin/key/witness topology	All-OS/multi-region launch broadens unverified surface; weaker durability needs weaker state name	OS, scale, RPO/RTO, residency, quotas, staffing, co-location, witness redundancy/backlog; consolidates message/file/audit retention and legal-hold ownership with privacy/legal co-approval
PD-011 Attention	Routine traffic never notifies; content-free count only; notify exact approvals, confirmed incidents, expiring high-risk elevation, terminal unrecoverable failure with redacted metadata and no message content by default	More alerts interrupt/leak; no exceptional alerts delays response	Event classes, channels, quiet hours, redaction, escalation

ORG-006 remains a separate accountable-owner blocker. The implemented baseline fixes cryptographic/storage mechanics only. Before production use, the owner must record eligible proposers, exception signers and administrative revokers; thresholds and allowed circumstances; voluntary versus mandatory relationship handling; notice, review, appeal and retention; and how legal or incident authority is established. No implemented route or local test is that approval.

19. Must-not-ship gates

Release is blocked until relevant gates pass:

Foreground isolation: zero routine agent content, context, turns, focus/input changes, permission prompts, or automatic digest enters an active user session.
Worker recovery: kill, restart, and compact every communication worker at every state edge; accepted state rebuilds from supervisor/core with no cross-session contamination or duplicate effect.
Harness/worker isolation and model egress: Claude needs approved Channel or clean headless fallback with no remote permission relay; Codex approval routing remains independent; Pi RPC survives queued load with no cross-talk and processes no hostile semantic content without OS sandbox/model-only profile; Antigravity passes resume, cost, approval, status, clean-HOME, secret, filesystem, process, IPC, DNS, and network escape tests. Every semantic adapter proves a supervisor model-egress broker path with no worker vendor credential or generic proxy. A harness that fails is deterministic-only.
A2A: zero TCK MUST failures; reviewed SHOULD failures; HTTP+JSON/JSON-RPC advertisement/preference and binding/media/version mismatch; per-agent Card/route and tenant mismatch; standing-grant revoke; Task versus direct-Message result; all StreamResponse variants; unspecified role/state; server-owned IDs; input/auth-required; Task push-gap/duplicate reconciliation; direct-Message stream loss; credential-origin confinement; downgrade, trust, rotation, cache, revoke, enumeration, callback, SSRF, artifact, and cross-SDK tests pass.
MCP/local API: identical explicit tool round trip through every supported binding; Pi passes without MCP; no identity from arguments or token passthrough.
Identity/enrollment: OIDC mix-up/state/nonce/PKCE, OOB substitution, key proof, stolen-token, DPoP replay/audience/domain, rotation, recovery, offline revoke, and credential leakage tests pass for every advertised OS tier. No enrolling/enrolled harness can read or auto-complete the independent approval channel; same-machine Slack/Telegram fails unless a tested boundary proves independence.
Local IPC/signing oracle: wrong, sibling, same-user, PID-reuse, socket-replacement, copied-capability, arbitrary-sign, replay, flood, and broker-restart attempts yield zero unauthorized proof, signature, or token at the claimed assurance tier. If exact same-UID adapter attribution cannot be proven, the one-compromise-domain fallback allows only local draft, explicit human view, and deterministic non-business control—zero protected business message, task, room/file action, read, disclosure, export, download, key release, or effect.
Authorization and intent: schema/diagnostic/missing state denies; human entitlement is the only positive source; self/duplicate approval fails; one-use grant creates one reservation; committed revocation affects the next protected decision; every decision uses one coherent revision. Semantic-derived effects/disclosures also require an exact task grant and source/sink policy. Relationship proposals have zero authority; exact subordinate-owner consent, policy-exception consumption, a completed exact local activation intent for either basis, renewal, concurrent revoke/renew, subject exit, expiry, clean-start-v1 verification, and unsupported-store rejection pass lifecycle/race tests. The local intent is provenance, not an independent witness. ORG-006 owner approval—not hidden code—is additionally required before exception/admin-override/mandatory-relationship/notice/appeal policy can ship. Directional assignment tests prove that an in-scope administrator-to-subordinate task reaches accepted_queued, while subordinate-to-administrator and peer-to-peer tasks remain pending_human with zero execution unless a separate active may_assign edge authorizes the exact direction and scope. Typed incompatible intents enter atomic conflict_pending; only the exact current subordinate owner can decide a revision-bound complete partition, with stale/racing decisions fenced and overlapping rejects propagated before release. Omitted deadlines must be server-derived at whole-second precision, capped by the full scope duration and strictly before relationship expiry, and bound into request/event custody bytes. Generic mailbox, conversation, and supervisor paths must withhold task/task-linked-control payloads even when a marker is absent; no protected TaskGrant release route exists in the current build. Acceptance or conflict release must never bypass recipient-side data or effect authorization.
Durability: crash, hard reset, upload reservation/object/promotion permutations, concurrent retry/reservation expiry, missing-version recovery, required/optional attachment behavior, fanout, 1-hour/7-day/30-day offline, reconnect storm, failover, fencing, PITR, restore, and resource-pressure tests produce no accepted loss or available artifact without verified object+manifest under the declared model.
Delivery/effects/expiry: actor-owned per-recipient state-machine/property tests prove no completion/cancellation/global-success without owning evidence; effect_unknown is never blind-retried; idempotency/receipt contradictions are detected. Delivery expiry uses authoritative clock/policy evidence, cannot reopen on retry/late receipt, and races safely with commit/cancel/effect; retention remains independent. Exact content stays fetchable only during authorized retention.
Revocation: full acceptance/delivery/read/effect matrix passes for human, harness, recipient, room, guest, key-compromise window, domain quarantine, stale policy, and E2EE epoch; no sibling reroute.
Room authority: model-check one active owner, frozen immutability, transfer race/crash, key compromise, permanent loss, fork labeling, history, and MLS/application epoch independence.
Files/audit: hostile-file, decompression/parser, scanner substitution/staleness, lineage, object swap, E2EE linkage, authorization-at-download, cross-domain/tenant/class equality, timing/quota probing, non-disclosing duplicates, audit-intent crash at authorize→intent→capability/key/bytes release, bounded backlog, omission/gap/fork/witness, deletion/legal-hold, and restore tests pass.
Signed-peer abuse and intent: zero unauthorized or unintended protected effect, sensitive read, disclosure, or exfiltration. At least 1,000 adaptive trials per supported model/config is a floor, not proof: require independent generation, deterministic source/sink oracles, seeded secret canaries, data-class/effect coverage, statistical reporting, and full rerun after any model, harness, prompt, tool, parser, policy, or launch-profile change. Loop, fanout, reconnect, and cost floods stay within budgets and preserve safety capacity.
Supply chain: signed install/update/uninstall, threshold-root rotation, rollback/freeze rejection, SBOM/provenance, canary, compromised-adapter disable, and credential cleanup pass for every supported OS/architecture.
Operations/failure and component adoption: demonstrated backup restore; every trust role passes the §14.4 degraded/recovery contract and approved backlog/stop rules; minimum physical/admin topology is deployed; kill switches meet SLO under load; unsupported combinations fail or remain queued without security downgrade. Every adopted third-party component has a pinned version, license/provenance/SBOM review, self-hosted deployment, upgrade/rollback and data-egress assessment, failure/revocation/offline/duplicate tests, canonical-schema mapping, replacement plan, and a recorded bake-off against the simpler baseline. No greenfield subsystem is approved without recording why maintained candidates failed the relevant gates.
Policy: no feature relying on PD-001 through PD-011 launches until the accountable owner records the chosen default or alternative and accepts its consequence. ORG-006 independently blocks production claims for relationship exception/override, mandatory-relationship, notice, review, and appeal policy.
Discovery/version/config: authorization-filtered non-enumerating directory, stale/forged capability and key/endpoint rotation tests; authenticated profile handshake; N/N-1 rolling upgrade, critical-field, downgrade, queued-unsupported-event, rollback, and redacted config migration/rebinding tests pass.
Freshness/crypto/audit roots: exact vectors and boundary tests pass for proof age/skew/nonce/jti/cache persistence/key epochs; transport/DEK/KEK/decrypt ACL/backup/rotation profiles pass; catastrophic audit trust roots, independent log reconciliation, witness outage/backlog, and compromise rebuild are demonstrated.

Any unauthorized effect or exfiltration, false durable/completion claim, active-session injection, positive authority expansion, missing required audit intent, uncontained public gateway, or silent security downgrade blocks release regardless of average benchmark results.

20. Requirement-by-requirement verification

Status meanings:

Covered: the selected design directly addresses the requirement.
Changed hypothesis: the user’s proposed mechanism was compared and refined.
Owner decision: the architecture supplies a safe default, but human approval is still required.
External evidence gate: local design or implementation exists, but required target-environment or independent evidence remains open.

No row below claims implementation completion.

20.1 Product and interoperability

Requirement	Status	Design evidence and remaining proof
ARC-001 Separate extension	Covered	Supervisor, adapters, and core install independently of any harness (§4). Verify install, upgrade, removal, and credential cleanup.
ARC-002 Agent agnostic and reuse-first	Covered	Common corporate semantics sit above harness and reusable-component adapters; §6.6 requires narrow replaceable interfaces and forbids component-defined authority. Adapter and bake-off gates remain.
ARC-003 Four frontier harnesses	External evidence gate	Concrete Claude, Codex, Pi, Antigravity paths in §5. All four must pass isolation/recovery/version tests before GA.
ARC-004 Native A2A	External evidence gate; interpretation explicit	Each agent interoperates via the domain’s native client/server gateway; per-harness wire stacks are intentionally not required. Discovery, auth, Message/Task/Artifact mapping, versioning, TCK and negative tests are in §6.1 and gate 4.
ARC-005 Internal transport independent of A2A	Covered; bake-off pending	Corporate typed API and transactional semantics remain authoritative while AGNTCY SLIM and other maintained transports are evaluated rather than recreated (§6.3, §6.6, §14).
ARC-006 External trust isolation	Covered, gate pending	All public peers start external-low-trust; curated registry never grants membership by itself (§6.1). Gateway containment tests remain.

20.2 Identity and enrollment

Requirement	Status	Design evidence and remaining proof
ID-001 Verified human principal	Covered with owner clarification	Domain/OIDC principal plus verified email alias/history (§7.1). PD-001 approves refinement from raw email authority.
ID-002 Independently authenticated human confirmation	Design covered; external evidence gate	Exact transcript, WebAuthn UV outside the enrolling harness, and exact purpose-separated possession-bound broker delivery retained by the waiting process (§7.2). Browser/human receives no code or capability; legacy active claim-code delivery is compatibility-only. Shared-host default must preserve distinct OS identity/storage/credentials and report `independent_boundary_proven=false`; separate administration remains optional high-assurance evidence.
ID-003 No self-asserted identity	Covered	Payload claims ignored; principal and harness derive from authenticated context (§3, §7). Negative spoof tests remain.
ID-004 Cryptographic binding	External evidence gate	Per-domain/per-harness key, proof of possession, DPoP credentials (§7.2–7.3). Platform custody/replay tests remain.
ID-005 Signing-key enrollment hypothesis	Changed hypothesis	Retain PoP keys, but replace bare key exchange with OIDC, exact OOB approval, lifecycle, DPoP, and purpose-specific origin signatures.
ID-006 Human/harness distinction	Covered	principal_id and harness_id are distinct and both mandatory (§7.1).
ID-007 Harness-level revocation	Covered, gate pending	Credential/harness epochs revoke one installation without siblings (§7.3). Revocation tests remain.
ID-008 Domain-scoped identity	Covered	IDs and keys are per trust domain; federation creates host-local guest IDs (§7.1, §12).
ID-009 Credential lifecycle	Covered, external evidence gate	Issuance, storage tiers, rotation, expiry, loss, recovery, compromise, offboarding in §7.3; OS and incident drills remain.

20.3 Verified caller and authorization

Requirement	Status	Design evidence and remaining proof
AUTH-001 Verified caller on every operation	Design covered; actor union explicit	Business/protected requests resolve human or host guest + exact harness. Service receipts resolve a scoped workload and, for any data/effect, an authorized parent human event/task grant. External A2A remains unverified-low-trust (§3, §7.1).
AUTH-002 Identity bound to proof	Covered, gate pending	TLS/DPoP, workload mTLS, local IPC, purpose-specific signatures; never payload prose (§6–8).
AUTH-003 User-level permissions	Covered with owner clarification	Positive entitlement only at human; harness constraints deny-only (§8.1). PD-003 approves precise attenuation semantics.
AUTH-004 Harness attribution	Covered	Harness/session/credential epoch recorded on events, decisions, and audit (§7–9).
AUTH-005 No authority escape	Covered	Task and management relations cannot carry positive data permissions (§8.2–8.3). Property tests remain.
AUTH-006 Hub-side gating	Covered by same-extension server role	Edge PEP and current policy check precede sensitive existence disclosure or effect; no separate Hub identity exists (§4, §8).
AUTH-007 Fail closed	Covered, gate pending	Missing/stale/diagnostic/inconsistent state denies (§8.1). Error and outage corpus remains.
AUTH-008 Human-approved elevation	Covered	Independent exact-transaction approval service (§8.4).
AUTH-009 Constrained elevation	Covered, gate pending	Scoped, expiring, non-self-approved, use-counted, revocable grant object (§8.4). Atomicity tests remain.
AUTH-010 Approval policy	Owner decision	Safe thresholds and alternatives in PD-004 (§18).

20.4 Organizational relationships

Requirement	Status	Design evidence and remaining proof
ORG-001 Multiple administrators	Implemented locally	Bilaterally active, exact directed pairs form a many-to-many graph (§8.2); production policy/evidence gates remain.
ORG-002 Multiple subordinates and downward assignment	Implemented locally	Current scoped `may_assign` edges permit automatic `accepted_queued` custody with an exact explicit or server-derived, whole-second, scope/relationship-bounded deadline. Generic reads disclose only a custody reference and no protected TaskGrant release route exists, so custody grants no execution authority (§8.2–8.3).
ORG-003 Graph, not tree	Implemented locally	Relations are explicit, typed, versioned, consent-bound, and pair/lifecycle-fenced (§8.2).
ORG-004 Management not data authority	Implemented locally	Exact completed local activation intent and assignment checks limit the edge to custody meta-actions. Task/task-linked-control payloads are withheld from generic mailbox, conversation, and supervisor reads, including records with no marker; no protected-data, semantic, tool, or effect authority is granted (§8.2).
ORG-005 Directional assignment and conflict resolution	Implemented locally	Downward scoped assignments may auto-queue; upward/lateral assignments remain `pending_human` unless a separate active directed edge exists. Exact relationship revision, owner/credential/policy epochs, expiry, and revoke/renew fencing are implemented. Typed incompatible intents enter atomic, arrival-order-independent `conflict_pending`; exact current subordinate-owner adjudication binds all members and revisions, permits only compatible releases, fences races/replay/drift, propagates overlapping rejects, and queues only fully unblocked custody. It grants no data, semantic, tool, or effect authority (§8.2 and gate 8). Production owner and external evidence gates remain.
ORG-006 Relationship lifecycle	Mechanics implemented; accountable-owner blocked	Zero-authority proposal, exact current subordinate human/guest-owner consent, separately recorded/consumed exception mechanism, and a completed exact local activation intent for either basis, plus renewal, expiry, subject exit/admin-revoke mechanism, race fencing, clean-start schema-v1 verification, and unsupported-store rejection are implemented. The activation intent is local provenance, not an independent witness. Eligible roles, exception/override circumstances/thresholds, mandatory relations, notice/review/appeal, retention, and production evidence remain unapproved (§8.2, §18, gate 17).

20.5 Communication and collaboration

Requirement	Status	Design evidence and remaining proof
COM-001 Agent-to-agent	Covered	Canonical direct events and mailboxes (§9.1).
COM-002 Agent-to-hub	Covered by same-extension server role	Supervisor to the ordinary AgentNet core/effect role on an always-on server agent (§4, §9).
COM-003 Hub-to-agent	Covered by same-extension server role	Durable recipient mailbox and cursor delivery from an ordinary always-on AgentNet installation (§9.5–9.6).
COM-004 Hub-to-hub	Covered as server-agent relay; federation gate pending	Domain-owned relay receipts and federation/public gateways between ordinary AgentNet installations (§9.3, §12).
COM-005 Group topologies	Covered	Per-recipient fanout state supports all cardinalities (§9.1, §9.4).
COM-006 Direct conversations	Covered	Conversation/thread objects and durable events (§9).
COM-007 Manager communication	Covered	Direct communication is bidirectional, while automatic task acceptance follows authenticated directed management edges and scope (§8.2–8.3, §9.1).
COM-008 Rooms and meetings	Covered, external evidence gate	Persistent/temporary room model, membership, governance, history, artifacts (§10).
COM-009 Participant clarity	Covered with minimization	Corporate contributions show scoped verified human/guest label, domain, harness, optional session; service facts show workload role; public A2A shows external-human-unverified. Email mapping is restricted (§7.1, §9.1–9.2).
COM-010 Room governance	Owner decision plus model gate	Creation, membership, moderation, history, guests, archive/delete, transfer in §10 and PD-006.
COM-011 Conversation semantics	Covered	Threads, replies, mentions, tasks, handoffs, cancellation, receipts, completion/unknown states (§9).

20.6 Files and artifacts

Requirement	Status	Design evidence and remaining proof
FILE-001 First-class sharing	Covered	Artifact references work in every event topology (§9.1, §11).
FILE-002 Identity and authorization	Covered	Current authorization at upload, release, relay, preview, download, and key release (§11.1).
FILE-003 Offline survival	Design covered; durability gate	Staged object-version→verification→manifest/event transaction, holds/orphans, restore, and durable mailbox (§11.4, §14).
FILE-004 Integrity/provenance	External evidence gate	Immutable digests, exact origin/derivation/scan evidence, and the initial DSSE/in-toto interoperability profile (§11.2).
FILE-005 Storage/retention	Owner decision	Versioning, encryption, quotas, dedup, lifecycle, WORM/legal hold modeled. PD-010 consolidates message/file/audit retention, with PD-006/007 plus privacy/legal co-approval.
FILE-006 Content safety	External evidence and owner gate	Quarantine, scanner sandbox, DLP/malware/polyglot/archive/executable rules (§11.3).

20.7 Availability and durable delivery

Requirement	Status	Design evidence and remaining proof
AVL-001 Mixed availability	Covered	Local supervisors plus always-on corporate core (§4, §9.6).
AVL-002 Offline is normal	Covered	Offline presence is distinct from identity/revocation (§9.6).
AVL-003 Durable store-and-forward	External evidence gate	Local encrypted queue, PostgreSQL mailbox, object store, cursor reconciliation (§9.6, §14).
AVL-004 Baseline logical Hub and future hubless profile	Covered by one ordinary extension; future gates pending	The same AgentNet package composes continuously available server-agent roles with redundant production deployment; there is no separate Hub product or identity. Section 9.7 preserves direct, opportunistic-relay, and fully distributed upgrade paths without central-instance identifiers or authority (§9.7, §14).
AVL-005 No silent loss	Covered, state tests pending	Explicit acceptance, queue, delivery, commit, expiry, rejection, failure, unknown, DLQ states (§9.4).
AVL-006 Delivery guarantees	Covered, external evidence gate	At-least-once, idempotency, dedup, causal sequence, replay, cancellation, reconciliation (§9.5).
AVL-007 Hub failure and hubless operation	External evidence/owner gate	HA, synchronous durability boundary, fencing, PITR, and restore protect the first production server-agent profile; future mesh/distributed modes require custody, quorum, partition, sequencing, policy-freshness, and revocation gates. There is no separate Hub product (§9.7, §14, PD-010).
AVL-008 Presence	Covered, external evidence gate	Expiring live/recent/stale/unknown lease, never authority (§9.6).

20.8 Non-interrupting user experience

Requirement	Status	Design evidence and remaining proof
UX-001 Separate sessions	External evidence gate	Dedicated worker per harness (§5). Four-harness interference tests required.
UX-002 Never interrupt flow	External evidence gate	No foreground content, turns, focus, input, or approvals (§5.1, gate 1).
UX-003 Passive indication	Partially covered preference	Content-free count where safe; researched Codex has no verified compliant passive surface and is explicit-pull only. No-indicator fallback protects the HARD UX requirements (§5).
UX-004 Noninteractive indicator	Covered, gate pending	No content or demanded interaction; status-only adapter surfaces (§5.1).
UX-005 Attention policy	Owner decision	Only approvals, confirmed incidents, expiring high-risk elevation, terminal unrecoverable failure by PD-011.
UX-006 Harness fallback	Covered	Headless/dedicated worker plus no indicator; explicit inbox only (§5).

20.9 Federation and contractors

Requirement	Status	Design evidence and remaining proof
FED-001 Multi-company future	Covered	Bilateral profile and separate gateway (§12).
FED-002 Internal user in external network	Covered	External host creates its own guest identity/grants; same non-transitive model (§12).
FED-003 External guest internally	Covered	Sponsor invitation, home assertion, pairwise key, host-local guest/credential (§12).
FED-004 Least privilege	Covered	Exact resources/actions/classes/expiry and host-local grant (§12).
FED-005 No transitive trust	Covered	Explicit invariant; A→B never creates B→C (§12).
FED-006 Domain context	Covered	Distinct IDs, keys, audiences, policy, and receipts per host domain (§7, §12).
FED-007 Federation model	Changed open question	Bilateral host-controlled federation selected; multilateral deferred (§12, §16).
FED-008 External assurance	Owner decision	Profiled home proof for ordinary, host-local reproof for high risk (PD-008).
FED-009 Audit/revocation	External evidence and owner gate	Host kill, home signals, dual-domain receipts, sponsor lifecycle, incident ownership (§12, PD-009).

20.10 Security, privacy, and accountability

Requirement	Status	Design evidence and remaining proof
SEC-001 Threat model	Design covered; adversarial gate	Candidate controls and catastrophic trust roots are explicit (§4.4, §13.5); campaigns remain.
SEC-002 Encryption	Design/owner/external evidence gate	Transport floor, device keys, domain/tenant/class DEK/KEK hierarchy, decrypt ACLs, backup/rotation, C1/C2/C3 profiles (§7.4, §13.1).
SEC-003 Auditability	Design covered; external evidence gate	Core-mediated transactional intents, independent logs/exporter/WORM/witness, assurance limits, backlog/outage/compromise rebuild (§4.4, §14.4).
SEC-004 Privacy/minimization	Design covered; owner gate	C0–C3 content and metadata matrix, scoped participant identity/dedup/indexes, retention/disclosure policy (§11.1, §13.1).
SEC-005 Replay/freshness	Design covered; external evidence gate	Versioned proof-age/skew/nonce/jti/cache/sequence/key-epoch/failure profile (§7.4).
SEC-006 Compromise containment	Design covered; drills pending	Conservative compromise window, one-domain same-UID fallback, dependency failure matrix, quarantine/rekey/rebuild (§4.1, §7.3, §14.4).
SEC-007 Extension trust	External evidence gate	Signed packages, SBOM/provenance, threshold updates, canary/rollback, zero-secret adapters (§13.4).

20.11 Operations and implementation

Requirement	Status	Design evidence and remaining proof
OPS-001 Hub definition and replaceability	Covered by one ordinary extension	An always-on AgentNet installation is a self-hosted composition of mailbox, policy, effect/data, gateway, artifact, and audit roles, not a separate product or identity; transport-neutral event and custodian interfaces preserve future peer-assisted replacement (§4, §9.7, §14.3).
OPS-002 Discovery	Design covered; external evidence gate	Non-enumerating authorization-filtered internal directory plus curated A2A/partner metadata and conformance probes (§6.4, §12).
OPS-003 Versioning	Design covered; conformance gate	Authenticated profile handshake, critical fields, no security downgrade, N/N-1 expand/migrate/contract, rollback/deprecation (§6.5).
OPS-004 Observability	Covered, external evidence gate	Privacy-aware delivery, DB, authorization, scanner, audit, cost, adapter metrics (§14.2).
OPS-005 Resource controls	Covered, soak gate	Multi-dimensional quotas, fair queues, breakers, attenuated sub-budgets, safety capacity (§13.3).
OPS-006 Portability and infrastructure independence	Design/owner/external evidence gate	Versioned redacted config, secret rebinding, independent installer, Linux-first, and self-hosted corporate services; cloud/provider integrations are optional adapters, never mandatory (§6.5, §9.7, §14.2, PD-010).
OPS-007 Test strategy and reuse bake-off	Covered	Nineteen must-not-ship gates plus §6.6 require pinned component evaluation, semantic mapping, failure/revocation/offline/duplicate tests, operational comparison, and documented build-versus-reuse decisions (§6.6, §15, §19).

20.12 Verification result

85 of 85 baseline requirements are explicitly addressed by the design.
2 implementation hypotheses changed: signing-key-only enrollment (ID-005) and a separate single/monolithic Hub product (AVL-004); the implemented shape is one ordinary AgentNet extension on laptops and always-on server agents.
1 HARD requirement interpretation is explicit: ARC-004 is delivered by the extension’s native domain gateway on behalf of each enrolled agent, not by embedding a separate A2A stack in every harness.
A second HARD requirement interpretation is explicit: AUTH-001 uses a typed actor union—business/protected submissions require verified human/host guest + exact harness; workload facts require scoped workload + parent human authority chain; unadmitted A2A remains external-human-unverified.
11 owner policy decisions remain: PD-001 through PD-011.
External, benchmark, conformance, owner, and operations gates remain before any production “satisfied” claim.
No requirement was rejected as an outcome. Several proposed mechanisms were replaced with safer mechanisms that preserve the intended outcome.

21. Primary-source research index

Key sources used by the three research and re-research rounds, retrieved or rechecked 2026-07-12. This index is explanatory, not the release lockfile. Any URL using latest, current, main, or master is a supplemental drift check; every release manifest pins the exact specification release, SDK tag/commit, TCK commit/report, internal profile hash, and retrieval date.

Protocols and harness integration

Pi and Antigravity adapter findings also relied on the exact locally installed documentation and binaries recorded in Claude’s resolution memo. Antigravity’s agy 1.1.1 surface evidence is single-source to that local probe—the Codex probe did not have Antigravity installed—so the release environment must reproduce it before reliance.

Identity, authorization, and federation

Delivery, rooms, E2EE, files, and operations

22. Final recommendation

Continue the local conformance and release kernel while closing every locally implementable accepted finding. Production enablement remains separate: it requires the named external, target-platform, accountable-owner, benchmark, and operations evidence without reopening the one-extension product boundary.

The product should be described as:

A secure, agent-agnostic corporate communication extension that gives each machine a durable communications supervisor, gives every harness a separately identified background worker, gives each corporate domain a transactional mailbox and policy authority, and exposes native A2A only through an isolated low-trust gateway.

The accountable owners must approve or change PD-001 through PD-011. Release review must preserve the already implemented supervisor/adapter, identity, authorization, mailbox, governance, provenance, artifact, and A2A boundaries while requiring their still-open target-environment evidence before enabling federation, E2EE, protected semantic execution, or production durability claims.

FilesExpand file tree

specification.md

Latest commit

History