The agent the capability is bound to — a cryptographic identity, not a self-declared name or prompt claim.
Methodology · HCAP
Hierarchical Capability & Attestation.
ABFP asks whether an agent is acting right. HCAP asks the prior question: was it ever allowed to? It makes delegated authority attenuable, walkable, and impossible to self-declare.
The gap
Authority that agents grant themselves.
When agent A delegates to agent B, two questions decide whether the system is safe: what is B actually allowed to do, and who said so. In most 2026 deployments the honest answer is B says so. Identity is asserted in a prompt or an unsigned card; the receiving agent is left to make the authorization call alone; and a delegation three hops deep has no record of where its authority came from.
The standards landscape is converging on the pieces but not the whole. Each addresses part of the problem and names the part it leaves open:
What no single piece provides is holder-attenuable, multi-hop delegation with provenance, spanning both the MCP tool surface and the A2A wire. That is the gap HCAP is built to close.
The capability
A token that can only ever shrink.
An HCAP capability is a signed, attenuable grant. Where a JWT is frozen at signing, a capability can be narrowed by its holder before being passed on — and never widened. Every field exists to make authority explicit and its provenance verifiable.
The exact actions and resources permitted. Expressed as an AuthZEN-style action/resource tuple so it drops into existing policy points.
A hash reference to the capability this one was derived from — the link that makes the delegation chain walkable and tamper-evident.
Each hop may only narrow authority, never widen it. A delegatee cannot grant what it was never given.
An N-of-M quorum of attesters signs the capability into existence. No single issuer is a single point of forgery.
Expiry, blast-radius class, and reversibility flag — the ambient context a policy point needs to size the risk of any one call.
Attestation
No single issuer to forge.
A self-signed identity is only as trustworthy as the one key behind it. HCAP anchors a capability with an N-of-M quorum of independent attesters — an identity authority, the delegating agent's owner, a policy service — so minting a valid capability requires compromising a threshold, not a single signer. The quorum set and its threshold travel with the capability, so any verifier can re-check the anchoring without trusting the presenter.
$ mst hcap verify --chain triage→remediation→billing.write [hop 1] triage ............ grant=read:* · quorum 2/3 ✓ [hop 2] remediation ....... attenuated → read:tickets ✓ [hop 3] billing.write ..... grant ⊄ parent — widened authority [ASI03] identity & privilege abuse · confused deputy chain rejected → out/chain.sarif
Hop 3 asks for billing.write while its parent only ever held read:tickets. Because authority can only attenuate, the request is provably outside the chain — a confused-deputy attack caught by arithmetic, not by guesswork.
Composition
Allowed, and acting like it.
HCAP and ABFP answer different halves of one question. HCAP is the static, provable half — this agent holds a valid, in-scope capability for this action. ABFP is the dynamic, behavioural half — this agent is acting within its baseline. A policy point in the AuthZEN mould can carry both in its context object: the capability chain as the authority, the ABFP deviation score as the ambient risk. An agent that is authorised but behaving anomalously, or behaving normally but reaching past its capability, fails the same check from opposite directions.