Skip to content
INTYGAStart free

Changelog

What shipped, and when.

Entries are written when something reaches users, not when it merges. Known limits go in the release that introduced them rather than in a support thread six weeks later.

v1.0 First public release

INTYGA is available. Pipelines, scripts, and AI agents can hold an irreversible action until a named human signs its exact parameters with a passkey or security key, and the executing code can verify that receipt itself.

Approvals

  • requireApproval blocks until a human signs or the deadline passes, with a matching server-side TTL so a challenge cannot outlive the wait.
  • Signatures are WebAuthn assertions made inside the approver's own authenticator. INTYGA holds no key capable of producing a valid approval.
  • M-of-N quorums, approver groups, and escalation routes are defined in gateway-owned rules — a requester cannot lower its own threshold.
  • Approval rules can require a hardware-backed authenticator on every plan — enforcing the product's headline promise is not something to paywall — and restrict to specific authenticator models on Business.

Verification

  • verifyApprovalReceipt re-derives the canonical payload from the parameters you are about to execute, so an approval for one action cannot authorize another.
  • Verifiers for TypeScript, Python, Go, Rust, and Java. The TypeScript verifier is dependency-free and Apache-2.0.
  • Verification is offline and free forever on every plan, including the free one.

Evidence

  • Every approval is committed to a tamper-evident log with a gapless per-tenant sequence, so a deleted record leaves a detectable hole.
  • Daily checkpoint roots are anchored to independent transparency logs, with a quorum of at least two distinct issuers in production.
  • Retention runs 14 days on Developer through 7 years plus legal hold on Enterprise. Redacted records keep their cryptographic commitment, so historical proofs still verify.

Integration

  • REST authorize endpoint, TypeScript, Python, Go, Rust and Java SDKs, and an MCP adapter for AI agent tool calls.
  • SSO and SCIM on Business and above.
  • Self-hosted VPC deployment on Enterprise.

Embedded platforms (DIV §5c)

  • A service with its own end users can embed the primitive white-label: opaque subjects, passkey ceremonies on the platform's own domain, and receipts over a payload digest — the payload itself never reaches INTYGA.
  • Platform API keys authenticate with a signed assertion (private_key_jwt) only; their static secret is refused.
  • A Relying Party can be registered in test mode: fully real and fully witnessed, never billed — build on localhost before a production domain exists.
  • Offline verification of platform receipts ships in the TypeScript verifier; the Go, Rust, Python and Java verifiers refuse the payload type until they implement DIV §5c.