Rust SDK
Source and runnable examples are in the aep-rust GitHub repository. Each of the six published crates links to its crates.io page below. AEP integration does not require an InFlow account.
Choose crates for your role
The workspace contains separate crates for protocol contracts, Agent behavior, Service behavior, and hosted identity. Tower and Axum are optional ways to connect the Service to HTTP; the Service crate remains usable without either. Add only the crates whose public APIs your application uses.
| Crate | Use it for |
|---|---|
| aep-core | Protocol models, validation, identity, and assertion primitives. |
| aep-agent | Inspect, Enroll, Status, Grant, Revoke, credential handling, and protected-resource authentication as an Agent. |
| aep-service | Inspect publication, command handling, assertion verification, enrollment, and resource authentication. |
| aep-tower | Reusable AEP command service and authentication layer for Tower-compatible HTTP stacks. |
| aep-axum | Direct Axum routing and an authenticated Agent principal extractor. |
| aep-platform | Optional hosted Agent identity provisioning, delegated signing, and lifecycle operations. |
Install matching crate versions
Rust 1.88 or newer is required. The crates share a release version; these Cargo.toml excerpts show an Agent application and, separately, an Axum Service. They are alternatives, not two dependency sections to paste into one file. Add aep-core explicitly only when your code names its models or cryptographic types.
# Agent application [dependencies] aep-agent = "0.1" # Axum Service application [dependencies] aep-service = "0.1" aep-axum = "0.1"
An application using Tower instead of Axum adds aep-service and aep-tower. A different HTTP stack can integrate directly with aep-service. The public asynchronous interfaces are runtime-independent, but the default HTTP transport uses Reqwest and requires Tokio. Applications using another runtime can supply their own transport.
Give an Agent a Service-scoped identity
aep-agent creates a Client from an application-supplied IdentityProvider. Its Service sessions inspect advertised capabilities, enroll with the requested Claims, check Status, and may obtain an advertised credential through Grant. Pending enrollment needs a Status check or wait_for_active before the application assumes access. The Agent crate guide explains the API and optional hosted identity provider.
For protected resources, the Agent chooses among methods the Service advertises; it does not infer that AEP client assertions are acceptable merely because AEP commands use them. Its default identity and credential stores are process-local. Replace them when identities or secrets must survive a restart, and protect secret-bearing records under your application's access-control and encryption policy. The local lifecycle example shows Inspect through targeted Revoke and a JWT fallback with real assertions.
Configure a Service before connecting HTTP
aep-service configures the Service DID, assertion verifier, enrollment policy, Claims, and optional Grant Types. Its default Inspect, Enroll, and Status implementation uses in-memory stores for examples. To issue a credential, register a GrantTypeDefinition and GrantTypeHandler; do not assume a built-in credential profile is installed. The Service crate guide gives the framework-neutral contract.
The Service checks a client assertion's audience, operation, resource, lifetime, and replay after verifying its signature. Production deployments replace enrollment, replay, idempotency, and credential stores with durable implementations that coordinate concurrent requests. Application authorization remains separate from successful Agent authentication.
Choose direct HTTP integration, Tower, or Axum
For another HTTP stack, map the Service's Inspect document and authenticated commands to your router, pass assertions and idempotency keys without logging them, and return its typed ServiceResponse. aep-tower instead supplies a reusable command service and authentication layer. aep-axum mounts those routes for Axum and exposes an AepPrincipal to protected handlers. The adapters may be used separately; neither is a prerequisite for the Service crate.
The Axum Service example mounts all AEP commands and protects an application resource. Apply its authentication layer only to protected routes; a public Inspect request and the authenticated AEP commands follow their own protocol rules. For a non-Axum stack, start with the Tower adapter guide or the Service crate directly.
Keep hosted identity optional
An Agent that delegates identity custody uses PlatformIdentityProvider from aep-agent. An application operating a Platform uses aep-platform and supplies caller authorization, Service DID resolution, identity storage, and key custody. Those are different integration roles. The ephemeral Platform example demonstrates provisioning and signing with development-only stores and policy; production keys and identities require protected, durable custody.
