The Agent Trust Profile: Verifiable Authority for Autonomous Agents

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 20 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

An agent request today typically carries a bearer token. A relying party can conclude "this credential is valid" but not "this specific agent, acting for this principal, holds delegated authority for this action under these limits, and that authority has not been revoked". The profile fills that gap with verifiable objects layered on existing standards. Conformance is defined by executable vectors (Section 12).¶

2. Model

3. Agent Identity

An agent identifier MUST be URI-safe, stable, non-secret and unique within its organization. SPIFFE IDs [SPIFFE], DIDs, OIDC subjects and organization-specific URIs are acceptable. Lifecycle states are pending, active, suspended, revoked, retired; only active agents may be authorized. Credentials bind a public JWK to the agent (kid, not_before, not_after, issuer, status). Issuer-signed identity tokens ([RFC7519] JWT-SVIDs, IdP JWTs) MAY be presented in the Agent-Credential header and validated against configured trust anchors (OIDC issuers via discovery JWKS; SPIFFE trust domains via their bundle endpoint); a valid presented token MAY stand in for a registered key.¶

4. Principal Binding

Every agent SHOULD carry an owner principal. Verifiers MUST report the principal as separate evidence and MUST NOT conflate agent and principal.¶

5. Capabilities, Constraints and Attenuation

action is exact; resource is exact or a trailing-* prefix. Constraint keys defined here: max_value and max_total (numbers), currency (ISO 4217), region (list). A child capability is covered by a parent when actions are equal, the parent resource contains the child resource, and the child constraints are tighter (max_value/max_total not greater; region a subset; other keys equal). Delegation MUST refuse anything wider (exceeds_parent). max_total denotes a lifetime budget across allowed requests.¶

6. Delegation Credential

Type agent-trust-delegation+jwt. Claims: iss (organization), sub (subject agent), jti (delegation id), iat, optional nbf/exp, and atp with v (1), issuer ({type, id}), capabilities, constraints, effective, parent, parent_hash (base64url SHA-256 of the parent JWS), depth, task. A chain root MUST be issued by a principal at depth 0; each child MUST be issued by the parent's subject, reference its parent by jti and parent_hash, increment depth, and satisfy capabilities ⊆ parent effective with effective = attenuate(parent effective, capabilities). Chains MUST NOT exceed depth 8.¶

7. Request Proof of Possession

A detached JWS of type agent-trust-proof+jwt in the Agent-Proof header, modelled on DPoP [RFC9449]: iss (agent), htm, htu (scheme and host lower-cased, no query or fragment), iat, exp, jti, rh (base64url SHA-256 of the exact request body). Verifiers MUST check the signature against the credential named by kid, htm, htu, rh, expiry and skew, and SHOULD reject replayed jti values.¶

8. Authorization

Authority is checked first and is default-deny; policy narrows. A policy document {version: 1, default?, rules[]} with rules {id, match?, conditions?, effect} fires every rule whose match and conditions hold; precedence is deny > require_approval > allow; the document default applies when nothing fires. Conditions: amount_lte, amount_gt, currency_in, region_in, requires_attestation, missing_attestation, delegation_depth_lte, delegation_depth_gt, time_window. Evaluation MUST be deterministic. A policy decision point exposing this evaluation SHOULD implement the AuthZEN evaluation request [AUTHZEN]. Human approval is a first-class signed object (agent-trust-approval+jwt) bound to the decision's request hash.¶

9. Authorization Attestation

Type agent-trust-attestation+jwt, short-lived, issued by the organization from an ALLOW decision or an approved REQUIRE_APPROVAL decision: iss, sub (agent), jti, iat, exp, optional aud, and atp with principal, organization, action, resource, decision, capabilities (effective), delegation_chain, human_approval, decision_id, request_hash, policy_version. A relying party MUST verify signature, type, expiry, subject, action and resource coverage, and SHOULD check revocation by jti.¶

10. Provenance

Each consequential event is a CloudEvents-shaped [CLOUDEVENTS] envelope hash-chained per organization (prev_hash, hash = SHA-256(JCS(envelope))), signed with the organization key (es256:<kid>:<sig>) or an HMAC. Stores MUST be append-only. A signed ledger-head checkpoint (agent-trust-ledger-head+jwt) enables external anchoring.¶

11. Revocation

Subjects: agent, credential, delegation, attestation, policy version. Revoking any link of a delegation chain invalidates every descendant at verification time. Short-lived credentials plus an indexed status lookup are RECOMMENDED.¶

12. Federation

Organizations publish an entity configuration (keys, endpoints, authority_hints) and MAY act as anchors publishing signed subordinate statements (entity-statement+jwt), following the shape of OpenID Federation [OIDFED]. Trust level 1 recognises an organization; level 2 permits its attested agents to act under the relying organization's policy. Peer revocation lists are not consulted in this version; attestation lifetimes bound the exposure.¶

13. Conformance

Three levels: Level 1 Verifier (decision vectors), Level 2 Credentials (signed-object vectors), Level 3 Federation. An implementation claims a level only when every vector of that level and all lower levels is reproduced.¶

14. Security Considerations

The model is not trusted: an agent's proposal never carries authority by itself. Replay of request proofs is bounded by jti tracking and short lifetimes. Attestations are short-lived because peer revocation is not consulted across organizations. Budget enforcement requires the ledger; snapshot-based verifiers MUST flag decisions taken without it. Debuggable enclaves MUST NOT yield verified TEE attestations.¶

15. IANA Considerations

This document requests registration of the media types application/agent-trust-proof+jwt, application/agent-trust-delegation+jwt, application/agent-trust-attestation+jwt, application/agent-trust-approval+jwt and application/agent-trust-ledger-head+jwt in the "Media Types" registry, and of the HTTP header fields Agent-Proof, Agent-Credential and Agent-Attestation in the "Hypertext Transfer Protocol (HTTP) Field Name Registry".¶

16. References

Appendix A. Acknowledgements

The profile builds on the work of the IETF WIMSE and OAuth working groups, the OpenID Foundation AuthZEN and Federation working groups, the SPIFFE project, and the Model Context Protocol and Agent-to-Agent communities.¶

Author's Address