An architecture you don’t have to trust.

Why this exists

Automation got fast enough to outrun supervision. A pipeline deploys, a script rotates a credential, an agent calls a tool — and each of those runs on a credential that was valid, issued to a system that was authorized, doing something nobody specifically agreed to. The credential answers who may act. It says nothing about who decided this particular thing should happen.

Most of the industry responded by making identity stronger: better tokens, shorter TTLs, tighter scopes. That is worth doing and it does not close the gap. A scoped credential constrains what a system may do. It cannot tell you that a person looked at an irreversible operation, understood its parameters, and agreed to it.

What we decided to build

One narrow thing: a way to hold an irreversible action until a named human signs its exact parameters with a hardware-backed key, and a way for the code about to execute that action to check the signature itself — offline, against the signer's public key, with no call back to us.

The narrowness is deliberate. We do not do identity, we do not do access management, and we do not try to decide whether an action is safe. Other people do those well, and a security product that expands until it overlaps everything ends up being trusted for things it was never designed to guarantee.

The part we are least willing to compromise on

INTYGA holds no key that can approve anything. The signature is produced by the approver's authenticator and its private key is never exposed to us. Synced passkeys may be backed up across the user's devices; a policy can instead require a hardware-bound credential. We could not forge an approval if we were compromised, coerced, or dishonest, because the material required to make one has never been in our possession.

The same reasoning shapes the audit trail. A log signed by the party being audited is tamper-evident, not non-repudiable — the attesting party and the accused party are the same. So checkpoints are anchored to independent transparency logs, and an anchor we operate does not count toward the quorum, because an endpoint the vendor controls is not an independent witness.

And the verifier is open source, dependency-free, and small enough to read in an afternoon. We are asking you to rely on it. You should be able to check it rather than take our word.

Why Europe first

We are a Swedish company, and building here shaped what we built. European buyers arrive with the EU AI Act's human-oversight obligations, NIS2, and an ISMS to satisfy, and they arrive asking a specific question: not whether oversight happened, but whether it can be demonstrated to someone who does not trust either of us. That is an evidence problem, and it is a better design constraint than a compliance checkbox.

Being precise here matters more than being enthusiastic. Article 14 requires effective human oversight and the ability to demonstrate it. It does not mandate cryptography, and no vendor can sell you conformity with a regulation. What a signature bound to an exact action gives you is the strongest available evidence — which is a real claim, and a smaller one than the industry usually makes.

What we are not

We are not certified against ISO 27001 or attested under SOC 2 today. ISO 27001 is the active track. Anything we publish about compliance is a readiness and control mapping, and we say so on the page rather than in a footnote.

We are also not the right answer for everyone. If you govern a handful of actions a day on a single platform, a well-configured native control — GitHub Environments, an MFA-protected API call — is probably enough, and we would rather tell you that than sell you something you do not need. The case for a dedicated primitive starts where the approval has to span platforms, outlive the tool that issued it, or convince someone who trusts neither party.