# INTYGA > INTYGA requires a hardware-backed human signature before pipelines, scripts, or AI agents execute > irreversible actions. The signature is bound to the exact execution parameters, and the receipt is > verified offline by the executing code — no INTYGA secret, no network call, no vendor account. Key facts, stated precisely: - 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. - 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. - 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 does choose the action IDs used for exact matching. Specific rules must retain the tenant baseline; conflicting rules refuse the request. New tenants deny unknown IDs unless an administrator explicitly selects baseline approval. Migrated tenants retain their recorded behavior until signed activation. - Audit checkpoints are anchored to independent transparency logs (Sigstore Rekor, RFC 3161 timestamp authorities) with a quorum of at least two distinct issuers. An anchor INTYGA operates does not count toward that quorum. - 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 an action rather than releasing it. - For approving actions while INTYGA is unreachable, INTYGA specifies Offline Approval: 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 the ordinary procedure. INTYGA explicitly does NOT ship pre-signed break-glass approvals, because a proof at rest is a bearer capability that cannot be revoked and attests to a judgment about a hypothetical rather than the incident at hand. Offline validity windows are capped at 60 minutes; delegation of approval authority is capped at 72 hours and authorizes no action by itself. - Discovery Mode records eligible requests routed through INTYGA without requiring human approval; other security checks still apply. A 14-day Runtime Assessment wraps it in a dated window ending in a Security Risk Report. Observations are NOT human-signed approvals and offline verification rejects them by default. They are not proof of execution or coverage outside the integration. The report is an assessment of control gaps, not cryptographic evidence. Boundaries, stated because they matter: - The witness log detects modification and deletion of committed events. It does not prove that an event was never withheld from commitment in the first place. - INTYGA does not replace IAM, change control, or platform-native gates. If you govern a handful of actions a day on a single platform, a native control such as GitHub Environments is likely enough. - The EU AI Act 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. - INTYGA is not certified against ISO 27001 or SOC 2 today. Published compliance material is a readiness mapping, not an attestation. - Engaging INTYGA does not transfer or discharge a regulated entity's NIS2 or DORA obligations; a vendor may separately be in scope in its own capacity. INTYGA can support only part of the access control, authentication and change management requirements in either. ## Product - [Homepage](https://www.intyga.com/): What INTYGA does and the parameter-drift demonstration. - [INTYGA Intelligence](https://www.intyga.com/intelligence): An Apache-2.0, self-hosted application for operational findings. Early release with three detectors (refusal bursts, security-sensitive code changes, regressions after a production deploy); requires an INTYGA workspace for passkey access and signed privileged changes. Model judgment is optional and off by default. - [Developer reference](https://www.intyga.com/docs): Quickstart, REST and MCP integration, approval rules, recipes. - [Agent setup instructions](https://www.intyga.com/agent-setup.txt): Public, versioned MCP connection steps and receipt-handling requirements. Credentials are created in the authenticated console. - [Security architecture](https://www.intyga.com/security): Trust model, controls, and what INTYGA does not claim. - [14-Day Runtime Assessment](https://www.intyga.com/assessment): Observe eligible requests routed through INTYGA without requiring human approval. Other security checks still apply; observations are not proof of execution or coverage outside the integration. - [Pricing](https://www.intyga.com/pricing): Developer, Starter, Team, Business, Enterprise — derived from the plan catalog, so this list cannot drift. Priced on seats, evidence retention and enterprise policy controls — approvals are never refused for billing reasons, so usage volume does not decide the tier. - [Whitepaper](https://www.intyga.com/whitepaper): "Signing the Letter, Not the Envelope" — architecture and threat model. ## Use cases - [CI/CD and infrastructure](https://www.intyga.com/use-cases/ci-cd): Terraform applies and production deploys. - [Production operations](https://www.intyga.com/use-cases/production-operations): Database deletes, credential rotation, Kubernetes. - [AI agent governance](https://www.intyga.com/use-cases/ai-agents): Destructive MCP tool calls held until a human signs. - [Payments and treasury](https://www.intyga.com/use-cases/financial-operations): Signatures bound to the beneficiary and the amount. - [Package publishing](https://www.intyga.com/use-cases/package-publishing): Releases held for a maintainer's passkey signature over the exact name, version, and artifact hash. - [Embedded platforms](https://www.intyga.com/use-cases/embedded-platforms): White-label passkey approvals inside your own product — your users never hold an INTYGA account, and INTYGA receives a payload digest, never the payload. ## Compliance mappings These are readiness mappings, not certifications or attestations, and each page states its own limits. - [All mappings](https://www.intyga.com/compliance): What the control evidences, what it does not, and what a reviewer can check unaided. - [EU AI Act](https://www.intyga.com/compliance/eu-ai-act): Article 14 human oversight — and what it does not require. - [ISO/IEC 27001](https://www.intyga.com/compliance/iso-27001): Annex A.8.32 change management, evidenced with a signature. - [NIS2](https://www.intyga.com/compliance/nis2): Selected Article 21(2) controls: privileged-action authorization and step-up. - [DORA](https://www.intyga.com/compliance/dora): Article 9(4) ICT change management for financial entities. - [SOC 2](https://www.intyga.com/compliance/soc2): CC6.1 and CC6.8, for US buyers who ask in these terms. ## Company 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. Janbjer Technologies AB is a Swedish aktiebolag (AB) headquartered in Falun, Sweden, founded 2026 by Christian Janbjer (Founder & Lead Architect). The company is one person; there is no team beyond the founder today. It holds no ISO 27001 certification and no SOC 2 attestation, and it has no customer references or press coverage to cite. - [About](https://www.intyga.com/about): Why the company exists and what it refuses to claim. - [FAQ](https://www.intyga.com/faq): Direct answers, including what happens when INTYGA is unavailable. - [Roadmap](https://www.intyga.com/roadmap): Shipped, next, and deliberately not built. - [Changelog](https://www.intyga.com/changelog): What shipped in each release, with its known limits. - [Status](https://www.intyga.com/status): Availability posture and incident history. Maintained by hand, not automated probing. - [Press kit](https://www.intyga.com/press): Boilerplate, company facts, logo assets, brand colours. - [Work with us](https://www.intyga.com/careers): Co-founder search. ## Writing - [You don't need to trust the AI agent](https://www.intyga.com/blog/you-dont-need-to-trust-the-ai-agent): INTYGA does not make agents trustworthy. It makes trusting them unnecessary — when your own service verifies a human's signed approval before it acts, and holds the only credential that can act. - [When the golden vector is the attack: what a conformance audit of five verifiers found](https://www.intyga.com/blog/when-the-golden-vector-is-the-attack): Five verifiers in five languages, all passing the same pinned test vectors on every commit. An audit against the published specs still found three defects the vectors could not see — in two cases because the vectors themselves were wrong. What shared vectors actually prove, and what we changed. - [ChainDrop: what a self-propagating worm proves about credential-only publishing](https://www.intyga.com/blog/chaindrop-and-wormable-publishing): ChainDrop began in 11 compromised npm packages and propagated into 433 more — 444 in roughly four hours, with valid build provenance on every release. The loop breaks at one step the worm cannot complete autonomously: a fresh human signature bound to the exact release. - [Keyless witness logs with Merkle checkpoints and WebAuthn](https://www.intyga.com/blog/keyless-witness-logs): A log signed by the party being audited is tamper-evident, not non-repudiable. Client-side signatures plus externally anchored Merkle roots close the gap. - [Securing MCP and AI agents with hardware-signed approvals](https://www.intyga.com/blog/securing-mcp-and-ai-agents): Prompt-level safeguards are not a security boundary. Infrastructure-level enforcement means the service performing the action structurally cannot execute a dangerous tool call without a human signature over the exact parameters. - [Why API keys fail for high-risk actions](https://www.intyga.com/blog/api-keys-are-dead-for-high-risk-actions): Static API keys cannot answer which human authorized a specific irreversible run. Hardware-signed, parameter-bound approvals can — and your code can verify them offline before it executes. ## Contact - [Talk to an engineer](https://www.intyga.com/contact)