Cryptographic Evidence of Human Oversight Under the EU AI Act

Technical abstract. Human oversight becomes difficult to evidence when an autonomous system can generate proposals whose execution is separated in time, service, and identity domain from the human decision that authorized them. A natural-language transcript can document conversation, but it does not inherently bind an approver's identity, authentication strength, approval time, policy version, exact machine payload, and eventual connector request into one verifiable object. This historical payment design examines a cryptographically committed approval transition while preserving the distinction between evidence of a control and proof of regulatory compliance.

Legal scope and amended timetable

Article 14 of Regulation (EU) 2024/1689 requires high-risk AI systems to support effective oversight by natural persons during use. Article 26 assigns deployers responsibilities for competent, trained, authorized and supported overseers, subject to the applicable scope and timetable.

The source is Article 1(40) of Regulation (EU) 2026/1744, adopted on 8 July 2026, published on 24 July and in force from 27 July. Publication, entry into force and the later application dates are distinct.

Ordinary AI-assisted vendor payments or B2B disbursements do not become Article 14 high-risk systems solely because money is involved. Classification depends on intended use and the applicable category. These provisions do not mandate a Nikxius certificate or a universal agent-execution certificate. The mechanism described here can support technical evidence for configured oversight procedures; it does not determine legal classification or establish compliance.

Conversation is not an exact control binding

A message thread may carry evidentiary value, but it does not by itself bind the final connector request to an identity provider, authentication strength, policy version, or exact machine payload.

Native payment controls already cover substantial ground. Modern Treasury documents approval rules, reviewer groups and sequential approval chains. The engineering question is what exact request those controls authorize and how that authority is checked at dispatch, not whether approval systems exist.

A proposal and a separate enforcement boundary

In this conceptual architecture, the AI agent proposes an exact payload. Policy and authenticated human approvals create authority. A connector verifies that authority before dispatch. This boundary depends on the agent lacking another credential or write path.

{
  "type": "nikxius.proposer-manifest.v1",
  "intent_id": "018f...uuid",
  "agent": {
    "agent_id": "payables-agent-prod",
    "model_class": "declared-by-deployer"
  },
  "prompt_sha256": "base64url(32-byte-digest)",
  "proposed_payload_sha256": "base64url(32-byte-digest)",
  "policy_sha256": "base64url(32-byte-digest)",
  "created_at": "2026-09-03T10:15:32Z"
}

The prompt hash commits to supplied bytes if those bytes are later produced. It does not reveal the prompt, establish that the prompt was truthful, or prove what an AI reasoned.

OIDC step-up identity binding

Under OpenID Connect Core, the relying party validates the token signature, issuer, audience, nonce, expiration and authentication time as required by its flow. It then checks the required authentication context and accepted authentication methods under the organization's identity-provider policy. Requesting acr_values alone does not establish that the requested assurance was achieved.

1. Build exact execution manifest M.
2. Compute dM = SHA256(JCS(M)).
3. Render the high-consequence fields of M to the human.
4. Initiate OIDC authentication with fresh nonce, max_age, and acr_values.
5. Validate signature, iss, aud, nonce, exp, auth_time, acr, and amr.
6. Obtain an explicit APPROVE or REJECT action.
7. Create approval A_j bound to dM.
8. Repeat until the policy-defined quorum is satisfied.
9. Persist intent and the approval-set digest.
10. Issue the short-lived execution authorization.

{
  "type": "nikxius.human-approval.v1",
  "intent_id": "018f...uuid",
  "effect_digest": "sha256:...",
  "policy_digest": "sha256:...",
  "decision": "APPROVE",
  "identity": {
    "oidc_issuer": "issuer-identifier",
    "oidc_subject": "subject-identifier",
    "auth_time": 1788429887,
    "acr": "enterprise-defined-assurance-context",
    "amr": ["mfa", "hwk"]
  },
  "approval_nonce": "base64url(...)",
  "approved_at": "2026-09-03T10:18:14Z"
}

A valid approval is a conjunction

Authentication is necessary but does not prove that the user approved a particular payment. The approval record must bind identity facts and an explicit decision to the final effect and policy digests.

In this design, the quorum counts distinct authenticated subjects and policy excludes the proposer from approving the same action. Repeated clicks by one identity do not satisfy multiple quorum seats. Distinct accounts do not, by themselves, establish independent human judgment.

Final enforcement at the connector

function enforce(request, authorization):
    require authorization.alg == ES256
    require trusted_authorization_key(authorization.kid)
    require verify_signature(authorization)

    M  := canonicalize_connector_request(request)
    dM := SHA256(JCS(M))

    require dM == authorization.effect_digest
    require current_intent.state == AUTHORIZATION_ISSUED
    require authorization.intent_id == current_intent.id
    require authorization.policy_digest == current_intent.policy_digest
    require authorization.approval_set_digest == current_intent.approval_set_digest
    require authorization.idempotency_key == current_intent.idempotency_key
    require authorization not expired
    require no prior terminal failure forbids execution

    dispatch using persisted idempotency key

If an intermediate service substitutes a beneficiary account covered by the canonical manifest, the digest changes. A correctly implemented connector rejects the mismatch. This depends on complete field coverage, correct canonicalization, trusted keys and enforcement on every permitted write path.

Evidence of control is not proof of judgment

The proposed construction can bind recorded identity evidence and an explicit approval to a particular payload, policy and authorization. Its assurance depends on identity validation, capture and connector enforcement. Cryptographic consistency does not independently prove that every recorded event occurred, that the human understood the action, or that the organization complied with applicable law.

Primary references

This is Nikxius’s technical synthesis of the original provider documentation, standards and official materials cited below. They support the specific mechanisms attributed to them; they do not endorse Nikxius or validate this conceptual construction. Living documentation may change after the stated review date.