Skip to content
INTYGAStart free

Roadmap

What is built, what is next, and what we refuse to build.

A roadmap is easy to write and easy to quietly abandon. This one includes the things we have decided against, because those are the commitments that actually shape the product.

These are intentions, not commitments. Nothing here is a delivery date, and a small company that promises a quarter is usually promising something else. What follows is the order we currently believe is right, and we will say so on this page when it changes.

Shipped

  • Parameter-bound human approval over WebAuthn passkeys and security keys, with no app to install.
  • Offline approval, platform and Agent Authority verification in TypeScript, Python, Go, Rust and Java, plus proof and evidence bundles, checkpoint continuity and caller-policy anchor quorum. RFC 3161 timestamp verification is available through optional OpenSSL 3 adapters with caller-configured TSA trust and revocation policy. NDJSON streaming remains unimplemented.
  • M-of-N quorums, approver groups, escalation routes, four-eyes, and hardware-key policy.
  • Tamper-evident witness log with gapless ordering of committed per-tenant events and Merkle inclusion proofs.
  • External anchoring to independent transparency logs with a multi-issuer quorum.
  • Zero-knowledge policy relay, SSO and SCIM, and an MCP adapter for AI agent tool calls.
  • Public client and verifier packages for TypeScript, Python, Go, Rust, and Java.

Next

Roughly in the order we expect to work on them.

  • ISO 27001 certification. The active compliance track, and the thing most likely to unblock European enterprise deals.
  • Publishing the normative DIV and DEWP protocol text after the public-source and protocol-review gates are complete.
  • Real uptime monitoring behind the status page, replacing the manually maintained incident log.
  • A browser-based receipt verifier, so the offline guarantee can be demonstrated without installing anything.
  • Broader integration coverage for the platforms teams actually gate: more CI systems, more infrastructure tooling.
  • Filing the payload specification as an Internet-Draft, so the format has standing independent of us.

Deliberately not building

The refusals matter more than the plans. Each of these would make the product larger and the guarantee weaker.

  • Trust scores and behavioural anomaly detection. These can identify suspicious activity, but a score does not establish that a human approved exact parameters. INTYGA records and verifies that narrower decision.
  • A general semantic safety engine. Connection-level policies and scheduled pre-approval rules exist, but their unsigned outcomes do not establish human approval. The per-action proof applies where a human signature is required and verified.
  • A distributed ledger. Tamper-evidence needs a hash chain and a published root, not consensus. Merkle trees have done this since 1979.
  • A proprietary mobile app, MDM enrolment, or an app-store dependency. An approval mechanism nobody installs is an approval mechanism everybody uses. Approvers are reached by browser web push, email, or a chat webhook, and the notification carries only an opaque nonce and a message kind.
  • npm runtime dependencies in the TypeScript verifier. @intyga/verify uses Node's built-in cryptography. Optional RFC 3161 verification in all five ports uses an installed OpenSSL 3 executable. Python, Rust and Java declare their own cryptography or serialization dependencies. Each implementation's source and dependencies can be inspected.
  • A workload or agent identity product. Others do that well; we consume their attestations and bind them into the signed payload rather than rebuilding the layer.