Have a Coding Agent Implement INK

If you’d like a coding agent (Claude, Codex, Cursor, or similar) to do the bulk of an INK implementation for you, this page collects everything the agent needs in one place. It is framed as agent-assisted implementation, not as outsourcing trust to the agent. The generated code is a starting point that must pass the conformance test vectors and survive a security review before any production traffic touches it.

If you are implementing INK by hand instead, the Accepting Foreign Senders guide and the rest of this site are written for human readers; come back here only if you decide to hand the work to an agent.

What you give the agent

A coding agent does its best work when it has the full normative material in front of it, not just a project README. The pinned packet below is everything that the implementer needs:

Spec bundle

• The full INK spec corpus. llms-full.txt is the machine-readable concatenation of every spec, extension, and reference page on this site, in a stable order. Hand the whole file to the agent — it fits in modern context windows and is the only spec source the agent should treat as normative.
• Test vectors. Reference test vectors for signing, encryption, replay protection, audit, transport auth, containment, key rotation, discovery gating, and witness verification. The agent’s implementation MUST reproduce every vector that covers a feature it claims to implement, byte-for-byte. Vectors for optional extensions only need to pass when the corresponding extension is in scope, but that scope must be declared up front in the traceability matrix below.
• Compliance checklist. INK 0.1 compliance checklist — every MUST and SHOULD item, grouped by domain. The agent should treat this as its acceptance criteria.

Security obligations

• Receiver threat model. Accepting Foreign Senders summarizes the protocol and deployment-level requirements for accepting INK from agents whose DID lives on a different platform. Even if your service is single-tenant, the cryptographic and replay-protection sections are non-negotiable.
• Wire-level checks. The agent must implement signature verification, freshness, single-use nonce, recipient binding, JCS canonicalization, and protocol-field shape enforcement (every field that the spec marks MUST appears, has the correct type, and is rejected if missing or malformed). These are MUSTs in Authentication, Replay Protection, and Canonicalization.
• Structured error responses. Use the error codes verbatim on every reject path. A receiver that returns generic 400s loses the audit signal that tells operators what happened.
• Encryption ordering. When the implementation accepts or sends encrypted payloads, do signature verification first, decrypt second, then inner/outer identity binding (Encryption). Sending an encrypted-but-signed-by-the-wrong-key envelope is silently broken if the order is reversed.
• Inner / outer identity check. When a payload carries an inner identity claim (encryption recipient, delegated sender), the agent must confirm that claim against the outer envelope before delivering. Mismatches are protocol violations.
• Key rotation rules. Key Rotation — revoked keys never verify, retired keys verify only within their validFrom/validUntil window.

Reference implementations to read

• @adastracomputing/ink — canonical TypeScript library with the signing/verification primitives. The agent SHOULD prefer using this library over re-implementing the wire format unless the goal is explicitly a from-scratch interop client.
• examples/foreign-sender-receiver/ — self-contained TypeScript reference for the receive-side patterns including SSRF defenses and the inbound-foreign decision function.
• examples/interop-cli/ — Python sender that does not depend on @adastracomputing/ink. Useful for the agent to read as a second independent implementation of the wire format.

The implementer prompt

Hand the following prompt to your coding agent verbatim, along with the spec bundle above. The prompt is designed to keep the agent honest: cite the spec, refuse assumptions, write tests first, and flag every place where the input is ambiguous.

Role. You are implementing the INK protocol for the codebase I will share. INK is an Ed25519-signed agent-to-agent protocol; the full normative material is in llms-full.txt and the test vectors. Treat that material as authoritative. If something is not in those documents, do NOT invent it — surface the gap and ask me.

Scope and acceptance criteria. Decide up front whether this is a full INK v0.1 implementation, a receive-only conformant subset, or a send-only client. A receive-only implementation cannot claim INK v0.1 compliance — it can only claim the subset it explicitly declares. Document the scope in the traceability matrix described below. Within scope, your implementation MUST pass every applicable item in the INK 0.1 compliance checklist and reproduce every applicable test vector byte-for-byte. You MUST NOT mark an item complete until the corresponding test passes.

Scope loopholes to refuse. If you mark encrypted-payload receive as out-of-scope, your endpoint MUST reject intent types the spec requires to be encrypted (schedule_meeting, context_share, multi_party_sync). Accepting them in plaintext is a spec violation, not a scope reduction. The same rule applies anywhere a feature is “skipped” while its required failure modes remain mandatory.

Traceability matrix (mandatory). Before writing any code, produce a table mapping every MUST item in the compliance checklist to one of implemented / out-of-scope / blocked, with a spec citation and the file path of the test that will cover it. Re-emit the table after each iteration with the columns updated. Do NOT silently narrow scope by leaving items off the table.

Workflow.

1. Read llms-full.txt, the compliance checklist, and the test vectors. Produce the traceability matrix.
2. For each implemented-bucket MUST item, write the failing test first, then implement, then confirm green.
3. For SSRF-adjacent surfaces (did:web: resolution, outbound INK delivery) treat the foreign-sender-receiver example as the structural reference for which defenses are required.
4. Cite the spec section in commit messages, in the PR summary, in test names or descriptions, AND in code comments on every security-sensitive check. The citation is what lets a future reviewer audit your reasoning — many agent workflows do not produce meaningful commit history, so multiple citation surfaces are required, not just commits.
5. After every implementation step, re-emit the traceability matrix, run the full test suite, and walk the conformance + human review checklists below.

Rules of engagement.

• Never accept any resolver outbound HTTP to a private IP, link-local address, IPv6 mapped address, or cloud metadata endpoint. This applies to did:web: document fetches AND to every other resolver fetch you add (Agent Card discovery, third-party DID directories, embedded service endpoints). Use the isIpLiteralHost and isPrivateHost patterns from the reference example for every outbound resolver path, not only the did:web: one.
• Never compare DID strings with startsWith against a method prefix without the trailing colon. Require the canonical did:<method>: shape.
• Never log envelope payloads, nonces, or secret material into observability pipelines.
• Never trust risk-scoring verdicts as authorization. Cryptographic checks are authoritative; scoring is advisory.
• Never reverse the encryption ordering. Verify signature first, decrypt second, check inner/outer identity third.
• Use the structured error codes on every reject. Do not invent reason strings.
• When a test fails, report it; do not silently relax the test.
• When a spec section is materially ambiguous (multiple interpretations have different security or wire-format consequences), flag it in the traceability matrix as blocked and stop. Harmless local decisions (variable naming, file layout, internal helper choice) can be documented in the matrix as implemented with a one-line note — do not block on those.

Starter traceability matrix

A concrete starter for the most common subset (Node receive-only endpoint, plaintext low-sensitivity intents). The agent’s first response should be a matrix in this shape, not a wall of code.

The statuses below are illustrative example values for a typical implementation; the agent MUST re-evaluate every status against the actual codebase and replace them all before writing any code. Do not copy implemented from this starter onto a row whose code has not been written.

ID	MUST item	Scope status	Spec citation	Planned test
AUTH-01	Reject missing/invalid Authorization: INK-Ed25519 ...	implemented	Authentication; Errors	test/ink/auth-header.test.ts
AUTH-02	Verify Ed25519 signature on every inbound message	implemented	Authentication	test/ink/signature.test.ts
AUTH-03	Signature base binds protocol, method, path, recipient DID, JCS body, timestamp	implemented	Authentication; Canonicalization	test/ink/signature-base.test.ts
AUTH-04	Resolve sender key from body.from; missing/malformed sender fails closed	implemented	Authentication; Errors	test/ink/sender.test.ts
AUTH-05	Apply key-rotation rule: active/retired valid, revoked never valid	blocked	Key Rotation	test/ink/key-rotation.test.ts
REPLAY-01	Require nonce length/charset bounds	implemented	Replay Protection; Errors	test/ink/replay.test.ts
REPLAY-02	Require parseable UTC timestamp	implemented	Replay Protection; Errors	test/ink/timestamp.test.ts
REPLAY-03	Reject timestamps older than 5 minutes past	implemented	Replay Protection	test/ink/timestamp.test.ts
REPLAY-04	Reject timestamps more than 30 seconds future	implemented	Replay Protection	test/ink/timestamp.test.ts
REPLAY-05	Reject duplicate (sender, nonce) within replay window	implemented	Replay Protection	test/ink/replay.test.ts
CANON-01	Use RFC 8785 JCS, not JSON.stringify, for signature verification	implemented	Canonicalization	test/ink/jcs-vectors.test.ts
CANON-02	Exclude any signature field from canonical body	blocked	Canonicalization	test/ink/jcs-vectors.test.ts
ERR-01	Return structured error response on every reject path	implemented	Error Codes	test/ink/errors.test.ts
INTENT-01	Accept valid POST /ink/v1/intent envelope	implemented	Intents	test/ink/intent.test.ts
ENC-01	Reject plaintext schedule_meeting / context_share / multi_party_sync	implemented	Encryption	test/ink/plaintext-sensitive-intents.test.ts
ENC-02	Decrypt InkEncryptedPayload receive path	out-of-scope	Encryption	n/a

implemented rows must have a passing test. blocked rows must list the unresolved ambiguity in a follow-up comment. out-of-scope rows must NOT silently widen acceptance — note ENC-01 is implemented precisely because the spec mandates rejecting plaintext for those intents even when the implementation has no decryption code path.

This matrix is a starter for the most common subset. A full v0.1 implementation will have many more rows. A different subset (send-only, audit-only) replaces these rows entirely. Use the compliance checklist as the source of truth for which rows your scope needs.

Conformance checklist for the agent’s output

Run these against the agent’s implementation before merging. The agent should also run them itself between iterations.

• A current traceability matrix exists, with every compliance MUST mapped to implemented / out-of-scope / blocked, each with a spec citation and a test file path. No item is missing from the table.
• Every implemented-bucket MUST item in /reference/compliance/ has a passing test.
• out-of-scope items are reflected in the README / declared subset, so the implementation does not silently claim full v0.1 compliance.
• Every /test-vectors/ vector covering a feature declared implemented in the traceability matrix reproduces byte-for-byte. Vectors for features declared out-of-scope need not run.
• Structured error codes. Every reject path returns one of the codes from /reference/errors/. No invented or generic strings.
• Protocol-field shape enforcement. Every field the spec marks MUST is present, the correct type, and rejected when missing or malformed.
• Encryption ordering. For encrypted intents, the implementation verifies the outer signature first, decrypts second, then checks inner identity claims against the outer envelope. Tests cover the wrong-order failure case.
• Inner / outer identity binding. Encrypted payloads with mismatched inner-vs-outer sender identity are rejected. Test covers a forged inner-identity payload.
• Signature verification rejects: tampered body, wrong to field, expired timestamp, future timestamp, replayed nonce, retired-key signature outside the validity window, revoked-key signature in any context.
• did:web: resolver rejects: malformed DIDs, hosts that resolve to RFC1918 / loopback / link-local / IPv6 mapped / cloud metadata, redirects across hosts.
• Allow-list / block-list matching: rejects prefix confusion (partner.example vs evilpartner.example), trailing dots, mixed case, method prefixes without trailing colon.
• Failure modes: every required check fails closed; risk scoring is treated as advisory unless explicitly enforced.
• Observability: no secrets, full payloads, or nonces in logs.

Human review checklist

Before any production traffic, a human MUST sign off on:

• The agent followed the workflow above (tests first; spec citations in commits, PR summary, test names/descriptions, and code comments on every security-sensitive check).
• No “unimplemented” / “TODO” markers remain in security-relevant code paths.
• Integration tests exercise real DID document fetches (not mocked) against at least one fixture server.
• The agent flagged every place where the spec was ambiguous; each flag has a documented resolution.
• At least one round of static analysis or dependency audit has been run.
• If the implementation receives traffic from foreign DIDs, a security review specifically of the SSRF and identity-binding surfaces has been performed.

What this section does not do

It does not certify the agent’s output. It does not promise that following the prompt produces a compliant or secure implementation. It collects the right materials so that an agent can do the work, and the conformance checklist plus human review are how you confirm the agent actually did.

If your implementation passes the conformance checklist and the human review, please consider opening a discussion describing what worked and what didn’t. The packet on this page is more useful with feedback from real agent-assisted runs.