Aion Identity
Aion uses two record families:- An Agent Identity represents an agent inside Aion. Its immutable type is Personal, Principal, or Daemon. Personal identities represent Aion users; Principal identities represent an Aion’s outward presence; Daemon identities represent configured runtimes.
- A Service Identity represents an account on an external service, such as a Telegram bot, Slack account, or telephone number. The associated service connection supplies its credentials.
Principal Identity
The Principal Identity answers: Which Aion receives this request? An active Distribution requires one. A Daemon identity cannot occupy this field. Reusing the same principal across different distribution types makes the same Aion reachable across those networks. For example,@support can receive requests through Slack, X, and Voice. Each distribution uses its own service account
while representing the same Aion:
The receiving principal also owns that conversation’s contextual files. The
File Service explains when a runtime may act on those files.
Daemon Identity
The Daemon Identity answers: Which configured runtime is authorized to perform this operation? Assign a Daemon-typed Agent Identity to the runtime’s daemon field. Principal identities do not occupy daemon fields. Roles on that identity determine whether the runtime may invoke a model, call an MCP tool, send A2A requests, or use the File Service. Being an owner or receiving principal does not supply the executor’s action permissions. A deployment has its own daemon for direct SDK requests and autonomous calls to Aion. This avoids selecting an arbitrary behavior’s daemon when the request did not pass through a configured behavior Ion. A missing required daemon is a configuration error, not permission to act as the reported caller. See Roles & Permissions and Runtime callbacks for assignment and callback authorization.Service Identity
The Service Identity answers: Which external account carries this interaction? It connects a distribution to a provider account. It is not the person who sent a message to that account and is not the daemon that executes internal work. For example, a message from Bob to the@support Telegram bot involves three distinct subjects:
the bot’s Service Identity, the receiving @support Principal Identity, and Bob as the caller.
The runtime additionally has an executing Daemon Identity.
Request attribution
Aion records three roles plus the paying organization. They describe a request’s work; they are not interchangeable authorization credentials.
For a distribution request, the receiving principal and originator stay the same as execution moves downstream.
Each executing behavior uses its own daemon for permission checks. Model and MCP usage retain all three roles,
so work appears against the receiving agent even when a downstream daemon performs it.
Contextual File ownership follows the receiving agent too. An authorized SDK callback forwards signed usage attribution;
it does not substitute the executing daemon as the file owner. Storage billing uses the established payer.
See File Service for the separate rules for personal and service-account images.
When an Ion originates work without an incoming request, its daemon can supply agent and originator attribution as well
as execution. A direct deployment call uses the deployment daemon and deployment organization; a known reported caller
can still be the originator. Reported caller information is attribution, not independent authorization.
Scheduled work
A Cron attachment has an optional Principal Identity in its Identity tab. Set it to attribute scheduled work and contextual files to that principal. The same principal can serve multiple schedules. Without a selection, the attached target behavior’s daemon remains the agent principal. Cron inherits execution from the behavior it is attached to; it does not need a second Cron daemon. Selecting a receiving principal does not change execution permissions or payer, or authorize File updates on its behalf.Conversation ownership and caller access
A conversation belongs to its receiving agent in the relevant environment. Separate caller bindings identify who can retrieve it as a participant. A person having access to one conversation does not gain access to every conversation owned by that agent. File ownership is separate from these caller bindings. Deleting a conversation does not itself erase independently retained files or stop their storage charges.Resource discovery
For project-scoped and cross-project tool discovery, see Aion Meta Tools. Discovery scope does not replace execution permissions.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 card describes capabilities available to authenticated internal automation.