Identity · · 3 min read
Identity is not permission.
An agent arrives with a valid signature. What do you know? You know that a key signed a particular message. You have not yet established who controls the key, whether its authority is current, or whether the requested action falls within that authority. Building an accountable agent system means preserving those distinctions all the way through the interaction.
Start with a recognizable participant
OAS uses decentralized identifiers to describe participants such as agents, people, organizations, tools, and services. An identity document provides context around the identifier and its controlling keys. Sigil can anchor supported identity records so another participant has a shared reference when it needs to inspect a signer.
That is useful even when an agent changes its model or moves between hosts. The identity refers to a participant in the system, rather than one process instance or one language-model session. An application can carry the same identifier through a conversation, a work request, and a settlement record without pretending those are the same operation.
Follow the relationship behind the key
Lineage adds a relationship: an entity has a parent, and that relationship leads toward an appropriate root. Sigil’s Global Anchor Layer defines typed records for human, threshold-controlled, and enterprise roots, along with organizational lineage commitments. A verifier can use those records to examine the authority claimed by an agent.
The verification rules are more specific than drawing a line between two boxes. They include checking revocation, resolving a relevant root anchor, checking the document commitment, verifying the parent signature, and, for organizational entities, checking the required inclusion proof. An attractive lineage diagram should explain those responsibilities without replacing them.
Make a separate authorization decision
A verified relationship does not mean an agent may do everything its parent can do. Authorization still needs a resource, an action, and a policy. A reporting agent might be allowed to read a dataset while being unable to send money. The policy must describe that distinction where access is actually enforced.
Capability systems such as Arsenal operate around external credentials and service access. Sigil’s mandate design describes bounded delegation at a different boundary. An integration must check the supported transaction surface and activation state rather than assume that a type in a specification means every lifecycle operation is enabled on its selected network.
Treat authority as something that can change
Keys rotate. Roles change. A relationship can be revoked. Caching an earlier success indefinitely can turn a correct identity check into an incorrect authorization decision later. The application needs a deliberate freshness policy and a clear response when the relevant authority can no longer be established.
The useful outcome is a decision with an understandable basis: this participant requested this action, the required relationship was verified, the permission covered the request, and the checks were current enough for the application. Identity gives that decision a subject. It does not eliminate the decision itself.