machine-readable · llms.txt · agent.json

Agents, welcome.

e-sig is an MIT-licensed SDK for PDF e-signatures that runs entirely inside the integrator's infrastructure. This page is the machine-oriented brief: exact capabilities, exact API names, exact commands — nothing to scrape around. AI agents are explicitly allowed in robots.txt.

Machine-readable entry points

/llms.txt

The brief: what e-sig is and where everything lives, in the llms.txt markdown format.

/llms-full.txt

Every public page of this site as plain text, regenerated from the live HTML.

/agent.json

JSON manifest: packages, roles, quickstart commands, endpoints, and contacts.

/sitemap.xml

All public pages. docs.e-sig.org hosts guides and API reference.

/verify

Client-side verifier: a signed PDF can be checked in the browser with no upload and no account.

npm registry ↗

Packages are published to the public npm registry under the @e-sig scope.

Capabilities, with exact API names

renderHtmlToPdf — HTML → PDF rendering via puppeteer-core
signPdf — PKCS#7 detached signature, ETSI.CAdES.detached subfilter, ESS signing-certificate-v2
verifyPdfSignature — recomputes the document digest and checks the signature; one altered byte fails
RFC-3161 timestamping — upgrades a signature to CAdES-T; only a SHA-256 hash ever leaves the process
@e-sig/core/pq-seal — hybrid Ed25519 + ML-DSA-65 (FIPS 204) post-quantum seal attached beneath the classical signature
createEnvelope — N ordered signers over one document, single-use tokenized signing links
signDocument — one-call orchestrator: render → cert → sign → store → audit
Pluggable CertStore / AuditLogStore / PdfStorageStore / EnvelopeStore — Supabase and filesystem adapters included
esig verify — CLI verification of a signed PDF (npx -y -p @e-sig/core esig verify <file.pdf> --json)
GitHub Action — verify signed PDFs in CI (action.yml; docs/verify-in-ci.md)
@e-sig/pillar-bridge — agent-to-agent signing delivery + identity proofs over UUAID's Pillar substrate (published, 0.1.0)

The exact quickstart

Node.js ≥ 20. No signup, no API keys, no external services — it issues a cert, signs, verifies, then rejects a tampered copy. Need a document to start from? examples/templates ↗ has six ready-to-sign HTML documents.

# from a clone of https://github.com/vmvtech/esig-suite
$ npm install
$ npm run build
$ npm run quickstart   # issue cert → render → sign (+timestamp) → verify → reject tamper

// the API underneath
import { signDocument, verifyPdfSignature } from "@e-sig/core";

const result = await signDocument({
  html, tenantId, subjectName,
  passphrase: process.env.ESIG_CERT_PASSPHRASE,
  signer: { name, email },
  certStore, auditStore, storage,   // your adapters
  pathPrefix: `${tenantId}/${documentId}`,
});
// → { signedPdfUrl, auditLogId, certFingerprint, timestamped }

const ok = verifyPdfSignature(signedPdf).ok;  // cryptographic check

@e-sig/mcp — agent-driven signing

An MCP server that lets an agent drive the whole envelope lifecycle — create a PDF envelope, track its signers, poll status, and confirm the sealed result — while cryptographic control of signing stays with a human by default. Two commands to try it: npx @e-sig/mcp demo --auto for a scripted end-to-end run, or npx @e-sig/mcp init to wire it into Claude Desktop or a project's .mcp.json. Published to npm at 0.5.0 — npm ↗. Source: packages/esig-mcp ↗. Full reference: docs.e-sig.org.

Tool surface (11 tools)

Tool	Purpose
esig_create_envelope	Create an envelope from HTML or a PDF docId + signers; dispatches links through the configured delivery channel.
esig_envelope_status	One envelope's status, phase, per-signer state, seal state, sealed PDF path.
esig_identity_challenge	Issue the sole-control challenge a signer's key must sign.
esig_ingest_document	Store PDF bytes; returns a docId for a Chrome-free PDF envelope, or for verification.
esig_list_envelopes	List envelopes for this server's tenant, optionally by status.
esig_list_events	An envelope's lifecycle events, oldest first.
esig_reseal	Retry the sealed-PDF step after a seal failure.
esig_send_reminder	Resend a signing reminder, on demand.
esig_verify_document	Verify a PDF's classical signature and, if present, its post-quantum seal.
esig_void_envelope	Cancel a pending or partially-signed envelope.
esig_whoami	Tenant, enabled modes, caps, seal readiness, cert/PQ fingerprints — never key material.

No tool signs. Modes A/C (agent-signs-as-itself; dual-key co-sign) are v0.2, gated behind a RedTeam review — ESIG_MCP_MODES refuses to even start a server configured for them. Full tool contracts: docs.e-sig.org/#mcp.

Delivery and lifecycle events

Delivery channels: a file outbox, console, webhook, email (SMTP or SES, with reminders), and pillar — reaching a signer that is itself an agent, over UUAID's Pillar substrate via the published bridge @e-sig/pillar-bridge ↗ (0.1.0). Every state change appends one of 12 lifecycle event types (envelope.created … signer.identity_rejected) to a signed, at-least-once webhook queue with exponential backoff. Full event catalog: docs.e-sig.org/#mcp-events.

Signer identity

Level	What's proven
none	Nothing (default).
L0	Self-asserted uuaid — no cryptographic proof.
L1	Sole control of a key (Ed25519 DataIntegrityProof) — identity itself still self-asserted.
L1p	Key↔uuaid binding by construction — a Pillar agent identity, no registry needed.
L2	Key↔uuaid binding verified against the UUAID registry's signed badge.

Full ladder, refusal codes, and pre-verified identity via Pillar: docs.e-sig.org/#mcp-identity. Agent-to-agent delivery detail: docs.e-sig.org/#mcp-pillar.

When the signer is an agent

If your AI agent signs documents on someone's behalf, attribution is the whole problem. The opt-in @e-sig/uuaid ↗ adapter stamps the acting agent's UUAID into the signature's audit log and anchors the audit hash-chain, so the record says which agent acted — not just which account. Hosted support for agent-signed workflows (UUAID Enterprise) is on the Cloud waitlist.

Trust semantics, stated plainly: the verifier proves the embedded PKCS#7/PAdES signature matches the document bytes (and, where present, the hybrid PQ seal verifies). Self-issued certificates are cryptographically valid but not trusted by default in stock PDF readers. No PDF reader natively validates ML-DSA-65 in PAdES yet — that is why the post-quantum seal rides beneath the classical signature. e-sig provides technical controls supporting ESIGN/UETA; compliance posture remains the integrator's responsibility.