INK: Inter-agent Networking Kernel

Note

INK’s current defined wire version is ink/0.2, a backward-compatible minor over ink/0.1. New receivers should accept both within major 0. See Versioning & Compatibility.

Implementing INK?

If you are putting INK into production or building an independent implementation, write to [email protected]. Implementer questions get direct maintainer help, and what you run into feeds the conformance corpus before 1.0 freezes it.

Choose your starting point

I'm implementing INK Start with the wire format, signing base and authentication. Then walk through the handshake and run the test vectors against your build.

I'm integrating with an INK agent Read Discovery & Transport plus the Agent Card schema. That's everything a client needs to send its first signed intent.

I'm auditing INK security Threat model below, then the Authentication, Encryption and Replay-Protection specs. The implementation lives in the GitHub repo.

I'm comparing INK to other protocols Design Principles compares INK to AT Protocol, UCAN, ACP and message-bus alternatives. INK uses self-certifying key-derived principals and is transport-agnostic.

I want to test my sender against a live receiver Send a signed envelope to the public test endpoint at ink-echo.tulpa.network and read back a JSON acknowledgement. A 200 means your bytes are on the canonical wire.

Library

github.com/Ad-Astra-Computing/ink

The dual-licensed (MIT OR Apache-2.0) TypeScript library, an independent Go implementation that also signs, the conformance corpus, a containerized interop lab, the threat model and the full spec. Open source under Ad Astra Computing. TypeScript is the reference, and its signing and verification primitives are the same ones used in production.

View the repository → · npm package · Contributing

Send messages across services

INK is cross-platform by design. Any compatible service that serves an Agent Card at the versioned discovery path and exposes an inbound /ink/v1/... endpoint can accept signed INK envelopes from agents running on other platforms.

No DID method is required to take part. The identifier on the card can be a key-derived principal that carries its own signing key, a did:web identity rooted in a DID document, or any other stable identifier under which an Ed25519 signing key is published. What a receiver needs is a key it can resolve and a signature it can check.

tulpa.network is one current example of an accepting endpoint. Its receive side resolves inbound senders against published Agent Cards and applies operator-level and per-user acceptance policies. The same protocol surface can be implemented by other operators.

Core primitives

Self-Certifying Identity

An agent is named by a key-derived principal that embeds its own genesis Ed25519 key, or by a did:web identity rooted in a DID document. Live signing and encryption keys are published on the agent’s Agent Card and rotate under a signed rotation chain.

Signed Messages

Every INK message is Ed25519-signed over protocol version, method, path, recipient DID, JCS-canonical body and timestamp. No shared secrets.

ECIES Encryption

Ephemeral X25519 key agreement, HKDF-SHA256 derivation, AES-256-GCM. A fresh ephemeral key per message against the recipient’s static key. Outer envelope stays plaintext for routing.

Hash-Chained Audit

Per-agent append-only logs with monotonic sequence numbers, SHA-256 chain linkage and Ed25519 signatures. Fork and gap detection built in.

Message Receipts

Signed disposition acknowledgments (received, delivered, acted, rejected, expired). Receipts are full INK messages with replay protection.

Authorization Chains

A bounded linear chain of signed grants, each narrowing the one above it. Scope subset, nested windows and per-position lifetime ceilings, UCAN-inspired.

Protocol overview

INK is an application-layer protocol that lets AI agents representing humans discover each other, negotiate professional intents and establish verifiable trust without a central broker. Identity is self-certifying by default: an agentId embeds the agent’s genesis Ed25519 key, so a receiver can root a signature without consulting any directory. A did:web identity is the supported alternative, and an AT Protocol binding is an optional layer that ties an agent to a human owner. INK is transport-agnostic for everything else, and any system that can publish an Ed25519 signing key under a stable identifier can participate.

Invariants

All INK implementations MUST satisfy:

• Signatures are mandatory. Every message carries an Ed25519 signature over a deterministic base string. Unsigned messages MUST be rejected.
• Replay protection is mandatory. Every message carries a nonce and timestamp. Duplicate nonces within the 5-minute window MUST be rejected.
• Identity carries its own signing authority. An INK principal is either key-derived, a tulpa: or ink: agentId whose multibase tail is the agent’s genesis Ed25519 key, or a did:web identity whose DID document roots the key. A key-derived principal is self-certifying: it identifies exactly the holder of the embedded private key, with no directory or issuer behind it. Binding an agent to a human owner, for example through an AT Protocol agentLink record, is an optional layer on top and is never what makes a signature valid.
• Audit is append-only. Each agent’s audit log is hash-chained with monotonic sequence numbers. Forks (same sequence, different hash) are detectable.
• Encryption uses ephemeral keys. ECIES payloads use per-message ephemeral X25519 keys. The agent’s long-term encryption key is the static recipient key only.
• Human authority is preserved. Agents operate within configurable autonomy policies. The escalated_to_human resolution outcome exists for this reason.

Threat model

INK assumes a network adversary that can intercept, replay or forge messages on the wire and may operate at scale (botnets, coordinated spam). For a key-derived principal it assumes nothing beyond the secrecy of the private key, because the identifier is the key. For a did:web principal it assumes the DID document resolves honestly. Compromise of an agent’s long-term private key is out of scope: a key-derived identity has no recovery path, and a did:web identity recovers through its DID document.

Threat	Mitigation
Message forgery	Ed25519 signatures over a version-keyed domain-separated base, verified against the principal’s rooted key set
Replay attack	Nonce + timestamp window (5 min past, 30s future)
Recipient confusion	Recipient principal bound into the signature base and into the AEAD additional data
Eavesdropping	ECIES payload encryption with per-message ephemeral sender keys (ephemeral-static, so no forward secrecy against recipient-key compromise)
Audit tampering	Hash-chained logs with sequence numbers; bilateral exchange detects divergence
Split-view audit	Third-party Merkle witness services
Privilege escalation	Authorization chains enforce permission attenuation per hop
Stale delegation	Bounded link lifetimes with nested windows, checked per presentation

State transitions

Diagrams use a consistent color language. Blue = identity and keys · Purple = INK coordination · Green = audit / receipts · Gray = local storage / app state.

At a glance

Protocol versionink/0.1 + 0.2

StatusDraft

SigningEd25519

EncryptionX25519 + AES-256-GCM

CanonicalizationJCS (RFC 8785)

Identitydid:web, did:plc, did:key

Replay window5 min past, 30 s future

Delegationbounded linear chain