The Agent Has Authority. ChainIT Asks Whether the Grantor Did, and Whether the Payment Still Matches What Was Approved.

ChainIT published Provable Authority on 1 September 2026, a technical white paper introducing a ChainIT Authority Protocol and an Agent Subject Profile, distributed a day later through PR Newswire. Moona Intelligence verifies it now against the same standard applied to every proposed agent authority architecture in this corpus: what does the evidence actually establish about where an agent's authority came from, and what does it leave open.

Four states, kept separate: authentication, delegated authority, proposal activity, final execution

ChainIT's chief technology officer, Matt Koepp, is quoted in the announcement describing the technical breakthrough as the separation of authentication, delegated authority, proposal activity and final execution. This record treats that as the framework's own organizing claim and keeps the four states apart rather than reading any one as evidence of another. Identity and authentication establish who is acting. Delegated authority establishes what an organization's own governance says that actor may do. Proposal activity is an agent, workflow or person proposing an action. Final execution is the action actually happening, and ChainIT's own material states this is the point deterministic controls evaluate, returning Allow, Step Up, Hold, Reject or Prohibit before consequence follows rather than after. ChainIT positions Provable Authority as addressing two distinct problems at once: a longstanding business authority problem, whether an employee, owner or representative was actually authorized to take a specific action, and an emerging agentic authority problem, the same question asked of a workflow or an autonomous AI agent acting on an organization's behalf.

What already existed, and what is new

Provable Authority is not ChainIT's first product in this space, and this record separates the two layers throughout the way it separates vLEI's ISO standardized identity layer from GLEIF's newer agent mandate proposal. ChainIT Org ID and ChainIT ID, its business verification and individual identity verification products, are existing, documented infrastructure, corroborated across ChainIT's own product pages as consistently described. So is the Authority Resolution Pactvera, ARP, and the underlying Pactvera execution workflow, both covered by dedicated ChainIT support documentation this record cites below. The ChainIT Authority Protocol and the Agent Subject Profile are the newer layer the white paper introduces, extending that existing organizational and individual identity foundation toward a named protocol and a defined subject type for autonomous agents specifically. This record does not credit the newer layer with the older layer's maturity, and does not describe the ChainIT Authority Protocol as itself independently reviewed, publicly specified, or reference implemented on anything this session could verify.

Roles by themselves are not enough: the ARP model

ChainIT's own organizational authority documentation, as corroborated through repeated search passes, states directly that roles by themselves are not enough, that authority must be explicitly attested, tokenized and enforced, and describes an Authority Resolution Pactvera as an immutable record of who may act for an organization, for what purpose, and at what point in time. That is a genuinely more explicit doctrine than most agent authority architectures in this dataset state about their own organizational layer. ChainIT's model combines verified organizational identity through KYB, verified individuals through ChainIT ID, defined roles and groups, and the ARP itself as the artifact resolving role assignment into an attested authority grant.

ChainIT's separate Pactvera documentation, describing what happens after a Pactvera is sent, states that access to an organization or a Pactvera does not automatically authorize every action, and that a user must possess the authority the assigned task actually requires. Read together with the ARP model, this reads as a deliberate rejection of the failure this corpus already names as claimed authorization accepted without verification: a role, an account, or a signed document is treated here as necessary but not sufficient, with the ARP standing as the artifact that is supposed to close the gap. Whether it closes the gap in every deployment, rather than in the cases ChainIT's own material describes, is not established by anything this record could independently confirm.

Delegation to an Agent Subject: what is named, and what is not shown

The Agent Subject Profile is ChainIT's name for how an autonomous agent enters this model as a distinct kind of subject alongside a human, an organization or a workflow. ChainIT's own material, as corroborated through search, describes the profile as connecting verified identity, organizational authority, delegated scope, sourced evidence, deterministic controls, transaction capacity and exact instruction approval. What this record could not confirm is the profile's field level structure: whether an Agent Subject carries an independent cryptographic identity distinct from its parent human or organization, how a session identity relates to that subject, and whether the scope an Agent Subject receives is enforced as a verifiable subset of its human or organizational grantor's own authority or is simply asserted alongside it. This record does not assume attenuation, a delegated grant narrowed to no more than its parent's own scope, unless a mechanism enforcing it is shown, and none was found in material available to this session.

The canonical transaction digest: exact effect binding

This is the half of ChainIT's claim least comparable to the rest of this dataset. ChainIT's own material, as corroborated across search, describes a canonical transaction digest binding the payer, the payee, the destination, the amount, the currency or asset, the payment rail and other material terms to both the approval of a transaction and its execution. Framed against the central question this record applies to every such claim, whether a system can prove that the transaction which executed is the same transaction that was authorized, this is a more specific, more checkable design than a generic approved diff or an unbound sign off. It is also, on anything this session could independently verify, a claim rather than a demonstrated mechanism. No canonicalization algorithm, no serialization format, no statement of which fields are mandatory versus optional, and no independent test of the digest against a live or reference transaction appears in material available to this record. This record does not credit ChainIT with cryptographically exact effect binding on the strength of the digest's stated field list alone.

Alongside the digest, ChainIT's material describes scoped session credentials and a single use execution authorization, intended so that an authorization consumed once cannot execute a second time and a stale instruction cannot ride on an authorization it no longer matches. Whether that consumption is atomic under a retried or concurrent request, what happens to an issued but unused authorization when the underlying delegation is revoked before it is spent, and what a replay attempt actually encounters, are not established by anything this session could independently confirm. This record does not infer perfect replay prevention from the phrase single use alone, the same caution it applies to every vendor's own naming of its own control.

Deterministic outcomes: Allow, Step Up, Hold, Reject, Prohibit

ChainIT's own material names five outcomes a deterministic, pre execution control can return: Allow, Step Up, Hold, Reject or Prohibit. This record does not map these onto any other vendor's own terminology, and does not assume Reject and Prohibit carry distinct canonical meanings, that Hold creates a persistent pending action rather than a synchronous pause, or what a Step Up outcome specifically requests, whether a fresh authentication, a second approver, or additional evidence, beyond what ChainIT's own material states in general terms. Versioned authority policies and sourced evidence are named as inputs to these outcomes, corroborated through search as ChainIT's own language, without a confirmed statement of exactly what sourced means for a given evidence type or how a policy version is bound to the decision it produced.

Commit time revalidation, and how close it sits to the consequence

ChainIT's platform level material, as corroborated here, states that a role, a delegation, a business standing or a signatory authority can expire, revoke, narrow or become invalid, and that commit time revalidation checks current identity, authority, lifecycle, delegation and revocation state before consequence follows. That is a stronger design principle than a check performed once when a session opens. It is a check performed before commit, not the same fact as a guarantee that the resulting effect cannot mutate after that check runs, and this record does not conflate the two. Nothing available to this session establishes how close ChainIT's own revalidation sits, in wall clock time or in architectural distance, to the actual payment, data, asset or contractual consequence it precedes, or what happens when state changes in the interval between a Pactvera's final check and the effect it authorizes.

The Authority Provenance ledger

This is the part a press release and a set of support pages are never built to state on their own, so Moona Intelligence separates it out deliberately, distinguishing what ChainIT's material establishes from what it leaves open.

Authority grantor. A named individual or organizational role, verified through ChainIT ID and ChainIT Org ID, with the resulting grant recorded in an Authority Resolution Pactvera. This is documented, and it rests on an existing, already running verification product rather than a fresh proposal.

Mandate or basis. This is where ChainIT's own material, as far as this record could verify it, stops. An ARP is stated to be an immutable record of who may act, for what purpose, and at what point in time. It is not documented, in anything this record could confirm, which ARPs are grounded in an authoritative government or state source, which rest on a shareholder attestation, and which rest on an organization's own internal, unverified determination. This record records mandate legitimacy as unknown at the level of a specific ARP's evidentiary basis, the same gap already documented for AIC, x401, Nuggets and GLEIF, rather than assuming ChainIT's attestation model closes it because the resulting record does not change afterward.

Delegated scope. Documented at the level of ChainIT's own named dimensions, organizational authority, delegated scope, transaction capacity and exact instruction approval, and undocumented at the level of a specific field schema this record could independently confirm. Whether an Agent Subject's scope is enforced as a verifiable subset of its grantor's own authority was not established.

Explicit limits. ChainIT's own material names transaction capacity and exact instruction approval as dimensions its deterministic controls evaluate, without this record confirming whether those limits are cryptographically bound to a session credential, evaluated by a policy engine at commit time, or both. Recorded as documented in principle and unconfirmed in mechanism.

Inherited assumptions. This record found no statement in ChainIT's own material claiming that possessing a ChainIT Org ID account, an ARP, or access to a Pactvera by itself authorizes every action available to it. ChainIT's Pactvera documentation states the opposite directly. This record does not extend that stated principle to a confirmed enforcement mechanism it could not independently verify.

Revocation or modification. ChainIT states that authority may expire, revoke, narrow or become invalid, and that commit time revalidation checks current identity, authority, lifecycle, delegation and revocation state before consequence. This record could not confirm propagation latency, whether an in flight transaction is affected by a revocation issued during it, or whether revoking an upstream ARP automatically invalidates an already issued Agent Subject credential or a single use execution authorization already outstanding, and records each as unknown.

Challenge authority. Undocumented at the level this record requires. This record searched for a formal channel by which a party other than the original grantor, an auditor, a resource owner, a regulator, can contest or invalidate an ARP already recorded, and found none in material available to it. This record does not treat ChainIT's own commit time revalidation as a challenge process; it is a check performed before a new consequence, not a channel for disputing a delegation already accepted.

Recovery. Undocumented. This record searched for a reversal, rollback, refund or compensation mechanism addressing a consequential action already executed under an authority later found illegitimate, and found none in material available to it. Deterministic pre execution controls, on ChainIT's own stated design, prevent a future action. Nothing found here says they reverse an effect that already occurred.

Provenance evidence quality. Layered, and this record does not collapse the layers into one claim that ChainIT's framework proves legitimate agent authority end to end. Organizational and individual identity, through ChainIT Org ID and ChainIT ID, is documented against an existing, running product. The ARP's own attestation discipline, roles alone are not enough, is a genuinely more explicit doctrine than most comparable architectures state, and is documented as a design principle. Its underlying evidentiary basis, which grants rest on an authoritative external source versus an internal attestation, is unconfirmed. Delegated scope and explicit limits are documented as named dimensions and unconfirmed as field level mechanisms. The canonical transaction digest and single use execution authorization are the most specific exact effect claims this record has verified in this corpus, and are also entirely vendor asserted, with no independently inspected canonicalization, serialization or atomic consumption behavior found. Revocation is documented as a design goal with an unconfirmed propagation mechanism. Challenge authority and recovery are both undocumented.

Where this sits against what Moona Intelligence has already verified

Draft wei aic identity cert 00 already owns a certificate based architecture where a certificate authority's own issuance policy decides whether a principal's certified authority was legitimate, left unconstrained by the draft itself. x401 already owns a generic, credential neutral HTTP mechanism verifying a human to an identity assurance standard without establishing that human's corporate or account holding entitlement. Nuggets' Authority Control Plane already owns a vendor enforcement layer that signs a receipt binding an action's exact parameters, hashed, without documenting how a grantor's own mandate was established. GLEIF's proposed partitioned authority architecture already owns an unusually mature, ISO standardized organizational identity foundation extended toward agent mandates, without a confirmed field level binding of that mandate to a specific transaction's exact terms. None of them, on the material this record could verify, combines what ChainIT's own material describes attempting at once: an explicit doctrine that a role alone is insufficient and an organizational grant must be attested, tokenized and enforced through an immutable record, together with a canonical transaction digest ChainIT says binds payer, payee, destination, amount, currency and payment rail to both approval and execution. That combination, upstream organizational mandate resolution joined to a named exact effect commit mechanism, is not owned by any existing canonical in this corpus without distorting what those records already established about their own, narrower architectures. That is why ChainIT gets its own record here rather than an addition to AIC, x401, Nuggets or GLEIF.

It is also why this record refuses to let that combination round up into more than ChainIT's own material, as corroborated here, actually claims. An organization can record, through an Authority Resolution Pactvera, an immutable statement of who may act, for what purpose, and for how long, a genuinely more explicit organizational authority artifact than most comparable architectures in this dataset produce. What that organization still cannot show, on anything this record could verify, is that the underlying grant was substantively correct rather than merely recorded, that an Agent Subject's delegated scope is enforced as a verifiable subset of its grantor's authority, that a single use execution authorization is consumed atomically under a retried or concurrent request, or that a canonical transaction digest is bound to approval and execution through a mechanism independent of ChainIT's own account of it. The agent has authority under ChainIT's design. Whether the grantor was entitled to grant it, and whether the transaction that executed is provably the one that was approved, are questions this record found ChainIT's own material, as far as it could verify it, still leaving to ChainIT's own attestation and to a relying party's trust in it, not yet to independently inspectable proof.