Security architecture
Do not take our word for an approval.
INTYGA is designed so an executing service can verify the human signature over its own intended parameters, without trusting a mutable approval flag or a vendor-held signing key.
Controls that matter at execution time
Approvers sign with a browser WebAuthn passkey or security key. INTYGA does not hold the private key that proves approval.
The canonical signed payload includes target, action type, structured parameters, requester, nonce, and expiry. Execution re-derives those bytes.
A missing, expired, altered, or already consumed approval must not authorize the irreversible operation. This holds when INTYGA itself is unreachable: the SDK surfaces an error or an expired status, never an approval, so an outage delays the action rather than releasing it.
The open-source verifier checks a receipt locally using public-key cryptography; a relying party does not need an INTYGA secret or a network call.
When INTYGA is unreachable, the relying party builds the challenge itself and approvers sign it on a disconnected device. We do not ship pre-signed break-glass approvals: a proof waiting in a file is a bearer capability that cannot be revoked and attests to a judgment about a hypothetical. The ceremony moves off the network, not earlier in time, and the validity window is capped at 60 minutes. Where approvers are also unreachable, a Delegation transfers only the authority to approve, is capped at 72 hours, and is refused outright by receipt verification.
Quorum, four-eyes, hardware-key, and requester-attestation requirements are frozen at challenge creation and cannot be lowered by a requester.
The trust graph is tenant-scoped with Postgres RLS. Meaningful actions are recorded in a Merkle-backed witness ledger with client-signature evidence.
Where the trust actually sits
A vendor-signed policy decision and a human-signed approval establish different things. If the vendor holds the signing key, verification proves that key signed the decision; it does not independently establish that a human approved the operation. Key custody is part of the trust model, even when the resulting artifact can be checked offline.
INTYGA's receipt attests something narrower and harder: this specific person, using this specific authenticator, consented to these exact parameters. The signature is produced by the approver's authenticator and its private key is never exposed to INTYGA. Synced passkeys may be backed up across the user's devices; a policy can require a hardware-bound credential instead. We do not hold a key capable of producing a valid approval. That is the difference worth checking: verify a receipt with our open-source verifier and note that it never asks us for anything.
Receipt verification is a deterministic cryptographic check over canonical bytes. With the same proof, trusted keys, expectations and validation time, a conforming implementation produces the same result. Retain those inputs for historical checks: that is different from treating an expired approval as permission to execute today.
Shared pinned vectors test the canonical payload builders and receipt verifiers in five languages — TypeScript, Go, Rust, Python and Java — in CI. They catch disagreements covered by those cases, not every possible ambiguity. Ordinary ES256 and WebAuthn approval receipts are supported in all five, along with platform receipts, Agent Authority seals, evidence bundles, checkpoint continuity and caller-policy anchor quorum. The matrix below distinguishes implemented features from remaining limits; matching test vectors do not establish complete protocol conformance.
Being precise about what that does and does not establish: it shows the implementations agree with each other and with the vectors. That is not by itself agreement with the specification — a vector can be wrong in the same way as the code it was generated from, which an audit of the five verifiers found three times — and it is not a formal proof that the protocol is free of attacks. Both are different exercises, and we would rather name the gaps than let cross-checking be mistaken for them.
To be fair about the boundary — a model-based approach answers a question we do not answer at all: is this action consistent with what the agent was supposed to be doing? That is a semantic question and it is a real one. We answer a different one: did an authorized human approve these exact parameters. If you need both, they are complementary rather than competing.
Verifier support by capability
Choose an implementation for the proof type you need, not just the language you use.
| Capability | TypeScript | Python | Go / Rust / Java |
|---|---|---|---|
| Ordinary DIV approval receipts (ES256, WebAuthn, quorum) | Supported | Supported | Supported |
| Platform receipts (DIV §5c) | Supported | Supported | Supported |
| Agent Authority proofs (DIV §5b) | Supported | Supported | Supported |
| DEWP Core primitives and single-anchor ES256 signatures | Supported | Supported | Supported |
| Single inclusion-proof bundles | Supported | Supported | Supported |
| DEWP anchor quorum, continuity chain, multi-entry evidence bundles | Supported | Supported | Supported |
| RFC 3161 timestamp verification | Optional OpenSSL 3 adapter | Optional OpenSSL 3 adapter | Optional OpenSSL 3 adapter |
| NDJSON evidence streaming | Not implemented | Not implemented | Not implemented |
Proof inclusion and signature verification are separate checks. DEWP Core does not verify a WebAuthn event signature from its leaf alone. That is distinct from verifying a complete DIV WebAuthn approval receipt. Anchor quorum supports ES256, Ed25519, RSA-PSS and pinned-key Rekor evidence, plus RFC 3161 timestamps through optional OpenSSL 3 adapters in all five languages. Timestamp verification requires caller-configured TSA certificates, signer pins and an explicit revocation policy. It establishes that the checkpoint commitment existed by the TSA time; it does not establish when the underlying action happened. WEBHOOK anchors do not count toward quorum. Offline Agent Authority verification checks the seal, not later online revocation. No implementation claims the complete DEWP Extended Profile. See the implementation limits.
How we run this ourselves
A control the vendor exempts itself from is a product, not a practice. INTYGA's own production deploys and database migrations run through the same gate we sell.
The release workflow takes a full commit SHA and refuses any commit that is not an ancestor of main — so nothing reaches production that the CI gate never saw, and “deploy whatever the branch dropdown was pointing at” is not a reachable state.
A human approval bound to that exact SHA has to complete before the job can obtain deployment authority. The credential the pipeline holds is a requester credential: it can ask, and that is all it can do.
Gating our gateway on our gateway means an outage could block shipping its own fix. The recovery path is the Offline Approval procedure our customers get — approvers sign on a disconnected device and the workflow verifies the result — not a flag that turns the gate off. A bypass switch in the control we sell is worth less than the control.
The honest limit: this proves a person approved the exact commit, not that the commit was a good idea. And the offline path trades a little strength for availability — its single-use guarantee rests on the operator's redemption record and a window capped at 60 minutes, inside which a replay could only redeploy the identical commit.
Sovereignty and data residency
INTYGA is a Swedish company and the hosted service runs in the EU. For deployments where that is not enough, three properties matter more than the hosting region:
On Enterprise, the gateway runs in your own VPC. Approvals never traverse infrastructure we operate.
Your approval policy is encrypted with your organization's public key. The gateway relays it and enforces version freshness without ever decrypting it; decryption happens in your administrator's browser with a private key we never receive. Quorum is the deliberate exception — it lives in plaintext rules precisely so a compromised requester cannot lower a threshold we are unable to read.
Verification requires no network. Offline Approval lets you approve new actions with us fully unreachable. A deployment that cannot call out is a supported posture, not a degraded one.
What INTYGA does not claim
A compromise of the relying party’s own execution process is out of scope: that process is where the action runs. INTYGA also does not replace IAM, change control, or platform-native gates. It adds a human-signed, exact-action proof immediately before execution.
Give security a clean adoption path.
Developers can prove the integration on one action. Security can then review the verifier, add quorum and hardware requirements, and export evidence without replacing the integration.
Review plan capabilities →