AI Agents Have Identities. What They Need Is Verifiable Authority.

This article turns a familiar distinction into a testable architecture. Its authority-evidence contract asks whether a verifier can establish the principal's right to delegate, the approved mandate, its scope and lifecycle, the asserted delegation path, the current actor's binding to the request, and the relationship between authorisation decisions and execution receipts.

The contract works with the security stack enterprises already operate. OAuth, IAM, workload identity, and capability systems establish actors and access rights, and enterprise policy decides what may happen at each action boundary. The Human Delegation Provenance Protocol (HDP) supplies the evidence binding: a portable, signed record that holds what the person asked for, in their own words where practical, and how each agent in the chain read that request. Helixar 360 makes the live decisions with the enterprise's own controls and writes each one into that record.

HDP is deliberately never the gate. Since revision -03 of its Internet-Draft, an HDP token must not be an input to any access decision. That rule is what keeps the record trustworthy. Any auditor with the issuer's public key can verify it years later, and it never becomes a second access control system for an attacker to work against.

The missing edge in an authenticated request

Imagine that product counsel approves an agent to review a defined set of vendor agreements for missing data-handling clauses. The agent calls an OCR service, then requests source documents from a contract repository. The repository sees a recognised workload, a valid access token, and a request the token permits.

What, exactly, has been established?

The unresolved question is whether trustworthy evidence binds that request to the approved review, the counsel's right to commission it, and an allowed path to the current agent. A second question sits behind it and usually goes unasked: did the agent's understanding of the task still match what counsel asked for by the time it reached the repository?

Helixar's earlier article, Why Identity Alone Cannot Govern AI Agents, establishes the broader distinction between identity and governance. Here the next step is concrete: define the evidence a verifier should demand and the edges it should refuse to infer.

The authority-evidence contract

An authority-evidence contract is a set of questions that an architecture must answer with trustworthy, machine-usable evidence. Enterprise systems contribute signed assertions, authorisation-server state, capability proofs, policy data, and linked audit records. The access-control layer uses those answers to decide. HDP keeps a signed account of the request and every hop beside them, so a reviewer can later test each answer against what the person actually asked for.

The first two questions are often collapsed. A signature can show that an issuer made a statement, while informed human approval and the principal's right over the target resource require separate evidence. Trusted issuance must connect organisational rights, the approval experience, and the signed artefact.

Across organisational boundaries, human-origin evidence and resource-owner authorisation are separate edges. A principal's approval has effect only within rights that the relevant resource owner recognises.

Think in graphs, verify at edges

Agent execution branches. One agent delegates research, another transforms data, and a third invokes a tool. The evidence model should make those relationships explicit without pretending that a signed record automatically captures every real-world branch.

The solid path is the evidence claim to be tested: the record asserts approval by a principal with the relevant mandate; recorded delegation connects that mandate to a current actor; the actor made a bound request; policy evaluated it; and a controlled component recorded the result. Signature validation alone does not establish informed approval or organisational authority.

The dotted edges matter just as much. The request must be tied to the same task and session. The execution record must be joinable to the approval and decision. Without those bindings, an investigator has a collection of individually plausible facts rather than an authority proof for one operation.

This graph also has meaningful negative space. If no edge connects the current actor to the mandate, the verifier should leave the path unresolved. If a delegation proof ends at agent B while agent C presents it, a valid prefix does not authorise C. If the action occurred outside the controlled execution path, the absence of a receipt is itself a finding, while remaining inconclusive about what happened elsewhere.

Graph semantics therefore require at least four predicates:

1. Authenticity: Was each retained assertion made by a trusted issuer or component?
2. Continuity: Do identifiers and parent relationships connect the asserted path without substitution?
3. Applicability: Does the mandate, as interpreted by policy, cover this exact actor, operation, resource, arguments, session, and time?
4. Coverage: Does the architecture have reason to believe every consequential path must produce the required evidence?

HDP cryptography establishes authenticity and continuity for the recorded delegation chain: every hop is signed over the hops before it, so an altered, reordered, or inserted hop fails verification. Helixar 360 makes applicability and coverage enforceable through governed issuance, shared policy semantics, trusted gateways, behavioural evaluation, credential controls, and independently generated receipts. The two halves meet in the record. Every decision Helixar 360 takes is appended to the same HDP chain that holds the original request, so a reviewer can check whether enforcement actually matched the mandate.

From “purpose” to enforceable predicates

A natural-language purpose can help a reviewer, while high-consequence authorisation needs more precise predicates.

“Review vendor agreements for missing data-handling clauses” leaves important questions open. Which agreements? May the agent only read and classify, or also contact a supplier? May documents leave the legal environment? May the agent delegate extraction to another model provider? What change requires renewed approval?

The mandate should separate a human-readable intent from machine-evaluable constraints:

RFC 9396 Rich Authorization Requests is an important corrective to the claim that OAuth can express only coarse string scopes. It defines structured authorization_details; a deployment can profile those details for a transaction or task. Capability systems can use caveats or logical checks to express restrictions. IAM and policy engines can evaluate attributes and relationships.

Systems can use different syntax while meeting the same requirement: the verifier must know which facts are trusted, how they map to an operation, and how ambiguity is handled. An agent's self-reported purpose remains untrusted until an authorised process binds it to the mandate.

The intent row deserves more weight than it usually gets. Each agent passes on its own reading of the task, and after a few hops an action can sit inside every constraint in the table and still be far from what counsel wanted. No access check catches that, because nothing was denied. The only place it shows is a record that keeps counsel's sentence next to each agent's reading of it, which is what HDP holds.

Request binding is where abstractions become controls

Mandate evidence that travels alongside a request is easy to treat as explanatory metadata. To function as a control input, it must be bound to the operation that will actually execute, and it must live in the access-control layer: in authorization_details, a capability caveat, or an approval record the policy engine trusts.

That binding should cover the current actor, intended resource server, task and session identifiers, operation name, security-relevant arguments, and an anti-replay condition. The verifier must also validate the resource-access credential on its own terms. A mandate complements the repository's access token, a cloud role, or a workload identity.

The final policy decision might be expressed as:

permit(request) only if authenticated_actor = delegated_actor AND resource_credential_allows(request) AND mandate_covers(request) AND lifecycle_state_is_fresh AND path_is_controlled

Each term hides deployment work. “Authenticated actor” may require sender-constrained credentials rather than a bearer token whose possession alone enables use. RFC 6750 defines bearer-token use; DPoP is one mechanism for binding token use to key possession. The business mandate still needs its own evidence. “Lifecycle state is fresh” may require introspection, status replication, or short validity periods. “Path is controlled” requires the system to prevent direct access that bypasses the policy enforcement point.

One term is absent from that expression on purpose: the HDP token. A service must not grant, refuse, or condition an action on the presence of an HDP token, on the outcome of verifying one, or on its contents. A missing or failing token is recorded as an audit finding. The reason is architectural. A check that can deny is an access control mechanism whatever it is called, and running a second one beside the system's own adds an independent way to attack it.

The policy result must then be bound to the execution. Otherwise an agent can obtain approval for one argument set and invoke another. A trusted gateway can generate a decision identifier, pass only the approved operation to the tool, and retain a receipt containing the decision, request digest, result status, the HDP record reference, and relevant evidence identifiers.

HDP turns the contract into portable evidence

Helixar pioneered Human Delegation Provenance as a concrete, open protocol for this contract. The Human Delegation Provenance Protocol draft-03 defines a token that binds a principal and their request to a declared scope fixed after issuance, and records the session. As the work moves, the token accumulates an issuer-attested hop for each agent, stating how that agent read the task it was given. Any auditor can verify the whole record offline with nothing but the issuer's Ed25519 public key, on the day it was written or years later, without the operator's cooperation.

Three properties make that record worth carrying. It is portable: the same record follows the work across agent frameworks, model providers, and organisational boundaries, and on deployments that already use UCAN the same content can travel inside the capability certificates' own signed metadata, with a ZCAP-LD form proposed for review. It is independent of agent narration: the draft recommends that a component outside the agent's control, such as a tool gateway, record each hop, so the record does not depend on the agent describing itself honestly. And it fixes accountability where recording stops: if a chain reaches the depth its issuer set, the agent at the last recorded hop answers for everything delegated beyond it. Article 2 in this series, HDP: The Binding Layer for AI Agent Governance, shows how that record works with identity, access, policy, enforcement, and audit controls.

HDP connects the existing control stack

OAuth, capability proofs, IAM records, policy decisions, and signed logs remain essential. Each provides a strong answer at its own layer. HDP connects those answers to the human-approved request, so a reviewer does not have to reconstruct the mandate from platform-specific records or infer purpose from a credential.

In a Helixar implementation, Helixar 360 evaluates each governed request against the authenticated actor, the resource credential, current enterprise policy, the mandate as that policy holds it, and the proposed behaviour, then applies the configured response: observe, alert, require approval, block, or contain. Because Helixar 360 sits outside the agent at that boundary, it is also the component that records the hop. The action, including a blocked or attempted one, is appended to the task's HDP record, and the HDP reference goes into the tamper-evident decision receipt. HDP is what binds the identity, policy, behaviour, and evidence layers into one reviewable authority case.

Design for evidence before the incident

Authority evidence is often treated as an audit concern, something to reconstruct after an agent does harm. The contract is most useful when it is designed in before execution.

A high-consequence tool boundary should require both ordinary access authorisation and task-specific mandate evidence held by the access-control layer. It should resolve ambiguous scope conservatively, retrieve fresh lifecycle state where the risk warrants it, issue an independently generated decision receipt, and append the action to the HDP record. The same identifiers then support investigation, compliance testing, and reauthorisation.

This changes the review question from “Which account called the API?” to “Which authenticated actor requested this operation, under which policy-accepted mandate, through which issuer-attested or otherwise verified path, against which policy and state, what did the controlled executor do, and how far had the task drifted from what the person asked for?”

The answer spans identity, authorisation, provenance, policy, runtime, and evidence systems. HDP supplies the signed record that joins those systems around the original request, while Helixar 360 makes the live policy decisions, applies behavioural enforcement, and writes each decision into that record.

The third article in this series, The Hugging Face Incident Through an Authority-Evidence Lens, applies this contract to later reporting on the OpenAI evaluation and Hugging Face intrusion. The case shows why an identifiable agent, a usable credential, and an observed collaboration path should never be assumed to form a legitimate authority chain.