Require a human signature before your systems move money, change access or modify production data. Your service verifies exactly what was approved—and you retain independently verifiable evidence.
For AI agents, pipelines, backend services and human operators.
Try the signature check. No account needed.
For each operation you protect, keep the execution credential in the service performing the action. That service must verify valid human authorization before it acts, with no alternate credential or route available to the requester.
Imagine an AI agent requesting a database cleanup. This synthetic action is already signed. Change the table and see why the original signature cannot authorize the new request.
Delete table
payments_2024Database: acme-prod-dbDelete table
payments_2024Database: acme-prod-dbChanging a signed parameter changes the bytes being verified. This example uses your browser's WebCrypto.
The payload below is formatted for readability. Verification uses the compact canonical JSON bytes, with a real P-256 / SHA-256 signature check running locally in your browser.
{
"actionType": "database.drop_table",
"display": "Drop table `payments_2024` from acme-prod-db",
"evidence": null,
"expiresAt": "2026-07-30T12:05:00.000Z",
"nonce": "b7f3c1a29e5d4408a1c6f0e2d3b8a745",
"params": {
"database": "acme-prod-db",
"rows": 4182990,
"table": "payments_2024"
},
"requester": {
"attestation": null,
"did": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"
},
"requirement": {
"allowedAaguids": [],
"requesterCannotApprove": true,
"requireHardwareKey": true,
"requiredApprovals": 2,
"signerClass": "human"
},
"target": "acme-prod-db",
"type": "div-intent-verification",
"v": 1
}This demonstrates signature binding only. It does not perform a passkey ceremony or validate a complete approval receipt, expiry, quorum, hardware-key requirements or single use. The fixture has a historical expiry and authorizes no real operation.
Would it catch that change?
The decision is only the beginning
Keep the approver's signature and the details it covers. Your team and reviewers can check that evidence independently, without an INTYGA secret.
See how the evidence is verified →An approval receipt proves approval. It does not prove the downstream operation ran.
The witness trail makes changes to committed approval history detectable, with checkpoints anchored to independent witnesses. It cannot prove an event was never withheld before commitment. Explore the trust boundaries →
Bring it back to your systems
Choose where you need human control. See what changes in your workflow and what evidence remains.
Showing the ai agents example.
AI agents
An AI agent requests a production database cleanup. A person approves one table, but the agent later proposes a different target.
Could the agent still delete the other table?
Your execution service holds the database credential and verifies approval against the exact operation it will run. The agent can request work, but must have no credential or alternate route that bypasses this check.
Keep the human signature and the action details it covers. A changed table needs a new approval.
Explore AI agent approvals →The same approval boundary works for pipelines, scripts, backend services and human operators. Explore AI agent tool calls, package publishing or approvals inside your own product.
One boundary, before execution
Place the approval gate immediately before the operations you choose to protect. Your existing systems keep control of execution.
An operator, service, pipeline or agent submits the exact operation for approval.
A person reviews the details and signs with a passkey. Your configured approval rules determine who must sign.
Your code checks the receipt against its own operation parameters and trusted approver keys, offline.
Only after the checks pass, your code consumes the approval once and performs the operation.
Rebuild the expected operation from your own parameters and use your own trusted approver keys. Your execution path must enforce verification and prevent receipt reuse.
import { verifyApprovalReceipt } from "@intyga/verify";
const check = verifyApprovalReceipt(receipt, {
target: "prod-payments-eu",
actionType: "wipe_production",
params: { target: "prod-db-1" },
nonce,
approvers: { dids, resolveKey },
}, {
expectedOrigin: "https://app.intyga.com",
expectedRpId: "intyga.com",
});
if (!check.ok) throw new Error(check.reason);Ordinary ES256 and WebAuthn approval receipts are supported in all five languages.
Questions worth asking
The approving signature is made by the person's authenticator. INTYGA does not hold its private key. Your service verifies against approver keys it independently trusts. Synced passkeys are supported; your rules can require a hardware-bound credential.
Quorum and separation-of-duties requirements come from gateway-owned approval rules. A requester cannot lower the required number of signers through its request parameters.
Existing receipts can still be checked offline, subject to their validity and your verification requirements. New approvals wait, or use a separately configured Offline Approval procedure. A correctly integrated execution gate refuses an operation without valid approval.
You choose and integrate the operations to protect. Your execution service must check the approval, enforce the result and prevent reuse. Operations outside that path are outside INTYGA's coverage.
INTYGA Intelligence · Open source · Self-hosted
Investigate unusual authorization activity with evidence behind each finding. Intelligence runs on your infrastructure and uses INTYGA to protect sensitive configuration changes with signed approval.
Early release. Requires an INTYGA workspace.
Start with a real question
Plan a 14-day assessment of one workflow. Explicitly connect the requests you want to observe, review the approval gaps, then decide what to enforce.
Plan an assessment of one workflowThe assessment covers the requests you connect. Signing up does not discover your systems.