Google's ARD spec stops at the endpoint, before the agent proves which workload is calling

Start with what a consumer does under ARD. A publisher hosts a catalog on its own domain, describes its resources and attaches trust metadata; the consumer discovers a candidate, verifies the published information, then connects over the resource's native protocol ^[2]. All of that happens before invocation ^[3]. The resource still has to authenticate and authorize the caller, because verified discovery metadata is not a runtime access token ^[4].

ARD answers which domain claims a capability, where its endpoint and protocol description are, and what trust material the publisher provided ^[5]. It does not answer whether the calling process is the agent it claims to be, whether a user authorized the transaction, or whether the requested action is within policy ^[6].

Those unanswered questions have four different subjects. One agent action involves the operator who deploys the software, the running workload, the delegating user or system, and the resource owner that decides what the combination may do ^[7]. An API key collapses all four. It is usually an identity credential and a bearer permission compressed into one long-lived secret ^[8], and per the dev.to write-up it can leak from a log, an environment variable, a container image, or an agent transcript, after which whoever holds it inherits its authority ^[9]. The audit record then says only "the key did it", with the workload that ran and the authorizing user left out ^[10]. In my view the transcript is the leak surface teams have not yet written into a retention policy.

The July 2026 IETF Internet-Draft starts from the premise that agents are workloads, which should get cryptographic credentials at runtime, authenticate as themselves, carry delegated authority separately, and preserve both identities through the call chain ^[11]. In practice that means attesting the runtime and issuing a short-lived credential to the workload that passed attestation ^[12]. Issuance can be bound to the cluster, namespace, service account, image, execution environment, or deployment policy ^[13]. SPIFFE is the mature example the piece names. A workload gets a SPIFFE ID and a short-lived SVID, X.509 or JWT, through the Workload API, then uses that identity for mTLS or application-level auth without a long-lived secret shipped beside the code ^[14].

The layer count is where the framing needs care. The write-up names five layers: discovery, workload identity, HTTP request authentication, delegated user authority, and observability underneath all four ^[1][15]. The IETF draft's proposed architecture, as described, covers agent credentials, delegated user authority, workload identity, authorization and audit trails ^[16], which is four of those five, with discovery left to ARD ^[1]. So the two specs do not divide neatly into one layer each. The write-up does not give the draft's document number.

Both are moving. The ARD spec repository describes v0.91 as an evolving specification, and the advice in the piece is to version your catalogs and not treat today's fields as permanently fixed ^[17].

The observability requirement is a join across everything above it. An operator has to connect the discovery result, the workload credential, the user delegation, the authorization decision, the tool call and the final side effect. Without that the system is not meaningfully auditable, according to the write-up ^[18]. Nothing in a catalog entry or a workload credential produces that join for you; the logging that ties a tool call to what it changed is still local work. On the specs themselves the write-up is blunt: "Neither replaces OAuth. Neither makes a signed bot trustworthy." ^[19]