Questions we get asked, answered properly.

It holds an irreversible action until a named human approves that exact operation with a passkey or security key, and gives the code about to execute the action a receipt it can verify itself — offline, against the signer's public key, with no call back to us.

The signature covers the exact parameters. If the executed action differs from the approved one by a single byte, verification fails.

Yes — the Runtime Assessment reviews requests you explicitly route through INTYGA in Discovery Mode for 14 days. It records eligible requests without waiting for human approval; authentication, input validation, rate limits and other security checks still apply. Unconnected activity is not observed, and a recorded request does not prove an operation executed.

At the end you get a Security Risk Report covering recorded activity in the window: which identities approved their own requests, which requests had no human approval in the INTYGA path, and where one person holds both the requesting and approving role.

Nothing expires into enforcement. No scheduled job flips your workspace over on day 15 — we send one message saying the report is ready, and an administrator decides what to gate, if anything. A tool that started blocking production on a timer nobody set would be a worse version of the problem it exists to solve.

Discovery Mode records observations, not human approvals. Ordinary offline verification rejects these unsigned observations by default. Keep observation calls separate from production authorization decisions and retain existing controls. Signing up alone does not connect systems or start an assessment.

No. AI agents reaching a destructive tool call are one consumer. The same primitive covers CI/CD gates such as Terraform applies and database migrations, administrative scripts, backend services, and human-held API keys.

Agents get more attention because the failure modes are newer, but a cron job with a valid credential can drop a production table just as effectively.

MFA and step-up authentication establish who is present and grant a session. They do not produce a signature bound to the parameters of a specific transaction, and the record they leave is a log entry attested by the identity provider.

INTYGA signs the operation itself. The receipt binds the action type, the structured parameters, the requester, a nonce, and an expiry, and any relying party can verify it without an account.

Those authenticate a person, not a transaction, and they need a proprietary app and often MDM enrolment. A push prompt that says "Approve?" can be approved reflexively because there is nothing specific in it to disagree with.

INTYGA uses browser-native WebAuthn — Touch ID, Windows Hello, a YubiKey — with nothing to install, and puts the exact parameters in front of the approver as the thing being signed.

Those grant a human standing access for a window; the unit of governance is a session or a role. INTYGA signs a single action with its exact parameters, and the receipt is single-use.

They answer who may act. We answer what exactly was authorized, and whether you can prove it in six years without us. Plenty of teams should run both.

Each of those is good and scoped to one platform: GitHub gates a workflow, Vault gates a secret, AWS gates an AWS call. If you are single-platform, use the native control — we would rather say so than sell you something you do not need.

Independently verifiable evidence is not unique to INTYGA: CloudTrail, for example, supports offline log-integrity validation with exported files and public keys. INTYGA's distinction is a human-held signature over exact action parameters, verified by the executing service, with a separate witness trail. Use that distinction to decide whether it adds value alongside your native controls.

Yes — that is the platform integration plane. You provision your users as opaque subjects, every passkey ceremony runs on your own domain under your own brand, and your customers never hold an INTYGA account or see an INTYGA page. INTYGA receives a digest of each payload, never the payload itself, so your customers' financial or personal data stays with you.

Each completed signature produces a receipt your service verifies itself — offline, against the digest you recompute and the keys you enrolled — plus a tamper-evident ledger entry behind it. A Relying Party can be registered in test mode: everything stays fully real and fully witnessed, but nothing is billed, so you can build the whole loop on localhost before a production domain exists. Test mode is loopback-only; reserved and private-DNS names can serve real users, so shared staging RPs are registered live.

Embedding is a capability of every plan, not a separate product: signatures are unlimited and never volume-billed or capped, while completed signatures remain visible as usage telemetry. The free tier includes one live Relying Party (test-mode RPs are unlimited), which is enough to ship real customers; a very large embedded audience — thousands of monthly active approvers — is an Enterprise conversation, and nothing is ever refused while that conversation happens.

See the developer reference's Integrating Platforms section and the embedded platforms use-case page for the full walkthrough.

Partly, and the split is deliberate. The managed gateway and the operator console are proprietary. The client SDKs, the MCP proxy, and the offline receipt verifier are Apache-2.0.

INTYGA Intelligence is a separate Apache-2.0, self-hosted application for operational findings. It requires an INTYGA workspace for passkey access and signed privileged changes; its open-source license is separate from the workspace plan.

The verifier in particular has to be open source. An offline verification guarantee is meaningless if the verifying code is a black box you are asked to trust — so its source is available for inspection. The TypeScript verifier has no npm runtime dependencies; optional RFC 3161 timestamp verification also requires OpenSSL 3.

The difference is who holds the key. A policy engine's token attests that the engine decided yes, and it is signed with a key the vendor holds. Ours attests that a specific human, using a specific authenticator, consented to specific parameters — signed by a key we have never possessed and cannot obtain.

That matters for a narrow but important reason. A vendor-signed attestation is verifiable with the vendor's public key, which protects you if they disappear. It does not protect you if they are compromised or coerced, because the party that signed the evidence is the party you would be auditing. This is the same objection we would level at a cloud provider's own audit trail, and it applies to us too — which is why our checkpoints are anchored to transparency logs neither party controls.

Receipt verification is deterministic for the same proof, trusted keys, expectations and validation time. Retaining those inputs supports reproducible historical checks. It does not turn an expired approval into permission to execute today, or establish that the underlying decision was a good one.

In fairness, a classifier answers a question we do not: whether an action is consistent with what an agent was supposed to be doing. That is a real problem and a reasonable way to approach it. We answer whether a person authorized these exact parameters. They are complementary, and if you need both, use both.

Because we cannot forge the entries. Every approval carries a signature made inside the approver's own authenticator, using a private key we have never held.

Deletion is a separate problem, and it needs a separate mechanism: a gapless per-tenant sequence so a removed record leaves a detectable hole, and a two-tier Merkle tree whose daily checkpoint roots are anchored to independent transparency logs. An anchor we operate does not count toward the quorum, because an endpoint the vendor controls is not an independent witness.

One honest boundary: this detects modification and deletion of committed events. It does not prove that an event was never withheld from commitment in the first place.

No, and this is the property we are least willing to compromise. The approval key is managed by the approver's authenticator and is never exposed to INTYGA; we store public keys only. Synced passkeys may be backed up across the user's devices, while a policy can require a hardware-bound credential.

This is not a promise about our conduct — it is a fact about what we possess. We could not produce a valid approval if we were compromised or compelled to.

Policy documents are encrypted in the operator's browser using the tenant's own public key, with a hybrid RSA-OAEP and AES-256-GCM scheme. The gateway stores and relays the opaque blob without ever holding a decryption key. Decryption happens client-side.

Approval quorum is the deliberate exception: it lives in gateway-readable plaintext rules, because a requester that could rewrite its own threshold would not be governed by it.

The gateway records the WebAuthn AAGUID — the authenticator's model identifier — at approval time. An approval rule can require a hardware-backed authenticator, and on Business and above can restrict approvals to a specific allowlist of authenticator models.

One limitation worth knowing: the AAGUID is not checkable in an offline verifier, because it lives in attested credential data the receipt does not carry. It is enforced at approval time, not at verification time.

It fails closed: no approval, no action. That is the correct default for a gate in front of a destructive operation, and it does mean you are adding a dependency to your critical path. We would rather state that plainly than reassure you.

Three things reduce the exposure. Verification runs inside your runtime, with no dependency on us. Retained receipts and trusted keys can still support historical audit checks if we disappear; expiry and single-use rules still prevent an old receipt authorizing a new action. And the gateway is self-hostable on Enterprise.

There is also a specified procedure for approving new actions while we are unreachable — Offline Approval. Your service generates the nonce and builds the challenge itself, approvers sign it on a disconnected device, and your runtime verifies the result with its ordinary check. We are not in the loop at any point, and the validity window is capped in minutes rather than left open.

Note what we deliberately do not offer: pre-signed approvals held in a file against a future incident. That is a bearer capability at rest — possession is enough to act, it cannot be revoked at an offline relying party, and the human approved a hypothetical instead of the incident in front of them. Offline Approval moves the ceremony off the network rather than earlier in time, which is a different thing.

Even so: write the break-glass runbook and rehearse it. Any vendor who tells you their availability makes that unnecessary is selling you something.

That is what Delegation covers. It transfers the authority to approve to named local operators for a bounded period — hours, not weeks — and it is the one artifact in the system that is signed ahead of the incident.

A Delegation authorizes no action on its own. Verification refuses that payload type unconditionally, and there is no opt-in flag that lets one through, because a single mistake there would turn a delegation into exactly the pre-signed bearer capability we refuse to ship. Checking a Delegation is a separate operation whose output feeds a later approval check; it never replaces one.

Reach for it last. If your approvers can be reached at all, Offline Approval is the better answer, because a real person still looks at the real incident.

The call polls to a deadline and returns an expired status rather than hanging. The default wait is 120 seconds, and you can pass your own timeout; the SDK sends a matching server-side TTL so the challenge cannot outlive your wait.

Transient gateway errors do not abort the wait, because a human approval can easily outlast a brief 502. Repeated consecutive failures do throw rather than pretending to still be waiting.

Yes, on every plan including the free one — you should be able to watch a quorum work before paying for it. M-of-N quorums are defined in gateway-owned approval rules. The gateway counts signatures from distinct authorized keys and only moves the challenge to approved when the threshold is met.

Four-eyes — requiring that the requester cannot be the approver — is available on Business and above. Critically, none of this is a client-side argument: there is no requiredApprovals parameter, so a compromised caller cannot pass itself a lower threshold.

Requesters supply an action ID, which matches a rule exactly. Every specific rule must retain the tenant baseline requirements. New workspaces deny unknown IDs unless an administrator explicitly chooses baseline approval. Migrated workspaces retain their older semantics until exact matching is activated. The executing service verifies the receipt against the operation it will perform.

That is a real failure mode and it is why push-approval MFA disappoints. Two things help.

First, the approver sees the exact structured parameters, and those specific bytes are what gets signed — an approval that does not match what executes is worthless, so the content is load-bearing rather than decorative.

Second, the gate is meant to be expensive. It is for the handful of genuinely irreversible actions. If you are interrupting someone two hundred times a day you have configured it wrong, and no amount of cryptography fixes that.

The machine-side path is a policy lookup and a database read, which is negligible next to the thing it is gating. We have not published a benchmark, and we would rather say that than quote a number nobody measured.

The number that actually matters is the human one: a WebAuthn ceremony takes a couple of seconds once the approver is looking at it, and the real latency is however long it takes someone to notice and decide. Plan the gate around human response time, not milliseconds.

Because an approval mechanism nobody installs is an approval mechanism everybody uses. App stores, MDM enrolment, and corporate device policy are all friction between a person and the thing you need them to do.

WebAuthn is already in every browser, backed by a secure enclave or a security key. There is nothing to install on desktop or mobile.

Verification is free forever on every plan, including the free one. Charging to check a proof would contradict the entire point of the product.

Plans are priced on seats, evidence retention and the enterprise policy controls — not on volume. Developer $0 (3 seats, 14-day retention), Starter $149 (5 seats, 90-day retention), Team $499 (10 seats, 1-year retention), Business $1,249 (100 seats, 3-year retention), and Enterprise is negotiated.

Completed approvals are counted as usage telemetry, not volume-billed, and are never refused for billing reasons — a control that gates irreversible actions must not stop working because of an invoice, and if it did, the workaround people reach for is routing around the gate. This holds on every plan including the free one: plans are flat, and there is no per-approval charge, overage billing, spend cap, or top-up mechanism. The most a month can ever cost is the plan price. Self-serve paid tiers can also prepay a year at 10% off — Team, for example, works out to $449/mo billed annually.

No. ISO 27001 is the active certification track and SOC 2 is deferred. Anything we publish about compliance today is a readiness and control mapping, not an attestation, and we label it that way.

We would rather lose a deal on this answer than win one on a softer version of it.

No product can make you compliant with a regulation, and anyone claiming otherwise is describing a problem you will discover during an audit.

What Article 14 requires is effective human oversight of high-risk systems, and in practice the ability to demonstrate it. That is an evidence burden. A signature bound to the exact action, verifiable by a third party, is a materially stronger answer to it than a row in a database you administer — which is a real claim, and a narrower one than the category usually makes.

The monorepo root covers the managed gateway and the operator console, which are proprietary. Each client package — the SDKs, the MCP proxy, and the verifier — ships its own Apache-2.0 license, and that is what is published.

If you find a package where the license in the published artifact disagrees with what this page says, that is a bug and we want to hear about it.