Most organizations treat identity as a door. Someone arrives, proves who they are, and is let in. After that, identity is finished and the applications take over.
That model was already strained when the only operators were people. It breaks once agents, services, and automations act too. Identity is not the door. It is the control point every later decision depends on.
Three questions, answered on every action
Identity has to answer more than "is this a valid user." It has to answer three things, continuously:
- Who or what is acting? A person, a service, or an agent—resolved to a specific identity, not to the fact that a token verified.
- In which context? Which organization and which workspace the action belongs to. The same identity may have different standing in each.
- With what authority? Which applications, resources, and actions are permitted right now.
An answer to the first question alone is a login. Answers to all three are operating infrastructure.
Sign-in is the smallest part
The visible parts of identity—the form, the provider button, the session—are the least interesting parts of it.
The load-bearing parts are elsewhere: how context is resolved and carried, where entitlement is decided, how access is revoked, and how an action is attributed after the fact. Those determine whether the platform can be governed. The sign-in screen only determines how a person begins.
Permissions are a platform decision, not a claim in a token
A token is evidence of authentication. It is a poor place to store authority.
Permissions embedded in a credential are a snapshot: they reflect what was true when the credential was issued, not what is true when the action runs. Access removed this morning should not still work this afternoon because a token has not expired. Authority has to be decided by the platform at the moment of the action, against current entitlement, in the active context.
That is also what makes revocation real rather than eventual—and revocation is the control that matters most when the operator is an agent running unattended.
The same boundary on every surface
Identity is only a control point if it holds everywhere. If the web application enforces one boundary and an API, a CLI, or an agent enforces another, the weakest surface is the real policy.
This is why Topolo puts one identity beneath every surface: one operating layer for people, agents, and the applications that run a business. One identity, shared context, governed action. The application a person opens, the action an agent invokes, and the command a developer runs resolve against the same identity, the same workspace context, and the same permission boundary.
Get identity right and the rest of the platform has somewhere to stand. Treat it as a login screen, and every control built above it is enforcing a boundary the platform cannot actually see.