INTYGA: Make trust unnecessary

Your team should decide what reaches production, which payment goes out and which permission changes take effect. INTYGA gives the service performing those actions a human-signed approval to verify before it acts. Agents can prepare the work; your application enforces the human decision over the exact target and parameters.

Enterprises already put AI agents to work without fully trusting them. An agent can be redirected by untrusted input, misunderstand an instruction, or simply make a mistake; the work still goes ahead. Today that is accepted risk. Our prediction is that distrust will become a deliberate architectural assumption rather than a temporary discomfort while models improve.

The prevailing response is to govern the agent: identify it, classify its autonomy, narrow its permissions, and watch it. Gartner's May 2026 guidance recommends proportionate controls by autonomy level and explicitly warns that approval fatigue can make human review meaningless. Those controls matter. But autonomy describes the actor, while the irreversible consequence happens in another system. That is where the decisive check belongs.

External runtime controls already make this assumption. NVIDIA's March announcement of OpenShell describes a runtime that helps enforce controls around the agent. INTYGA gives the receiving application a further condition to enforce: human authorization for the exact consequential action.

The risk is in the sequence

Consider an agent permitted to read a customer record, summarize it, attach a document, and send a message. Each action may pass its own access check. Together they can move sensitive data outside the organization, an outcome nobody approved. The agent did not need a forbidden permission; it needed a path through several permitted ones.

Least privilege reduces what any one credential can do, and we still need it. It does not settle whether a particular sequence should end in a particular transfer, payment, or production change. An access policy can constrain combinations it models. The system performing the consequential action still needs to establish whether this particular request is authorized.

INTYGA puts human authorization where the action happens

Put the authorization check at the systems that can move money, change IAM, alter production data, or release information. Let agents reason and prepare work inside bounded environments. When one asks a consequential system to act, that system should require proof that a human approved this action, for this target, with these parameters. The agent must have no credential or alternate route that bypasses the check.

INTYGA lets the human sign that exact intent with a passkey. The executing system rebuilds the expected intent from what it is actually about to do, then checks the signature against an approver key it already trusts. A changed recipient, resource, amount, or other signed parameter fails verification before execution. An approval of an agent-written summary, followed by an unchecked API call, cannot make that promise.

The approver signs in the browser with a passkey or security key. INTYGA never holds the private key that produces that approval. Your service verifies the resulting receipt without calling us, and your team can retain it for independent review. The same authorization pattern applies to requests from operators, services, pipelines and agents.

Untrusted agent                Human approver
      |                              |
      |  exact action requested      |  reviews action, target,
      |                              |  and parameters
      v                              |
Consequential system <-------- passkey signature
      |
      |-- rebuilds the intent from what it will execute
      |-- verifies the signature against trusted approver keys
      |-- refuses changed, expired, or replayed authorization
      |
      v
Payment / IAM change / production write / data release

Don't put the human in the agent's loop. Put the human at the boundary of consequence. This also keeps approval requests scarce enough to read: the check belongs at the few outcomes where being wrong is costly, rather than at every intermediate tool call.

Give system owners control over what executes

Agent runtime controls and application authorization can both assume a compromised agent. Runtime controls restrict the environment in which it works; the application can additionally require a human signature for a particular consequential request. Each control needs an owner outside the agent's reach.

Responsibility moves toward the owners of the systems agents can affect. Instead of asking only, "Is this agent safe enough to have write access to our ERP?" they ask, "Can our ERP safely receive a request from an agent we assume is compromised?" That question has an answer in application architecture: who holds the execution credential, what exact request is verified, and whether any route can avoid verification.

Exact-action authorization is an application-architecture responsibility within the wider agent-security problem. The executing system can require human approval even when a request passes runtime policy. We expect more consequential systems to adopt this check, alongside isolation and least privilege; we are not claiming enterprises have already done so at scale.

Evidence your team can verify independently

Evidence that only the vendor's own software can verify is still vendor testimony. The protocols behind INTYGA are open specifications so the party relying on an approval or an audit record can check it independently.

DIV defines how a human authorization is bound to the exact action before execution. DEWP defines portable evidence that events were committed to a tamper-evident history with independent external anchoring. It can expose changes to committed history; it cannot prove an event was never withheld from commitment.

Start with INTYGA. Explore how it works, read the full DIV specification and DEWP specification. Choose one high-impact operation and build your first INTYGA approval flow, or talk to us about your workflow.