Human Approval for AI Agent Actions: How Four-Eye Control Works

Main claim: Four-eye control makes a high-risk AI agent action depend on signatures from multiple independent approvers over the exact operation that will execute.

An AI agent can prepare a valid payment, deployment, certificate, or key operation while the effect still requires human judgment. A confirmation button adds value only when the reviewed values stay bound to execution. Four-eye control gives each approver a cryptographic vote over one canonical operation and requires an m-of-n threshold before key use. This article explains what reviewers should see, what they sign, how approval reaches the cryptographic operation, and where the control ends.

What is four-eye control?

Four-eye control requires independent approval from more than one authorized party. TKeeper represents the requirement as m accepted signatures from n configured approver keys.

A 2-of-3 policy has three eligible approvers and needs two distinct signatures. One approver can be unavailable while the operation still receives the required votes.

The policy belongs to a TKeeper key identity. Protected key operations continue after the approval threshold, authentication, permissions, authority policy, audit, lifecycle, and quorum checks pass.

The approval signatures cover the operation body. They provide evidence that the required approver keys accepted those exact fields.

When should an AI agent action require human approval?

Human approval should protect effects that exceed the agent's autonomous authority. The trigger should use fields that determine impact.

Common triggers include:

• payment amount above an autonomous limit
• new or external destination
• production environment
• certificate subject or validity outside a routine profile
• full or cross-tenant data export
• key rotation, refresh, import, or destruction
• policy change or break-glass operation
• elevated risk verdict

Consider a treasury agent with autonomous authority up to 1,000 USD. A 2,500 USD invoice payment moves into a 2-of-3 approval path because the amount crosses the configured limit.

The same tool may therefore support autonomous and reviewed actions. Policy chooses the path from the effect.

What should the approver review?

The approver should review every field that can change the effect. The display should derive those values from the canonical operation submitted for signing.

A payment review can show:

Action: pay invoice
Asset: USDC
Amount: 2,500
Destination: 0x8c...42
Network: Base
Invoice: INV-4821
Agent identity: treasury-agent-prod
Expires: 2026-07-28 18:10 UTC

A deployment review needs another field set:

Service: billing-api
Environment: production
Artifact: sha256:7f...
Change request: CHG-1842
Agent identity: release-agent-prod

The review UI should render the operation from signed fields. A separate prose summary can omit, rename, or misrepresent a value.

What exactly does an approver sign?

An approver signs a SHA-256 hash of TKeeper's canonical operation body. Canonicalization gives clients and TKeeper the same byte representation.

TKeeper's approval rules include:

• compact UTF-8 JSON
• lexicographic object-field ordering
• recursive ordering for nested object fields
• omission of fields whose value is null
• preserved array order
• byte-exact strings
• exclusion of approvals.proofs from the hash

Array order remains part of the request. Sorting an approver list, authority list, or another array would create different approved bytes.

The approver signs the resulting 32-byte digest with its configured key. TKeeper verifies the proof through the algorithm declared for that approver.

Which approver algorithms can TKeeper verify?

TKeeper supports approver keys from the cryptographic platforms included in the runtime artifact.

The ECC platform supplies SECP256K1, P256, and ED25519. The PQC platform supplies the ML-DSA algorithms.

Each configured public key must decode under its declared algorithm. Duplicate approver keys are rejected because n counts distinct approvers.

The approver fingerprint is the base64 encoding of the SHA-256 digest of the encoded public key. The submitted proof identifies its configured key through this fingerprint.

How does TKeeper process an approved agent action?

TKeeper verifies approval before the protected key operation continues.

AI agent proposes action
-> policy requires approval
-> review system renders canonical operation
-> approvers sign operation hash
-> TKeeper verifies m distinct proofs
-> authority, audit, lifecycle, and quorum controls continue
-> TKeeper produces the result

For a signing request, the approved fields include the coordinator peer, key identity, command, optional tweak, nonce, and timestamp. The command contains the typed action governed by the key authority.

A change to the command creates another canonical hash. Previous signatures fail verification against the changed operation.

This binding prevents approval from floating between payment amounts, destinations, deployment artifacts, or other command values.

How do nonce and timestamp limit approval reuse?

The approval nonce identifies one approval attempt at the coordinator boundary. TKeeper consumes the nonce after enough signatures verify.

The approval timestamp must fit the configured approval TTL and stay out of the future. An expired approval fails before the key operation continues.

Threshold protocol retries reuse the same accepted approval. Non-coordinator peers verify its signatures and request fields without consuming the nonce again or repeating the age check.

This retry behavior creates a documented boundary. A compromised coordinator that bypasses its own nonce and TTL checks may replay a previously valid approval with the same fields. Lifecycle and session checks still apply.

Downstream replay needs a separate rule. The backend should enforce the signed action's expiry, nonce, sequence, or idempotency state when repeat execution matters.

What is the difference between four-eye modes?

TKeeper supports STRICT and LENIENT four-eye modes.

STRICT fits identities whose routine use requires approval. A treasury key can require approval for every signature.

LENIENT fits identities that permit automated signing while reserving approval for selected lifecycle changes. Authentication, permissions, authority policy, and audit still govern other operations.

Choose the mode from the operations that require human judgment. The mode name alone gives no risk classification for the identity.

How is human approval different from policy?

Policy evaluates machine-readable rules over the action and context. Human approval adds judgment from designated reviewers.

A payment policy can check:

asset = USDC
amount <= 10,000
network = Base
destination belongs to approved vendor set

An approver can evaluate information outside those rules, such as a new vendor relationship, unusual timing, or a change request that needs investigation.

The two controls can work in sequence. Policy rejects actions outside the declared boundary, while approvers decide among actions eligible for review.

Policy should also determine when approval is required. A fixed approval requirement on every action can create review fatigue and slow routine operations.

How is human approval different from threshold MPC?

Human approval distributes the business decision. Threshold MPC distributes the cryptographic operation.

A 2-of-3 four-eye policy can run on a mono TKeeper identity. Two approvers accept the action, and one TKeeper node performs the private-key operation.

The same policy can run on a 2-of-3 threshold identity. Two approvers accept the action, then two TKeeper peers cooperate to produce the signature.

Separate approver keys from TKeeper peer shares. Co-locating them under one operator or host reduces the independence gained from both layers.

How should external risk systems affect approval?

External risk systems should supply action-bound inputs to policy and review. Fraud, AML, KYT, prompt-injection, or business systems can trigger approval or denial.

A risk verdict should identify the canonical intent or its digest. A verdict for one payment should stay tied to its amount, destination, network, and invoice.

The review UI can show the verdict, source, timestamp, and covered action. The approver can then evaluate the result alongside the exact operation.

Unavailable verdicts need a defined outcome. High-impact actions may fail closed or require a separate manual process.

How should approval keys be stored?

Approval keys should live outside the systems they approve. Separation prevents one application compromise from creating both the request and its required votes.

Possible approval-key locations include:

• hardware security keys
• HSM-backed approval services
• protected operator devices
• isolated signing services
• post-quantum signing services using ML-DSA

The storage choice should match the impact of an approval-key compromise. A stolen approver key can cast valid votes until the configuration changes or the credential becomes unusable.

Approver onboarding and removal need authenticated administration, audit, and tested recovery. The approval policy should also preserve enough available approvers to reach m.

How should you implement human approval for one AI action?

Start with one action whose autonomous boundary is already defined.

1. List every field that changes the effect.
2. Define the policy condition that triggers approval.
3. Choose m and n.
4. Create distinct approver keys.
5. Keep approver keys outside TKeeper peers and the agent runtime.
6. Build approval tooling that uses TKeeper's canonical hash rules.
7. Render the signed fields on a trusted review surface.
8. Include a new nonce value and current timestamp.
9. Submit enough distinct proofs with the exact operation.
10. Verify the resulting TKeeper proof at the backend.
11. Enforce downstream replay rules.
12. Record the request, approvers, policy decision, proof, and execution result.

Test the process with one changed field. A new amount, destination, artifact, environment, generation, or tweak should require another approval.

Which approval failures should you test?

Approval tests should cover signature validity, distinctness, freshness, binding, and availability.

Test these cases:

1. Submit fewer than m proofs.
2. Submit the same approver key twice.
3. Change one operation field after approval.
4. Change array order after approval.
5. Reuse a consumed nonce.
6. Submit an expired timestamp.
7. Submit a timestamp from the future.
8. Use an approver algorithm absent from the build.
9. Remove one approver and verify that m remains reachable.
10. Replay the final action proof at the backend.

Each failure should stop before the protected effect. Record the stage and stable error used for operator diagnosis.

Which implementation errors weaken human approval?

Approving a conversation or workflow ID permits another action inside that container. Sign the exact operation body.

Showing a handwritten summary can hide a changed effect field. Render the values derived from canonical input.

Keeping approver keys beside TKeeper shares joins two controls under one compromise. Separate their custody.

Allowing duplicate approver keys turns several configured entries into one decision maker. Require distinct public keys.

Using long approval windows increases the time available for delayed use. Set TTL from the review and execution workflow.

Applying approval to the tool name alone grants every parameter combination behind that tool. Cover the typed command.

Treating approval as downstream replay protection leaves repeat execution open. The backend needs its own freshness and idempotency state.

Requiring review for every low-impact action creates approval volume without better judgment. Set autonomous limits and escalate by effect.

Where does four-eye control stop?

Four-eye control depends on approver-key custody. Compromised keys can produce accepted approval signatures.

The review depends on accurate presentation. Hidden or mislabeled fields can mislead a reviewer while the signature remains cryptographically valid.

The approval threshold controls configured votes. Collusion among m approvers reaches that boundary.

TKeeper controls operations that use its key identities. Another accepted key or backend credential creates another route.

The final proof can be replayed when the backend omits freshness and idempotency checks.

Availability depends on enough approvers before the TTL expires. Recovery needs a controlled way to replace lost approver keys without silently weakening m.

What should you do next?

Choose one AI agent action that currently relies on a confirmation button. Make two independent approvers sign the exact operation and require the resulting TKeeper proof at the backend.

Read How MPC Distributes AI Agent Signing Risk Across Multiple Nodes for distributed key use and How to Limit Prompt-Injection Damage in AI Agent Workflows for approval triggers after model compromise.