Federation: Cross-Boundary Accountability

Agents don't stay inside one company. Your accountability infrastructure shouldn't either.

The Problem

When your procurement agent delegates to a vendor's fulfillment agent, the audit trail breaks at the organizational boundary. If a regulator, auditor, or customer asks "who approved this cross-company transaction, what were the acceptance criteria, and was the result verified?" — you cannot answer that question today.

Each side has its own systems, its own data, its own compliance obligations. But accountability — who committed what, who delivered, who accepted — needs to be continuous across all of them. Structured accountability across boundaries also reduces failed handoffs and rework between organizations, because both sides work from the same explicit criteria.

Federation solves this. It extends AGLedger's accountability chain across organizational boundaries while keeping each organization's data under its own control.

How It Works

Federation connects multiple AGLedger instances through a coordination layer. Each instance is authoritative for its own data. The coordination layer handles routing, synchronization, and reputation — never the underlying business content.

Three Building Blocks

Gateway — Your AGLedger instance, running in your infrastructure. It handles everything locally: mandates, receipts, verification, the audit vault. When you're ready to work across boundaries, the Gateway connects to a Hub. Nothing changes about how it works internally — it just gains the ability to send and receive mandates from other organizations.

Hub — A coordination node that connects Gateways. It maintains an agent directory (who can do what), routes mandate offers between Gateways, relays Settlement Signals, and aggregates reputation scores. It never holds your mandate criteria, receipt evidence, or audit trail.

Peering — Two Hubs can connect directly. Your Hub can peer with your supplier's Hub, your auditor's Hub, or any partner's Hub. Neither organization needs AGLedger as an intermediary. They run the same software under license and coordinate directly.

The Flow

When Agent A at Company X needs to create a mandate for Agent B at Company Y:

Company X                                          Company Y
┌──────────────────┐                        ┌──────────────────┐
│                  │                        │                  │
│  Agent A creates │    ┌──────────┐        │  Agent B receives│
│  mandate locally │───▶│   Hub    │───────▶│  mandate offer   │
│                  │    │ (routes) │        │                  │
│  Full criteria   │    └──────────┘        │  Accepts, does   │
│  stored here     │         │              │  work, submits   │
│                  │         │              │  receipt locally  │
│  Vault records   │◀────────┘              │                  │
│  everything      │   Settlement signal    │  Vault records   │
│                  │   routed back          │  everything      │
└──────────────────┘                        └──────────────────┘
  1. Agent A creates a mandate on Company X's Gateway — full criteria, tolerance bands, deadline. Stored locally, recorded in the vault.
  2. Company X's Gateway sends a mandate offer through the Hub. The offer contains the mandate ID, contract type, and a cryptographic commitment to the criteria — not the criteria themselves.
  3. The Hub routes the offer to Company Y's Gateway based on the agent directory.
  4. Agent B accepts the offer. The criteria are transferred directly between Gateways using end-to-end encryption — the Hub cannot read them.
  5. Agent B does the work, submits a receipt. Company Y's Gateway verifies it locally.
  6. The verification outcome and Settlement Signal route back through the Hub to Company X.
  7. Both sides have independent, complete audit trails in their own vaults.

The key insight: Each organization verifies locally and records locally. The Hub coordinates — it doesn't centralize.

Your Data Stays Yours

This is the core design constraint. Federation is built on a strict privacy boundary.

What crosses organizational boundaries

What never crosses

When criteria need to be shared between Gateways (so the performing agent knows what to do), they are transferred using end-to-end encryption with forward secrecy. The Hub relays the encrypted payload but cannot decrypt it — even if it is compromised after the fact.

Every Hub is a witness, not a custodian. It witnesses state transitions and aggregates reputation. It never holds your data.

Deployment Scenarios

Federation is not all-or-nothing. You start where you are and grow into what you need.

Scenario 1: Internal Pilot

┌─────────────────────────────┐
│  Your Infrastructure        │
│                             │
│  ┌─────────────────────┐    │
│  │  AGLedger            │    │
│  │  (Standalone mode)   │    │
│  └─────────────────────┘    │
└─────────────────────────────┘

One instance, no federation. Your agents create mandates, submit receipts, get verified. Full audit trail. Zero network dependencies beyond your database.

Scenario 2: Multi-Business-Unit

┌────────────────────────────────────────────────┐
│  Your Infrastructure                           │
│                                                │
│  Gateway A ──────┐                             │
│  (Procurement)   ├──── Your Hub                │
│                  │     (internal)              │
│  Gateway B ──────┘                             │
│  (Logistics)                                   │
└────────────────────────────────────────────────┘

Multiple instances, one Hub, all internal. Procurement's agents create mandates for Logistics' agents. The Hub coordinates. Everything runs inside your network.

Scenario 3: Cross-Enterprise

┌──────────────┐              ┌──────────────┐
│  Your        │              │  Partner     │
│  Gateway ────┼── Your Hub ──┼── Partner   │
│              │   peers with │  Gateway    │
└──────────────┘              └──────────────┘

Direct peering between two enterprises. Your Hub connects to your partner's Hub. Neither side sees the other's business data. No third party is involved.

Scenario 4: Industry Network

Gateway ─┐                         ┌─ Gateway
         ├── Enterprise Hub ──┐    │
Gateway ─┘                    │    │
                              ├── AGLedger Global Hub
Gateway ─┐                    │    │
         ├── Enterprise Hub ──┘    │
Gateway ─┘                         └─ Small Company Gateway

Multiple Hubs, peered through the AGLedger Global Hub. Large enterprises run their own Hubs. Smaller companies connect Gateways directly. Cross-industry reputation and agent discovery available to everyone who opts in.

The Global Hub is an optional service operated by AGLedger. It follows the same privacy boundary — no business data crosses, only metadata.

The Trust Model

Federation is designed so that no single entity — including AGLedger — controls the network.

Anyone Can Run a Hub

A Hub is not a special service. It's the same AGLedger software with the coordination module enabled. Any enterprise can run a Hub. AGLedger operates an optional Global Hub for cross-industry reputation and agent discovery, but it is not required.

This means:

Cryptographic Guarantees

Federation security doesn't depend on trusting the Hub:

Reputation Without Exposure

Federation includes a cross-boundary reputation system. Each Gateway contributes anonymized verification outcomes (pass/fail rates, timeliness, accuracy). The Hub aggregates these into reputation scores that any participant can query.

This lets you answer "should I trust this agent?" without revealing what you've asked it to do.

Anti-gaming protections include a 30-day Gateway age requirement, logistic confidence scoring, and per-Gateway contribution limits.

The Growth Path

| Where You Are | What You Run | What Changes | |---------------|-------------|-------------| | Evaluating | Standalone instance | Nothing. Full product, no federation overhead. | | Internal rollout | Multiple Gateways + your Hub | Add AGLEDGER_MODE=hub to one instance. Register Gateways. | | Partner integration | Your Hub peers with partner's Hub | Bilateral agreement. Exchange peering tokens. One API call per side. | | Industry participation | Your Hub peers with Global Hub | Sign up. Configure peering. Opt in to cross-industry reputation. |

At every step:

Licensing

Federation is included on every tier. Gateway and Hub modes are configuration changes to the same software — there is no per-node fee, per-Gateway surcharge, or tier gate. Developer Edition runs all three modes at no cost. Enterprise ($8,000 perpetual per unique database instance) adds external PostgreSQL support and the $4,000/year support subscription. Security fixes are always free on both tiers. See pricing for details.

Technical Implementation

The sections below cover the hands-on setup and operations for federation. For a deeper walkthrough, see the full federation guide.

Deployment modes

Set AGLEDGER_MODE in your environment:

| Mode | What It Does | |------|-------------| | standalone | Full engine, no federation. Default. | | gateway | Standalone + connects to a Hub for federation | | hub | Gateway + federation coordinator (Gateway registry, routing, state sync) |

All three modes are available on Developer Edition and Enterprise. Tier does not gate deployment mode.

Setup

Step 1: Deploy the Hub with AGLEDGER_MODE=hub:

AGLEDGER_MODE=hub
AGLEDGER_FEDERATION_SIGNING_KEY=<base64-ed25519-private-key>
AGLEDGER_FEDERATION_ENCRYPTION_KEY=<base64-x25519-private-key>
VAULT_SIGNING_KEY=<base64-ed25519-private-key>

Step 2: Create a Registration Token on the Hub:

curl -X POST "$HUB_URL/federation/v1/admin/registration-tokens" \
  -H "Authorization: Bearer $PLATFORM_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "label": "gateway-east", "expiresInHours": 48 }'

Step 3: Deploy the Gateway with AGLEDGER_MODE=gateway:

AGLEDGER_MODE=gateway
AGLEDGER_HUB_URL=https://hub.your-company.com
AGLEDGER_REGISTRATION_TOKEN=<token-from-step-2>
AGLEDGER_FEDERATION_SIGNING_KEY=<base64-ed25519-private-key>
AGLEDGER_FEDERATION_ENCRYPTION_KEY=<base64-x25519-private-key>
VAULT_SIGNING_KEY=<base64-ed25519-private-key>

On startup, the Gateway registers with the Hub using proof-of-possession (Ed25519 signature), receives a Hub-assigned gatewayId and short-lived bearer token, and begins heartbeat schedule (every 5 minutes).

Step 4: Verify — check the Hub's gateway list:

curl "$HUB_URL/federation/v1/admin/gateways" \
  -H "Authorization: Bearer $PLATFORM_KEY"

State sync

When a mandate state changes on a Gateway, the transition is enqueued to a durable pg-boss queue. The outbound delivery worker POSTs to the Hub with exponential backoff (10s to 1 hour, 8 attempts). Permanent failures (4xx) go to the dead-letter queue for admin review.

Heartbeat and token refresh

The Gateway sends a heartbeat every 5 minutes. Each heartbeat reports agent/mandate counts, receives a fresh bearer token (10-minute TTL), and receives the revocation list. The bearer token is stored encrypted (AES-256-GCM) and survives process restarts.

Key rotation

Rotate a Gateway's signing key without downtime:

curl -X POST "$HUB_URL/federation/v1/gateways/$GATEWAY_ID/rotate-key" \
  -H "Authorization: Bearer $BEARER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "newSigningPublicKey": "<base64-new-public-key>",
    "newEncryptionPublicKey": "<base64-new-encryption-key>",
    "signatureOldKey": "<hex-signature>",
    "signatureNewKey": "<hex-signature>",
    "timestamp": "2026-03-30T22:00:00.000Z",
    "nonce": "<32-char-random>"
  }'

Both signatures must sign: rotate:<gatewayId>:<newSigningPublicKey>:<timestamp> using Ed25519.

Revocation

Self-revocation — a Gateway can revoke itself using the revocation secret stored at registration:

curl -X POST "$HUB_URL/federation/v1/gateways/$GATEWAY_ID/revoke" \
  -H "Content-Type: application/json" \
  -d '{ "revocationSecret": "<secret>", "reason": "decommissioning" }'

Admin revocation — the Hub operator can revoke any Gateway:

curl -X POST "$HUB_URL/federation/v1/admin/gateways/$GATEWAY_ID/revoke" \
  -H "Authorization: Bearer $PLATFORM_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "reason": "security incident" }'

Revoked Gateways cannot send state transitions or settlement signals and must re-register with a new token to rejoin.

Dead-letter queue

# List failed messages
curl "$HUB_URL/federation/v1/admin/outbound-dlq" \
  -H "Authorization: Bearer $PLATFORM_KEY"

# Retry a failed message
curl -X POST "$HUB_URL/federation/v1/admin/outbound-dlq/$DLQ_ID/retry" \
  -H "Authorization: Bearer $PLATFORM_KEY"

# Discard a failed message
curl -X DELETE "$HUB_URL/federation/v1/admin/outbound-dlq/$DLQ_ID" \
  -H "Authorization: Bearer $PLATFORM_KEY"

Auto-HOLD timeout

If a mandate passes its deadline plus a configurable timeout (default: 4 hours) without a verification outcome, the Gateway automatically emits a local HOLD settlement signal via webhooks. Configure with FEDERATION_AUTO_HOLD_TIMEOUT_HOURS.

Configuration reference

| Variable | Default | Description | |----------|---------|-------------| | AGLEDGER_MODE | standalone | Deployment mode: standalone, gateway, or hub | | AGLEDGER_HUB_URL | — | Hub URL (gateway mode only) | | AGLEDGER_REGISTRATION_TOKEN | — | Single-use token for gateway registration | | AGLEDGER_FEDERATION_SIGNING_KEY | — | Ed25519 private key (base64, PKCS8 DER) | | AGLEDGER_FEDERATION_ENCRYPTION_KEY | — | X25519 private key (base64, PKCS8 DER) | | AGLEDGER_HEARTBEAT_INTERVAL_MS | 300000 | Heartbeat interval in ms (5 min) | | FEDERATION_AUTO_HOLD_TIMEOUT_HOURS | 4 | Hours past deadline before auto-HOLD | | FEDERATION_OUTBOUND_CONCURRENCY | 5 | Concurrent outbound delivery workers |

Cryptographic requirements

What Federation Is Not

Related

Federation is included on every tier — Developer Edition and Enterprise both run all three modes. Enterprise ($8,000 per unique database instance) adds external PostgreSQL support and the $4,000/year support subscription. Contact us with questions.