Enrollment protocol
Agent Enrollment Protocol (AEP): Machine-First Agent Enrollment
Agent Enrollment Protocol (AEP) defines a machine-first way for an autonomous agent to discover a service's enrollment requirements, enroll a cryptographic identity, authenticate later requests and optionally obtain session credentials. It solves a different boundary from UHP harness execution.
Status first
Section titled “Status first”draft-kavian-agent-enrollment-protocol-04 is an active individual IETF Internet-Draft, not an RFC or an IETF-endorsed standard. Revision -04 was published 4 September 2026 and expires 8 March 2027 unless it is updated or replaced. The document header says “Intended status: Standards Track,” while the IETF Datatracker currently lists no RFC stream or intended RFC status and explicitly says the draft has no formal standing in the IETF standards process.
The durable idea is narrower than a general agent protocol: AEP defines an HTTP enrollment and authentication substrate for an autonomous Agent to become recognized by a Service. Its core scope is Inspect, Enroll, Status, Grant and Revoke. Payment settlement, checkout, application-action authorization, KYC execution and legal policy remain outside the core draft.
Why revision -04 matters
Section titled “Why revision -04 matters”Revision -04 makes the protocol’s compatibility model explicit. The Inspect document now carries aep_version in MAJOR.MINOR form, and this draft defines 1.0. A major version identifies the compatibility family; same-major minor revisions may add optional fields, values, capabilities or clarifications without removing or redefining existing wire behavior. Implementations must not infer optional capability support from the minor number alone.
That is meaningful interoperability work because the version advertised by the service becomes the protocol-version authority rather than an informal property of a particular document revision or media type.
Core flow
Section titled “Core flow”The baseline flow is intentionally small:
| Step | AEP operation | Purpose |
|---|---|---|
| 1 | GET /.well-known/aep — Inspect | Discover AEP version, supported commands, identity methods, requested claims, HTTP endpoint configuration, authentication methods, grant types and extensions. |
| 2 | POST .../enroll — Enroll | Present the Agent identity and requested claims and create or retrieve its enrollment record. |
| 3 | GET .../status — Status | Read the current lifecycle state, especially when enrollment or verification is pending. |
| 4 | POST .../grant — Grant | Optionally obtain a concrete session credential advertised by the Service. |
| 5 | POST .../revoke — Revoke | Revoke a credential, a grant type, or all supported session credentials according to the applicable grant profile. |
The command base is advertised by http.endpoint_base; when it is absent, the core draft defines /aep/ as the default. The HTTP binding uses HTTP/1.1, HTTP/2 or HTTP/3, requires TLS 1.3 or later for network use, uses application/aep+json for AEP JSON payloads and RFC 9457 Problem Details for errors.
Identity and baseline authentication
Section titled “Identity and baseline authentication”AEP uses a cryptographic Agent identity rather than a human registration flow. The core draft currently uses Decentralized Identifiers (DIDs) plus a per-request signed client-assertion JWT.
Authenticated AEP commands use:
Authorization: AEP <jwt>The assertion binds the Agent identity and Service audience to the requested operation. Its required claims include iss, sub, aud, op, iat, exp and a fresh replay identifier jti; protected-resource assertions additionally bind the target resource. The draft caps the assertion lifetime at 300 seconds and requires replay detection. Services implementing this version must support EdDSA and ES256 for Agent identity assertions and must not use none or symmetric JOSE algorithms for them.
Inspect itself is unauthenticated. Every Service exposing Enroll, Grant, Revoke or Status must continue to accept the baseline Authorization: AEP <jwt> form on those command endpoints even when optional session credentials are also supported.
Session credentials are optional, not the root of trust
Section titled “Session credentials are optional, not the root of trust”The Grant command lets an enrolled Agent ask for a concrete session credential. The core protocol does not define the credential formats itself; companion Internet-Drafts define profiles for familiar mechanisms including HTTP Basic, API keys and OAuth Bearer credentials.
This separation matters. A session credential is a convenience or compatibility credential issued after AEP authentication. It does not replace the baseline signed Agent assertion as the enrollment root of trust, and Grant/Revoke continue to use the baseline assertion.
The core also supports protected-resource authentication with either the normal Authorization field or, for AEP-recognized credentials, the dedicated AEP-Authorization carrier where the applicable method permits it. The dedicated field preserves the original scheme, such as AEP, Bearer or Basic, rather than inventing a second credential syntax.
Authentication is not application authorization
Section titled “Authentication is not application authorization”AEP draws a useful security boundary: successful protected-resource authentication establishes an Agent principal and credential metadata, but it does not authorize the requested application action. The protected application still evaluates its own resource policy and scopes.
That distinction prevents “valid Agent identity” from being silently promoted into “Agent may perform this operation.” It also makes AEP composable with an application protocol whose own objects, permissions and lifecycle rules remain separate.
Enrollment lifecycle
Section titled “Enrollment lifecycle”The Status/Enroll lifecycle vocabulary in revision -04 includes:
| State | Meaning in the draft |
|---|---|
active | Enrolled and operational. |
pending | Enrollment awaits asynchronous verification. |
unavailable | Temporarily unavailable for Service-defined non-punitive reasons. |
suspended | Temporarily disabled by Service action. |
terminated | Permanently de-registered. |
rejected | Asynchronous verification failed. |
AEP also separates submitted claims whose verification is still pending from requirements the Agent still has to satisfy. That is enrollment state, not a general task-execution state machine.
AEP and UHP solve different boundaries
Section titled “AEP and UHP solve different boundaries”| Dimension | Agent Enrollment Protocol -04 | UHP 2026-08-11 |
|---|---|---|
| Primary boundary | Autonomous Agent ↔ Service enrollment/authentication layer | Client ↔ UHP server ↔ selected complete harness |
| Main purpose | Discover requirements, enroll identity, authenticate, optionally bootstrap session credentials | Discover harnesses and execute/manage harness tasks, sessions, files and streams |
| Discovery | Service enrollment/authentication requirements at /.well-known/aep | UHP server/harness discovery and capability surfaces |
| Persistent identity | Agent DID and Service-local enrollment record | Authenticated UHP principal plus protocol objects; UHP does not define AEP enrollment |
| Task execution | Out of scope | Core protocol purpose |
| Session credentials | Optional Grant profiles | UHP authentication is a separate protocol concern; no AEP grant binding is defined |
| Application authorization | Explicitly separate from successful AEP authentication | UHP access control and per-principal object scoping remain within the UHP service boundary |
| Lifecycle | Enrollment identity states | Task/Response/session lifecycle |
| Standardized UHP binding | None verified | None defined for AEP |
The protocols could therefore compose without replacing each other. A service could, as an implementation choice, use an AEP enrollment/authentication layer before exposing some application API and separately expose UHP for harness execution. But no reviewed primary source defines a normative AEP↔UHP binding, a HarnessRouter AEP integration, or native AEP adoption by UHP/HarnessRouter.
What must not be inferred
Section titled “What must not be inferred”- An Internet-Draft is not an IETF standard or RFC.
- The draft’s internal
aep_version: "1.0"is a protocol-version field; it does not mean AEP is an IETF “1.0 standard.” - Enrollment or authentication does not by itself authorize application actions.
- AEP session-credential profiles do not turn Basic, API-key or OAuth mechanisms into UHP authentication requirements.
- The shared acronym does not connect Agent Enrollment Protocol to Agent Event Protocol.
- No native UHP adoption, HarnessRouter integration, production deployment or cross-protocol conformance is established by the reviewed sources.
Related pages
Section titled “Related pages”Read UHP architecture for the harness-execution boundary, UHP security for current UHP authentication and principal-scoping requirements, UHP vs Agent Event Protocol for the unrelated event-plane AEP, and UHP vs SAIP for a separate signed agent-identity proposal.