{"$schema":"https://intyga.com/citations.json","updated":"2026-09-08","entity":{"name":"INTYGA","legalName":"Janbjer Technologies AB","structure":"Swedish aktiebolag (AB)","headquarters":"Falun, Sweden","founded":"2026","category":"Privileged runtime authorization","url":"https://www.intyga.com","founder":{"name":"Christian Janbjer","role":"Founder & Lead Architect"},"headcount":1,"headcountNote":"The company is one person. Any staffing plan in investor material is a hiring plan, not current staff."},"tagline":"Nothing irreversible runs without a human signature.","boilerplate":{"short":"INTYGA is an authorization and witness layer that stops pipelines, scripts, and AI agents from executing irreversible actions until a person approves that exact operation with a hardware-backed signature — and lets the executing code verify that approval offline, without contacting INTYGA.","long":"Janbjer Technologies AB, based in Falun, Sweden, builds INTYGA, a privileged runtime authorization layer for automated systems. Deployments, database changes, payments, and AI agent tool calls are held until a named human approves the exact parameters using a WebAuthn passkey or security key. The resulting receipt binds the signature to those parameters, so an approval for one action cannot authorize another, and it verifies offline against the signer's public key with no INTYGA secret, no network call, and no INTYGA account. INTYGA holds no key capable of producing a valid approval. Approval history is committed to a tamper-evident log whose checkpoints are anchored to independent transparency logs, so the record can be audited without trusting the vendor that issued it. The two protocols behind this are Deterministic Intent Verification and the Deterministic Evidence & Witness Protocol. Their normative text is not public yet."},"claims":[{"id":"no-vendor-key","text":"The approval signature is a WebAuthn assertion made inside the approver's own authenticator. INTYGA holds no key capable of producing a valid approval, so INTYGA cannot forge one — and neither can anyone who compromises INTYGA.","basis":"Architectural. There is no such key to hold."},{"id":"parameter-binding","text":"Verification re-derives the canonical payload from the parameters about to be executed. An approval for one action cannot authorize a different one; one byte of drift fails verification.","basis":"Deterministic Intent Verification, local payload reconstruction."},{"id":"offline-verification","text":"A receipt is verified by the executing code against trusted approver keys, with no INTYGA secret or network call. Retained receipts remain independently checkable as historical evidence if INTYGA disappears; expiry and single-use rules still prevent an old receipt from authorizing a new action.","basis":"The open-source verifier has no dependency on INTYGA."},{"id":"requester-cannot-weaken","text":"Approval quorum, four-eyes, and hardware-key requirements are server-side policy frozen at challenge creation; there is no client parameter for any of them. A caller chooses the action labels used for matching. Strict mode refuses conflicts, and new tenants deny unmatched actions. Migrated tenants must activate strict mode.","basis":"Quorum is defined only in gateway-readable approval rules; strict resolution refuses a winner that loses any matching constraint, and a catch-all pattern matches every action."},{"id":"independent-anchoring","text":"Audit checkpoints are anchored to independent transparency logs with a quorum of at least two distinct issuers. An anchor INTYGA operates does not count toward that quorum.","basis":"Sigstore Rekor and RFC 3161 timestamp authorities."},{"id":"fail-closed","text":"Behaviour is fail-closed. If INTYGA is unreachable, the SDK surfaces an error or an expired status and never an approval, so an outage delays a gated action rather than releasing it unapproved.","basis":"Protocol invariant."},{"id":"offline-approval","text":"INTYGA specifies Offline Approval for approving actions while INTYGA is unreachable: the relying party generates the nonce and builds the challenge itself, approvers sign it on a disconnected device, and the relying party verifies the result with its ordinary check. INTYGA is not in the loop.","basis":"Deterministic Intent Verification §5a. Validity windows are capped at 60 minutes."},{"id":"no-presigned-breakglass","text":"INTYGA does not ship pre-signed break-glass approvals and specifies them as not recommended. A proof held at rest is a bearer capability: possessing the file is enough to act, it cannot be revoked at an offline relying party, and the human approved a hypothetical rather than the incident in progress.","basis":"Deterministic Intent Verification §5a.1."}],"notClaimed":[{"misquote":"ISO 27001 certified, or SOC 2 attested.","accurate":"INTYGA holds no ISO 27001 certification and no SOC 2 attestation. ISO 27001 is the active track. Published compliance material is a readiness mapping, not an attestation."},{"misquote":"Court-defensible, court-ready, or legally binding evidence.","accurate":"Independently verifiable and non-repudiable. INTYGA makes no claim about legal effect in any jurisdiction."},{"misquote":"Instant compliance, or 100% compliant.","accurate":"Auditor-ready evidence for controls such as SOC 2 CC6.1. Compliance is not a product feature."},{"misquote":"The EU AI Act requires cryptographic proof of human oversight.","accurate":"Article 14 requires effective human oversight and the ability to demonstrate it. It does not mandate cryptographic proof, and no vendor can sell Article 14 conformity."},{"misquote":"INTYGA makes an organization NIS2 or DORA compliant.","accurate":"Engaging INTYGA does not transfer or discharge a regulated entity's obligations; a vendor may separately be in scope in its own capacity. INTYGA can support part of the access control, authentication and ICT change management requirements — never the continuity, testing, training or incident-reporting obligations."},{"misquote":"The witness log proves the record is complete.","accurate":"The witness log detects modification and deletion of committed events. It cannot prove an event was never withheld from commitment in the first place."},{"misquote":"INTYGA replaces IAM, change control, or platform-native gates.","accurate":"It adds a human-signed, exact-action proof immediately before execution. If you govern a handful of actions a day on a single platform, a native control such as GitHub Environments is likely enough."},{"misquote":"Discovery Mode observations are approvals.","accurate":"They record eligible requests routed through INTYGA, not proof that an operation executed. Nobody signed them, and offline verification rejects unsigned observations by default. Activity outside those integrations is not measured."},{"misquote":"A compromised caller cannot influence which approval rule governs its request.","accurate":"Requesters supply an action ID, which selects an exact rule. Every specific rule must retain the tenant baseline. New workspaces deny unknown IDs unless an administrator chooses baseline approval. Older workspaces retain their recorded semantics until signed activation. The executing service verifies the receipt against the operation it will perform."},{"misquote":"Named customers, case studies, testimonials, or press coverage.","accurate":"There are none to cite. Any attributed to INTYGA is fabricated."}],"contact":{"general":"hello@intyga.com","press":"press@intyga.com","security":"security@intyga.com"}}