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. The Human Delegation Provenance Protocol (HDP) supplies the binding layer: a portable, signed chain connecting the human mandate to downstream agent actions. Helixar 360 uses that chain as live policy and enforcement context wherever consequential actions are decided.

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.

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. HDP provides the common protocol that binds those answers to the human mandate and carries them through the agent chain.

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. Helixar 360 supplies the surrounding operating controls: governed issuance, shared policy semantics, trusted gateways, behavioural evaluation, credential controls, and independently generated receipts. Together they make applicability and coverage enforceable rather than leaving the signed mandate as passive metadata.

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.

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.

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.

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, 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-01 defines a token that binds a principal to root-level scope fixed after issuance, session and validity data, and an issuer-attested sequence of delegation hops. Every verifier receives the same portable authority context, even when the request crosses agent frameworks or infrastructure boundaries. Article 2 in this series, HDP: The Binding Layer for AI Agent Governance, shows how that binding 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 mandate so a downstream control point does not have to reconstruct authority from platform-specific records or infer purpose from a credential.

In a Helixar implementation, Helixar 360 verifies the HDP chain, resolves its signed scope against current enterprise policy, evaluates the proposed behaviour, and applies the configured response: observe, alert, require approval, block, or contain. The same decision and HDP identifiers flow into a tamper-evident audit trail. 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 before execution.

A high-consequence tool boundary should require both ordinary access authorisation and task-specific mandate evidence. It should resolve ambiguous scope conservatively, retrieve fresh lifecycle state where the risk warrants it, and issue an independently generated decision receipt. 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, and what did the controlled executor do?”

The answer spans identity, authorisation, provenance, policy, runtime, and evidence systems. HDP supplies the common authority chain that joins those systems, while Helixar 360 turns that chain into live policy decisions, behavioural enforcement, and audit-ready evidence.

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.