Xail — Agent Security SDK
@xail/agent-sdk

When agents control real-world actions, a forged instruction is not a data breach. It is a physical event.

Doors open. Funds move. Firmware overwrites. A single compromised channel can fabricate any instruction — unless the instruction never exists as a complete artifact in any single channel. XorIDA splits every payload across independent providers. Fewer than k shares reveal zero information. Not "hard to break." Mathematically impossible.

88% Enterprises Hit

AI agent security incidents in the past year

¹ HelpNetSecurity, Feb 2026
45.6% Still on API Keys

of teams use shared keys for agent auth today

² Gravitee, 2026
$52.6B Market by 2030

enterprise multi-agent — 340% YoY growth

³ TechFundingNews, 2026
136 Passing Tests

XorIDA known-answer vectors, fuzz-tested, statistically verified for share independence.

⁴ packages/crypto/ — 100% line coverage
APIs have keys. ACIs have identity. xail is the Authenticated Cryptographic Interface for agent security.
What changes in practice

Three guarantees you cannot get from API keys, JWTs, or TLS alone

These are not features on a roadmap. They are properties of the cryptographic architecture — enforced by mathematics, not by policy configuration.

30s
Bounded blast radius — a leaked key is a 30-second problem, not an indefinite one

A leaked API key is unbounded — full access, all endpoints, forever, until someone notices and rotates. A leaked Xail signing key is bounded by three independent constraints:

Temporal bound (30 seconds): Every envelope carries a cryptographic timestamp. The verifier rejects anything older than 30 seconds. A stolen signing key allows forgery only within this window — no rotation ceremony needed. The window closes itself.
Scope bound: A DID scoped to finance.invoice.approve cannot call firmware.update.deploy. Scope is signed into every individual envelope and checked against the trust graph on every request. No god-mode keys. No lateral movement.
Content independence: The Ed25519 signing key and the AES-256-GCM payload decryption key are entirely separate. Stealing a signing key does not let you read any encrypted content on the wire. Authentication and content are cryptographically independent.

Compare: a standard API key gives the attacker both authentication and access to encrypted payloads. Xail separates these concerns at the cryptographic layer.

Offline-resilient authentication — your agents keep working when the network doesn't

The trust registry resolves DIDs to public keys at first contact. After that, public keys are cached locally. Your agents authenticate each other directly — the registry is not in the message delivery path.

Normal operation: Agent A boots, resolves Agent B's DID from the registry, caches the public key. All subsequent requests authenticate directly — no registry call per message.
Registry unreachable: If the registry goes down mid-day, existing agent-to-agent communication continues uninterrupted. Cached keys are sufficient for authentication. No degraded mode. No fallback logic.
Revocation still works: When a compromised agent needs to be revoked, the registry check catches it on the next key refresh. You don't depend on an external service for every request, but revocation still propagates.

This matters for IoT, edge deployments, and any environment where network reliability cannot be assumed. The registry is a phone book, not a gatekeeper.

Per-request replay protection — every request is unique and non-replayable

Every envelope carries a 128-bit cryptographic nonce and a 30-second timestamp window. This is per-request, not per-credential — each individual request is unique and cannot be replayed.

Message replay: Dead. A captured request cannot be re-submitted. The nonce has already been consumed and the timestamp has expired.
Envelope replay: Dead. A captured command — firmware update, financial transaction, access control instruction — cannot be re-POSTed. The nonce store rejects it immediately.
No credential-level tradeoffs: Traditional systems often weaken replay protection to avoid breaking access patterns. Xail's nonce model operates at the request layer, not the credential layer — your credential issuance logic is unaffected.

Nonce + timestamp + Ed25519 signature + scope — all four are verified before your handler executes. The middleware enforces this automatically.

Transport-layer defense

Agent instruction injection is the new SQL injection

When Agent A tells Agent B unlock door 4 over a single transport channel, anyone who compromises that channel can substitute unlock all doors. TLS doesn't help — the attacker is often the transport operator, a compromised endpoint, or a man-in-the-middle at the provider. Every content-based defense (input filtering, classifier detection, LLM firewalls) can be bypassed by a sufficiently adaptive payload. The structural defense cannot.

Single-channel delivery
Complete instruction travels through one provider — one point of compromise delivers a complete forgery
TLS protects the pipe, not the content — the endpoint operator can read and modify
Content-based defenses (Lakera, CaMeL, LLM firewalls) are probabilistic — adaptive payloads bypass them
A forged instruction to a physical system — doors, payments, dosage, firmware — is irreversible
XorIDA split-channel delivery
Instruction split into n shares across independent providers — each share is mathematical noise
Compromising fewer than k channels yields zero bits of the instruction — regardless of computational power
Reconstruction only at the recipient from k verified shares — per-share HMAC + Ed25519 signature + threshold consistency
The defense is structural and transport-layer — operates before any LLM or application logic sees the instruction
This is not prompt filtering. Content-based injection defenses inspect the instruction and try to distinguish legitimate from malicious. They fail against adaptive payloads. XorIDA split-channel operates at the transport layer — the instruction never exists as a complete artifact in any single channel. There is no content to filter because there is no complete instruction to inspect. The defense is independent of what the attacker puts in the channel, independent of payload sophistication, and independent of computational resources applied to the captured shares.
The physical consequence test

If your agent controls something physical — a door, a drug infusion pump, a power relay, a financial transaction — ask this question: what happens if an attacker on your network substitutes one instruction for another?

"Unlock unit 42" becomes "unlock all units."
"Dispense 10mg" becomes "dispense 100mg."
"Approve $1,400" becomes "approve $140,000."

Content filters inspect the instruction and try to distinguish legitimate from malicious. A sufficiently crafted payload passes. XorIDA split-channel means the instruction never exists as a complete artifact in any single channel. There is no payload to craft. The defense is architectural.
Quick start

Four concepts. Everything else is invisible.

01
Create an identity
Ed25519 keypair generated, DID registered in trust registry. One call at provisioning time. Private key never leaves the agent.
02
Send — direct mode
Payload encrypted to recipient, signed (encrypt-then-sign order), delivered over HTTPS. Sender authenticated, replay impossible, scope locked.
03
Send — split-channel mode
Pass splitChannel: true. XorIDA splits the ciphertext across n independent provider endpoints. No single provider can reconstruct or modify the instruction. Zero information below threshold. This is the structural prompt injection defense.
04
Receive — verified middleware
Drop agent.middleware() on any Express or Fastify route. Timestamp, nonce, signature, scope — all checked. req.agentMessage is verified or the request never reaches your handler.
agent-setup.ts
import { Agent } from '@xail/agent-sdk';

// 1. Create identity (once, on provisioning)
const agent = await Agent.create({
  name: 'invoice-processor',
  registry: 'https://atelier.xail.io',
});

// 2. Send — signed + encrypted
await agent.send({
  to: 'did:xail:service-accounts-payable',
  payload: { invoiceId: 'INV-2847', amount: 14200 },
  scope: 'finance.invoice.approve',
});

// 3. Split-channel — no provider sees full content
await agent.send({
  to: 'did:xail:service-accounts-payable',
  payload: { invoiceId: 'INV-2847', amount: 14200 },
  scope: 'finance.invoice.approve',
  splitChannel: true,  // ← the feature nobody else has
});

// 4. Receive — verified middleware
app.post('/agent/inbox', agent.middleware(), (req, res) => {
  const { sender, payload, scope } = req.agentMessage;
  // sender verified · payload decrypted · scope checked
});
Installation

Drop into any Node.js agent stack

No new infrastructure required for the identity layer. Uses your existing Postgres and Redis. Split-channel delivery requires @xail/crypto as a peer dependency — the XorIDA implementation.

The SDK ships with built-in adapters for development (in-memory nonce store, in-memory trust registry) and production (Redis nonce store, HttpTrustRegistry for registry.xail.io). Replace the adapters, not the SDK.

License: Proprietary. Early access SDK available to approved organizations. Contact us to request access — we're onboarding regulated-industry customers first.
Beyond Node.js: The SDK is the convenience layer — the envelope format is the real product. Standard JSON with Ed25519 signatures and AES-256-GCM payloads. A verify-and-decrypt implementation is ~300 lines in any language. Full SDK for Node.js. Open envelope spec for everything else.
terminal
# Identity + signing layer
npm install @xail/agent-sdk

# Split-channel delivery (peer dep)
npm install @xail/crypto

# Production: Redis nonce store
# (included in @xail/agent-sdk)
import { RedisNonceStore } from '@xail/agent-sdk';
envelope format v1
{
  "v": 1,
  "alg": "Ed25519",
  "sender": "did:xail:agent-invoice-processor",
  "recipient": "did:xail:service-ap",
  "timestamp": 1742300000000,
  "nonce": "a3f7b2c1d4e8f9a0...",
  "scope": "finance.invoice.approve",
  "payload": "base64(AES-256-GCM ciphertext)",
  "signature": "base64(Ed25519 — covers ciphertext)"
}
Architecture

Two delivery modes. Registry only at provisioning.

The trust registry resolves DIDs at first contact. After that, public keys are cached locally. The registry is not in the message delivery path — your agents keep working even if the registry is temporarily unreachable.

direct mode
// Direct: signed + encrypted point-to-point

Agent A
   create envelope (sign + encrypt + scope)
   deliver over HTTPS / MQTT / any transport
   Agent B
      verify signature (Ed25519)
      check timestamp (30s window)
      check nonce (replay protection)
      check scope (trust graph)
      decrypt payload (AES-256-GCM)

// Registry involvement: ZERO at runtime
// DID → public key cached after first resolution
split-channel mode
// Split-channel: no single provider sees content

Agent A
   create envelope (sign + encrypt + scope)
   XorIDA split ciphertext into n shares
   share 1  Provider A (zero knowledge)
   share 2  Provider B (zero knowledge)
   Agent B
      collect shares from providers
      reconstruct ciphertext (XorIDA)
      verify + decrypt (same as direct)

// Each provider holds random noise.
// No single breach exposes content.
Registry = phone book, not gatekeeper. The trust registry at atelier.xail.io maps DIDs to public keys — like DNS maps domains to IPs. Once resolved, the key is cached. Your agents authenticate each other directly using cached keys. The registry is consulted at provisioning and periodic refresh, never in the critical message path.
Transport-agnostic

MQTT, HTTPS, WebSocket — the envelope doesn't care

The envelope format is a JSON object with a signature. It rides on any transport that can carry bytes. Here is a concrete example over MQTT — the same envelope, the same verification, different wire.

did-document.json
{
  "id": "did:xail:sensor-north-07",
  "verificationMethod": [{
    "id": "did:xail:sensor-north-07#key-1",
    "type": "Ed25519VerificationKey2020",
    "publicKeyMultibase": "z6Mkf5rG..."
  }],
  "service": [{
    "id": "#mqtt",
    "type": "AgentTransport",
    "serviceEndpoint": {
      "transport": "mqtt",
      "broker": "mqtts://broker.example.com:8883",
      "topic": "xail/agents/sensor-north-07/inbox",
      "qos": 1
    }
  }]
}
mqtt-publish.ts
// Sender: publish signed envelope to MQTT topic
const envelope = await agent.send({
  to: 'did:xail:sensor-north-07',
  payload: { action: 'telemetry.report', zone: 'B4' },
  scope: 'telemetry.sensor-north-07.publish',
});

// The envelope is standard JSON — publish it
mqtt.publish(
  'xail/agents/sensor-north-07/inbox',
  JSON.stringify(envelope),
  { qos: 1 }
);

// Receiver: subscribe + verify with same middleware
mqtt.on('message', async (topic, msg) => {
  const envelope = JSON.parse(msg.toString());
  const result = await agent.receive(envelope);
  if (!result.ok) return; // rejected
  // result.value.payload.action === 'telemetry.report'
  // result.value.scope === 'telemetry.sensor-north-07.publish'
});
Security guarantees

Mathematical guarantees against specific threats — not features, not policies

Threat Traditional response Atelier guarantee
Compromised transport channel HOPE
"We use TLS." Endpoint operator still reads content. No defense once TLS terminates.
MATHEMATICAL
Fewer than k shares = 0 bits of instruction content. Provider holds random noise. Unconditional.
Agent instruction injection PROBABILISTIC
Content filtering, LLM firewalls, classifier detection. Bypassed by adaptive payloads.
STRUCTURAL
Instruction never exists as a complete artifact in any single channel. No content to filter. Transport-layer defense.
Signing key compromise UNBOUNDED
Full impersonation, indefinitely, until someone notices and rotates.
BOUNDED
30-second window. Scope-limited. Zero content exposure. Instant revocation.
Quantum adversary MIGRATE
Algorithm swap (10–20 year timeline). Captured ciphertext decryptable later.
IMMUNE
XorIDA makes zero computational assumptions. Captured shares are permanent noise. No migration needed.
Provider subpoena COMPLY
Encrypt and hope. Provider holds complete ciphertext — breakable with court-ordered key disclosure.
IMPOSSIBLE
Provider holds one share. Mathematical impossibility of reconstruction. Nothing to disclose.
Replay attack VARIES
Nonce + timestamp, if implemented. Often absent in API key systems.
ENFORCED
Cryptographic nonce + 30s timestamp + scope + Ed25519 signature. All verified before handler executes.
Competitive landscape

Every funded competitor stops at the transport. We own the message.

Player What they provide Content security?
Keycard
$38M — a16z
TRANSPORT
Scoped tokens, revocation, audit trail. Strong identity layer. TLS for delivery.
BETTER
Still TLS only. Endpoint operator reads message. No split-channel.
Google A2A
Linux Foundation
TRANSPORT
Agent interoperability, discovery, JWT/OIDC auth. De facto standard.
COMPATIBLE
Xail split-channel works over A2A channels. We complement, not compete.
API Keys
45.6% of teams²
NONE
Bearer token. No identity, no replay protection, no audit, no scope.
COMPLETE
@xail/agent-sdk replaces this entirely.
@xail/agent-sdk Ed25519 identity + signed envelopes + per-request scope + trust graph XorIDA split-channel — zero-knowledge below threshold. Not encryption. Mathematics.
Key Security

A leaked key here is categorically less dangerous than anywhere else

In any standard PKI system, a leaked private key is a catastrophic event — indefinite impersonation, potential access to historical messages, unbounded damage. In the Xail agent architecture, it is a bounded, auditable incident. Not by policy. By mathematics.

30s
Time-bounded by the envelope format
Every envelope carries a timestamp. The verifier rejects anything older than 30 seconds by default. A leaked signing key allows forgery only within this window — enforced cryptographically, not operationally.
≡0
Zero content exposure — signing and decryption are independent
The Ed25519 signing key and the AES-256-GCM payload decryption key are entirely separate operations. A leaked signing key cannot decrypt any message. An attacker with your signing key can forge envelopes — but cannot read a single message they did not receive as the intended recipient.
Scope-limited by the trust graph
A compromised key grants only the permissions that agent was authorized to hold — not arbitrary system access. Scope is signed into every individual envelope and checked against the trust graph on every request.
Instant revocation — no propagation delay
Setting the revocation status in the trust registry takes effect on the immediately subsequent request. No CRL. No cache to wait out. No grace period.
Enterprise key custody. For zero-trust deployments, agent signing keys can be split using XorIDA — the same algorithm deployed by Xecret for cryptographic seed phrase protection. Keys distributed across independent HSMs, reconstructed ephemerally at signing time only, never existing as a complete value in any single system.
The Structural Advantage

A leaked signing key is bounded. A leaked API key is not.

In a standard PKI or API key model, a credential leak is unbounded — full access, forever, until someone notices. Xail’s architecture makes that impossible by design.

API Key Leak — Unbounded
Full access to every action that agent is permitted to take
Valid indefinitely — no expiry, no scope, no limit
Historical requests can be replayed indefinitely
Message content exposed if key used for encryption
Xail Signing Key Leak — Bounded
30-second window. Each request contains a 128-bit nonce. No historical replay is possible.
Scope-limited. Trust graph enforces exactly what this agent is permitted to do. No escalation.
Content-independent. Signing and decryption are separate. A leaked signing key exposes zero message content.
Instant revocation. One registry call. No rotation process. No propagation delay.

Built on the same XOR-IDA cryptographic foundation as Xecret.io — production-deployed since 2021 for cryptocurrency seed phrase protection. The same algorithm that protects agent messages can also protect the agent’s own signing key via threshold-split key custody.

Independence

Your keys. Your agents. Your exit.

We built Atelier so your system never depends on ours to function. The SDK is a convenience layer. The envelope format is the real product — and it’s yours.

Your keys never leave your agents
Ed25519 private keys are generated locally and stay local. We never see them, never escrow them, never have the ability to sign on your behalf. You own your identity completely.
{ }
Open envelope format
The envelope is standard JSON. The signature is standard Ed25519. The encryption is standard AES-256-GCM. Any language with these primitives can produce and verify Atelier envelopes — no SDK required.
Works without us
The SDK ships with in-memory adapters for the trust registry and nonce store. Air-gapped deployments, embedded devices, or teams that prefer self-hosted infrastructure can run the full protocol without any call to xail.io.
No lock-in by design
If you outgrow us or we disappear, your agents keep working. The envelope format is documented. Your keys are yours. Migrate the registry to your own infrastructure — the SDK's adapter pattern makes it a config change, not a rewrite.
Run your own registry
The trust registry is not a cloud dependency — it's an adapter. Swap HttpTrustRegistry for your own Postgres, Consul, or any key-value store. Your devices pin public keys at provisioning exactly like TLS certificate pinning. If registry.xail.io disappears, your deployed devices keep working. Provisioning new devices requires only your registry, not ours.
Source code escrow
Enterprise license includes source code escrow with a third-party agent. If Xail ceases operations, customers receive the complete source for @xail/agent-sdk and @xail/crypto. For infrastructure that controls physical access, financial transactions, or healthcare systems, vendor lock-in with no escape hatch is a non-starter. We agree.
Verify-only in ~300 lines. For embedded systems, IoT devices, or non-Node.js runtimes, a verify-and-decrypt implementation requires only Ed25519 signature verification and AES-256-GCM decryption. No SDK dependency. No npm. No registry call. The device just needs the sender's public key — pinned at provisioning, exactly like you'd pin a TLS certificate. See the reference implementation below.
Quantum resistance

Already quantum-safe. No migration. No algorithm swap.

Every computational encryption scheme — AES, RSA, ECDSA, lattice-based PQC — is breakable by a sufficiently powerful computer. The question is when. XorIDA makes no computational assumption at all. The security of fewer-than-k shares is not "hard to break." It is information-theoretically impossible to extract any information — regardless of adversary resources, including quantum computers. This is Shannon’s perfect secrecy applied to agent communication.

0
Zero computational assumptions
XorIDA operates over GF(2) — pure XOR arithmetic. No prime factorization. No discrete logarithm. No lattice problem. There is no hardness assumption for a quantum computer to break.
Unlimited adversary power
Security holds against an adversary with unlimited computational resources — classical or quantum. This is the definition of information-theoretic security. It does not degrade over time, ever.
2035
CNSA 2.0 mandate deadline
The U.S. government requires quantum-resistant cryptographic systems by 2035. NIST estimates PQC migration will cost billions. XorIDA split-channel delivery is already compliant. Zero migration cost.
Harvest-now immune
Nation-state adversaries collect encrypted traffic today, banking on future quantum capability to decrypt. XorIDA shares are immune — captured shares are permanent mathematical noise. There is nothing to decrypt, now or ever.
Information-theoretic vs. computational: TLS, AES-256-GCM, and Ed25519 are computationally secure — safe until computers get powerful enough. XorIDA split-channel delivery is information-theoretically secure — safe unconditionally, by mathematics, not by assumption. For agent systems expected to operate 5, 10, or 20 years, this is the difference between "hard to hack today" and "mathematically impossible to intercept with fewer than k shares, forever."
The DIY question

Ed25519 and AES-256-GCM are implementable. The delivery guarantees are not.

A senior engineer can implement signed, encrypted, replay-protected agent envelopes in ~450 lines. We respect that. Here is what those 450 lines do not give you.

What you can build yourself
Ed25519 identity + signature verification (~200 lines)
AES-256-GCM envelope encryption (~150 lines)
Timestamp + nonce replay prevention (~100 lines)

This gets you signed, encrypted, replay-protected agent envelopes. Solid. Start here if that's all you need.

What you cannot build trivially
Information-theoretic delivery: Correct threshold sharing over GF(2), HMAC-before-reconstruct integrity, multi-channel delivery orchestration. A subtle implementation error silently degrades the security guarantee to zero.
Structural prompt injection defense: Splitting instructions so no single channel holds a complete instruction requires correct share construction, channel independence verification, and threshold enforcement. This is not a library call — it is an architecture.
Quantum-resistant delivery: Information-theoretic security is a property of the mathematical construction, not a feature you bolt on. AES-256-GCM is computationally secure. XorIDA shares are unconditionally secure. You cannot upgrade from one to the other incrementally.
Compliance-ready audit trails: HIPAA, ABA Rule 1.6, and SEC 17a-4 require specific evidence formats, retention policies, and exportable audit trails. Weeks of engineering per framework — and the requirements change.
We built the SDK so you don't have to get threshold cryptography right. The cost of getting it wrong in a system controlling physical access, healthcare data, or financial transactions is not a bug report. It is a liability event. The SDK is tested against known-answer vectors with 100% coverage, fuzz-tested, and statistically verified for share independence.
Reference implementation

Verify-only in Python — no SDK, no npm, no dependency

For embedded systems, IoT devices, or any non-Node.js runtime. This is the complete verification flow — ~80 lines of Python using only the standard library and cryptography. Your device just needs the sender's public key, pinned at provisioning.

verify_envelope.py
import json, time, base64, hashlib
from cryptography.hazmat.primitives.asymmetric.ed25519 \
  import Ed25519PublicKey
from cryptography.hazmat.primitives.ciphers.aead \
  import AESGCM

# Pinned at provisioning (like a TLS cert)
SENDER_PUBKEY = bytes.fromhex("ab12...ef")
DEVICE_PUBKEY = bytes.fromhex("cd34...gh")
NONCES_SEEN = set()

def verify_envelope(raw_json: str):
    env = json.loads(raw_json)

    # 1. Version check
    assert env["v"] == 1
    assert env["alg"] == "Ed25519"

    # 2. Timestamp (30s window)
    age = abs(time.time() * 1000 - env["timestamp"])
    if age > 30_000:
        raise ValueError("Timestamp expired")

    # 3. Nonce (replay prevention)
    nonce_key = f'{env["sender"]}:{env["nonce"]}'
    if nonce_key in NONCES_SEEN:
        raise ValueError("Replay detected")
    NONCES_SEEN.add(nonce_key)

    # 4. Verify Ed25519 signature
    payload = base64.b64decode(env["payload"])
    sig = base64.b64decode(env["signature"])
    pub = Ed25519PublicKey.from_public_bytes(SENDER_PUBKEY)
    pub.verify(sig, payload)  # raises on failure

    # 5. Derive shared key: SHA-256(sort(pubA,pubB))
    pair = sorted([SENDER_PUBKEY, DEVICE_PUBKEY])
    shared = hashlib.sha256(pair[0] + pair[1]).digest()

    # 6. Decrypt AES-256-GCM (12-byte IV prepended)
    iv, ct = payload[:12], payload[12:]
    plaintext = AESGCM(shared).decrypt(iv, ct, None)

    return json.loads(plaintext)
verify_envelope.c (pseudocode)
// C equivalent for embedded / QuickJS
// Dependencies: libsodium (Ed25519),
//   OpenSSL or mbedTLS (AES-256-GCM)

int verify_envelope(
  const char* json_str,
  const uint8_t sender_pub[32],
  const uint8_t device_pub[32]
) {
  // 1. Parse JSON (cJSON / jsmn)
  // 2. Check v == 1, alg == "Ed25519"
  // 3. Verify |now - timestamp| < 30000ms
  // 4. Check nonce not in seen-set

  // 5. Verify signature
  crypto_sign_ed25519_verify_detached(
    sig, payload, payload_len, sender_pub
  );

  // 6. Derive shared key
  //    sort(pubA, pubB) -> SHA-256
  uint8_t shared[32];
  sort_and_concat(sender_pub, device_pub, buf);
  SHA256(buf, 64, shared);

  // 7. Decrypt AES-256-GCM
  //    iv = payload[0:12]
  //    ciphertext = payload[12:]
  EVP_DecryptInit_ex(ctx, EVP_aes_256_gcm(),
    NULL, shared, iv);

  // 8. Parse decrypted JSON payload
  return 0; // success
}
No SDK lock-in. The Python implementation above is complete — it verifies signatures, checks replay, decrypts payloads, and enforces the 30-second window. The C pseudocode covers the same flow for embedded targets. Any language with Ed25519 and AES-256-GCM can verify Atelier envelopes. The SDK is a convenience, not a requirement.
Published test vectors

Verify your implementation against known-answer outputs

These are the same test vectors used in the @xail/crypto test suite — 136 tests, 100% line coverage, fuzz-tested, statistically verified for share independence. Use them to validate any independent implementation of XorIDA 2-of-3 sharing.

xorida-test-vector-1.json
{
  "description": "2-of-3 XorIDA — 'Hello!' with PKCS#7 padding",
  "config": { "n": 3, "k": 2 },
  "input": "[0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x21, 0x02, 0x02]",
  "random_r": "[0xa3, 0x7f, 0x12, 0xe8, 0x5c, 0xb1, 0x9d, 0x44]",
  "shares": {
    "0": "[0xeb, 0x1a, 0x7e, 0x84, 0x33, 0x90, 0x9f, 0x46]",
    "1": "[0xc6, 0x7f, 0x7e, 0xe8, 0x7d, 0xb1, 0x9f, 0x44]",
    "2": "[0xa3, 0x37, 0x12, 0x84, 0x5c, 0xde, 0x9d, 0x46]"
  },
  "reconstruction": {
    "[0,1]": "reconstructs to input ✓",
    "[0,2]": "reconstructs to input ✓",
    "[1,2]": "reconstructs to input ✓"
  },
  "single_share_entropy": "each share is indistinguishable from random — zero information about input"
}
xorida-test-vector-2.json
{
  "description": "2-of-3 XorIDA — edge case, zero random",
  "config": { "n": 3, "k": 2 },
  "input": "[0xff, 0x01]",
  "random_r": "[0x00, 0x00]",
  "shares": {
    "0": "[0xff, 0x01]",
    "1": "[0x01, 0x00]",
    "2": "[0x00, 0xff]"
  },
  "reconstruction": {
    "[0,1]": "reconstructs to input ✓",
    "[0,2]": "reconstructs to input ✓",
    "[1,2]": "reconstructs to input ✓"
  },
  "note": "Zero random exposes structure — production MUST use crypto.getRandomValues(). This vector verifies the algebraic identity holds even in degenerate cases."
}

// Reconstruction algorithm (any 2 of 3):
// Given shares[i] and shares[j] where i < j:
//   row_i XOR row_j → intermediate
//   Apply GF(2) inverse of (M[i] XOR M[j])
//   to recover the original padded message.
//
// The generator matrix M is derived from
// the Cauchy matrix over GF(2^8), projected
// to binary — XorIDA construction.
Full test suite: 136 tests, 100% line coverage. Includes known-answer vectors verified against reference implementations, fuzz tests with random inputs across all valid (n,k) configurations, statistical independence tests verifying each share passes chi-squared randomness tests, and reconstruction tests for every valid subset of k shares. The test suite is available with SDK access.
Regulated industries

Compliance by architecture, not by policy

For law firms, healthcare organizations, and financial services firms — where "we use TLS" is not a sufficient answer.

HIPAA Security Rule §164.312(e)
Protected Health Information
PHI split across independent channels — no single channel holds reconstructable patient data. Breach of one channel is not a HIPAA reportable event. Information-theoretic guarantee, not administrative assertion.
ABA Model Rule 1.6(c)
Attorney-Client Privilege
No single cloud provider holds reconstructable privileged content. Satisfies the competence obligation for AI agent communication with a mathematical guarantee — not a checkbox on a policy document.
SEC Rule 17a-4
Records Preservation
Every agent action signed, timestamped, and attributable via Ed25519. Tamper-evident, cryptographically non-repudiable records. Audit export is deterministic.
CMMC Level 2 — SC.L2-3.13.8
CUI in Transit
XorIDA exceeds the NIST 800-171 encryption requirement — information-theoretic security, not computational. Controlled unclassified information is mathematically unrecoverable from individual shares.
FedRAMP — NIST 800-53
Cryptographic Controls
Thin backend architecture minimizes assessment surface. Split-channel delivery means the server never holds message content. Cryptographic audit trail without content exposure to auditors.
EO 14028 — Zero Trust
No Implicit Trust
Every agent authenticates every message. No trusted intermediary. Provider compromise yields random noise. Identity is cryptographic (Ed25519 DID), not network-based.
Honest trade-offs

Is Atelier right for you?

We'd rather you know the trade-offs now than discover them in production. Atelier adds a cryptographic layer — that's power, but it's also complexity. Here's when it's worth it.

Atelier is the right fit when...
You operate multiple agents across facilities or cloud providers and need scoped, revocable identity per agent
You're in a regulated industry (legal, healthcare, finance) where "we use TLS" isn't a sufficient compliance answer
You need a provable audit trail with non-repudiation — who sent what, proven cryptographically
You're sending commands where forgery has physical consequences — OTA firmware, access control, remote operations
You need structural defense against instruction injection — not probabilistic content filtering
You need split-channel delivery where no single cloud provider can read the message content
You need quantum-resistant delivery for systems expected to operate 10+ years
You might not need it yet if...
You have one agent talking to one server on an internal network — HMAC + TLS may be sufficient for now
Your threat model doesn't include the transport provider as an adversary — standard encryption covers you
You prefer zero external dependencies — consider implementing the open envelope format directly
You're in early development with a single deployment — start with the envelope spec, add the SDK when you scale

The envelope format and verify-only implementation are available independently of the SDK. Start with the spec. Add the convenience layer when the complexity is justified.

R
Ask Ren
Sales engineer
Questions about the SDK, pricing, or integration? I can help.
Want to talk to a person? contact@xail.io
Early access

Download the SDK

@xail/agent-atelier is available for approved early access. Download the SDK, read the technical architecture, or share the executive brief with your leadership team.

Technical abstract. The Xail Agent Identity Protocol uses Ed25519 cryptographic identities registered as DIDs in a trust registry. Messages are encrypted with AES-256-GCM (per-message ephemeral key via X25519 + ML-KEM-768 hybrid key agreement), signed with Ed25519 (encrypt-then-sign order), and optionally split across independent providers using XorIDA over GF(2) for information-theoretic content security. v2 envelopes use FIPS 203 ML-KEM-768 hybrid KEM — session keys are secure as long as either X25519 or ML-KEM holds, defending against harvest-now-decrypt-later attacks. Split-channel delivery provides structural transport-layer defense against instruction injection and quantum-resistant delivery with zero computational assumptions. Replay protection via timestamp + nonce. Scope enforcement via signed trust graph. 30-second default compromise window. The envelope format is open and language-agnostic.