Resources

AEP Roadmap

Explore future directions and help identify the capabilities your application needs.

Where AEP is heading

AEP establishes how Agents identify themselves, enroll with Services, and obtain access. Future work explores how that relationship can support stronger evidence, more identity choices, privacy preferences, additional communication methods, and blockchain-native applications.

The topics below include proposed extensions and exploratory directions. They are presented to gather feedback and identify useful implementations, not as a release schedule. The published specifications describe what is supported today.

Ecosystem integrations

Agent-to-Agent identification

Explore mutual identification between Agents that collaborate directly. Short-lived interactions could establish who is participating without requiring every exchange to create a persistent Service enrollment.

This would address peer identification; it would not attempt to define the entire collaboration or task-execution protocol.

Edge, proxy, and CDN integration

Help infrastructure in front of a Service recognize authenticated Agent traffic and evaluate relevant evidence before forwarding requests. This could give legitimate Agents a clearer access path than relying exclusively on browser-oriented bot detection.

The design would distinguish evidence used by the edge from the identity and permissions required by the underlying Service.

Additional credentials and integration guidance

Support additional credential formats where applications have a concrete need, and document how identity providers, wallet software, verification providers, and other participants can integrate with AEP.

The goal is to reuse the systems applications already depend on while making their AEP behavior interoperable.

Blockchain-native Agents

Account abstraction

Allow smart-contract accounts to participate as AEP Agent identities. Their configured signing and authorization rules could establish who is permitted to act for the Agent, connecting AEP to programmable wallet infrastructure.

This direction focuses on identity and verification. It can support both conventional Service integrations and broader on-chain designs.

Blockchain profiles and on-chain onboarding

Explore how blockchain infrastructure can support Agent identity, enrollment, and verification. Combined with an on-chain ODP representation, this could enable Agents to discover Offerings and onboard with Services fully on-chain.

That broader direction would require explicit designs for discovery, enrollment state, contract interactions, and privacy. Wallet-based identity is one building block; it does not, by itself, move discovery or enrollment on-chain.

Identity and trust

Self-custodied and wallet-based identities

Expand identity choices beyond did:web so Agents can identify themselves using keys they control directly or identities associated with wallets. This could let a developer operate an Agent without hosting its identity document on a web domain and connect AEP to the wider ecosystem of self-custodied wallets and signing tools.

The work would define how Services obtain the appropriate verification material and verify control of the identity. Controlling a wallet would establish identity control, not automatically grant access to a Service.

Verified claims and attestations

Allow Agents to present signed evidence from a verifier instead of relying only on self-declared information. A Service could evaluate who issued the evidence, which Agent or Owner it concerns, what was checked, and whether it remains valid.

Applications include evidence about an Agent's vendor, runtime environment, or Owner. Services would retain control over which verifiers they trust and what evidence their enrollment policies require.

Know Your Agent

Define common ways to communicate verification about an Agent and its Owner. A Service could request evidence that an Owner has been verified or that an Agent is controlled by that Owner, without inventing a separate claim format for every verification provider.

This would connect verification providers to AEP enrollment while keeping their verification procedures and the Service's acceptance decisions separate.

Zero-knowledge proofs

Let Agents prove a required property without disclosing the underlying information. Examples include proving that an Owner meets an age threshold without revealing their birth date, or proving membership in an approved group without revealing which member they are.

The work would cover how Services request proofs, how Agents present them, and how Services determine whether a proof satisfies their requirements. Different proof types could support different privacy and verification needs.

Agent lifecycle

Updates, key rotation, and decommissioning

Support maintenance of an Agent's relationship with a Service after enrollment. An Agent may need to update supplied information, replace a signing key, or explicitly retire its relationship with the Service.

These operations would provide clearer lifecycle behavior while preserving the Service's authority over access. They would not allow an Agent to undo a suspension or grant itself permissions.

Account maintenance and recovery

Describe how enrollment, credentials, changed requirements, and account closure fit together over time. This would help applications guide an Agent or its Owner through maintenance and recovery instead of treating each interruption as a new enrollment.

The work would also clarify what happens to associated credentials and retained information when a relationship ends.

Policies, privacy, and accountability

Service policy disclosure

Give Agents a structured way to understand relevant Service policies before enrolling. Disclosures could cover verification expectations, inactivity rules, retention periods, and references to terms and privacy information.

Making a policy discoverable helps an Agent or its Owner make an informed decision. It does not itself prove that a Service complies with that policy.

Privacy preferences and buyer consent

Let Services advertise the data-handling and communication choices they support and let Agents communicate their Owners' decisions. These could include permission for analytics, data sharing, or marketing by email or text message. Enrollment could make clear which preferences were accepted and which could not be accommodated.

The work would distinguish an explicit Owner decision from a Service-provided default and describe how choices can be updated or withdrawn. For example, an Owner could agree to receive order updates while declining promotional messages. An Agent would convey that decision rather than infer consent from enrollment or a purchase.

ODP purchase interactions could refer to these choices without defining a competing consent model. This would complement the Service's published policies; the Service would remain responsible for applying the choices and meeting its obligations.

Data residency and jurisdiction

Distinguish where information is stored or processed from where a Service is available. An Agent could evaluate both a Service's data-location disclosures and its geographic eligibility requirements before supplying information.

These are related but different questions: a Service may accept customers from one region while processing their information in another.

Audit history and export

Provide a portable way to retrieve relevant Service-side records of an Agent's interactions, such as enrollment and lifecycle changes. This could help Owners and developers investigate unexpected behavior and maintain records across integrations.

Services would continue to use their existing audit storage and retention policies.

Connections and notifications

MCP integration

Define how AEP enrollment and authentication can be used in MCP integrations. An Agent using MCP tools could discover the Service's requirements and establish access through a consistent enrollment process.

The work would clarify the relationship between AEP identity, enrollment, and the authentication mechanisms used by the MCP integration.

WebSocket connections

Support AEP interactions over persistent WebSocket connections for applications that already use long-lived, bidirectional communication. Agents and Services could maintain an ongoing connection while preserving AEP's authentication and lifecycle rules.

Server-sent events

Explore streaming Service updates to Agents over server-sent events. This could help applications receive progress or status changes without repeatedly requesting the same information.

The design would clarify how event delivery works alongside commands, authentication, and reconnection.

Webhooks

Allow Services to notify Agents when enrollment completes, requirements change, or other relevant lifecycle events occur. Applications that can receive callbacks could respond promptly instead of relying entirely on polling.

Status retrieval would remain important for applications that cannot receive callbacks or need to reconcile missed notifications.

Help shape AEP

Which of these capabilities would help your application? We welcome concrete use cases, implementation feedback, and collaboration from Service developers, Agent builders, wallet teams, verification providers, and infrastructure operators.

Tell us what you are building, what is missing, and which roadmap direction would make a practical difference.