Skip to main content
Identities establish stable subjects for an Aion’s public presence, internal work, and external network accounts. An Identity can remain stable while the Ions, Sequences, and runtime configuration around it change. Agent Identity records share one durable shape, but their immutable type determines how each record can be used.

​
Three identity records

These records answer different questions:
  • Aion Identity: Which Aion does this network endpoint represent?
  • Daemon Identity: Which configured runtime is acting inside the application?
  • Linked service identity: Which external account should this integration use?

​
Aion identities

A Personal or Principal Identity can root an Aion. It can appear in the Aion Catalog as a durable address before any Behavior or Distribution Ion is attached. When that Identity is assigned as a Distribution’s Principal Identity, it serves as the Aion Identity on that network. Reusing the same principal on another Distribution makes the same Aion reachable through another network.

​
One Aion Identity, many Distributions

The Identity—not the Project—is the invariant. In this example, @support represents one Aion across Slack, X, and Voice. Each linked service account authenticates its Distribution, and each Distribution points to the same Aion Identity. A Principal Identity is optional for most Distributions; an active Playground Distribution requires one. Without a principal, the Distribution is not mapped to an Aion Identity.

​
Daemon identities

A Daemon Identity is the identity a configured Ion runtime uses when it acts inside an application. It is bound to an Ion’s runtime configuration, has the immutable type Daemon, and serves as that runtime’s principal. One Daemon Identity can be bound to only one active configured runtime. A runtime acts under its Daemon Identity when it:
  • calls another Aion or application component
  • accesses MCP tools, resources, or other internal systems
  • invokes models or other metered services
  • publishes, subscribes to, or processes internal events

​
Permissions, billing, and attribution

Aion uses the Daemon Identity to determine what the runtime may do and to record which runtime performed the work. Roles and permissions are evaluated against that Identity for actions such as using capabilities and invoking models. See Roles & Permissions for how a role’s permissions and reach determine which resources that Identity can use. Metered usage carries the acting principal and its billing organization, so model and capability usage can be attributed to the Daemon Identity. Audit and trace data can use the same principal to identify the runtime that initiated the work.

​
Project and environment boundaries

Most Daemon Identities use Aion’s Project Agent role. Its capability access is scoped to the Project containing the configured Ion. The runtime can discover and use eligible resources in that Project, such as MCP-capable Ions, because they share the same Project definition. Individual capabilities must still be enabled and permitted. An organization-wide role can extend capability discovery to other Projects in the same organization. Aion still matches the source Project’s environment name, keeping production, development, and other environments separate. For example, runtimes in two Projects whose environment name is Production can discover eligible resources in each other’s Projects when their Daemon Identities have organization-wide access. A runtime in a Production environment does not discover resources from a Development environment through that search. See MCP Servers for detailed discovery and authorization rules.

​
Internal identity, not public ingress

A Daemon Identity supports authenticated communication and resource use within the application. It is not the public network identity that outside clients use to reach an Aion. External traffic enters through a Distribution. The identities remain separate:
  • The Aion Identity tells a Distribution which Aion it represents.
  • The linked service identity authenticates the external account carrying network traffic.
  • The Daemon Identity identifies the configured runtime when it performs work inside the application.
Authenticated internal A2A automation can target the configured runtime bound to a Daemon Identity. That path is for communication within the application; it does not replace the Distribution used for public ingress.

​
Agent Cards and identities

An Agent Card describes one addressable A2A surface:
  • A public Distribution card describes an A2A Distribution and its connected Sequence.
  • A component Agent Card describes the capabilities available to authenticated internal automation.
A configured Ion can have both cards when it participates in a public A2A Distribution and supports internal daemon communication. The component card does not make the Daemon Identity a public endpoint; outside clients still enter through the Distribution. See Ions, Behavior Ions, and Distribution Ions for the surrounding model.