Over the last few years, much of B2B SaaS has outsourced identity to dedicated services. Hosted platforms such as Auth0 and WorkOS, and self-hosted servers such as Keycloak and FusionAuth, have earned adoption by handling the plumbing of authentication, SAML federation, and directory synchronization.
That is a useful division of labor. An identity provider helps answer who is this? But answering what may they do? requires rules that reflect the organization’s responsibilities and ways of working. Applying those rules may also require the record’s current state and other context.
The limits of front-door control
Consider a finance agent allowed to edit a draft invoice but not one that has been approved. A token can identify the agent and carry a broad invoice-editing scope. Before permitting a change, however, the system must also check the invoice’s current state—and any relevant limits on the agent’s authority.
A token’s claims describe what was asserted when the token was issued. They do not, by themselves, establish the current state of an invoice or capture every rule governing it. If the application relies on the user interface to enforce those rules, another client can bypass them. If checks are scattered across route handlers, they can drift or be missed.
What matters is that authorization is enforced consistently, using trustworthy and sufficiently current information, wherever a request comes from. To do that, a platform must be able to express the operational rules it governs: who can perform an action, on what, and under which conditions.
AI actors raise the stakes
Agents may connect through an API or MCP, or run on a schedule using a service identity. Like a browser, an agent is simply another client. But an autonomous agent can make many changes quickly, making gaps in server-side checks more consequential.
An agent may connect from outside the platform, but its identity, authority, and actions should be understood within it. For each action, the platform needs to know not just the caller's identity and broad scope, but whether this agent, perhaps acting for this person, may make this change to this record in its current state. It should also record the actor and the authority under which the action was taken.
Keeping authorization close to the domain
Fine-grained authorization services can help teams model and evaluate permissions. Some maintain relationship data separately; others evaluate contextual information supplied with a request. These approaches can be useful, but they introduce a design question: how does an authorization decision stay consistent with the business data and the change being made?
When permissions depend on changing workflow states or field values, duplicating that information across systems creates opportunities for drift. Even when current context is passed to a policy engine, the application must ensure that the decision remains valid when the change is applied. Centralizing rules does not remove the need to enforce them at the point of action.
The Engaging OS approach
Engaging OS uses Directus, part of its stack, to authenticate users. The platform then applies its own rules to determine what each user or agent may do with its data.
State-aware rules. Every permission is evaluated against the record’s current state and may also depend on other domain conditions. Permissions are evaluated within the transaction that applies a change, rather than relying solely on claims carried in a token.
One rulebook for every actor. People and AI agents, whether connected through MCP or running on a schedule, pass through the same permissions, workflows, and transactions.
One history. Changes made by people and agents are checked, applied, and recorded in the same place, with the actor and authority attached. This shared history makes it possible to trace what changed, who or what made the change, and under whose authority.
For an invoice, the platform checks that the invoice is in the required state and that any other conditions are met. An agent acting in a finance role might be permitted to approve a submitted invoice only if its amount is within the limit set for that position. Conditions can also draw on other information, including environmental factors. The goal is to keep the decision and the change together, so that the platform does not authorize an action based on an earlier view of the record.
An organization’s rules arise from its own structure and activities: who holds which responsibilities, what is being worked on, where that work stands, and what other conditions apply. An external service can help evaluate permissions, but it cannot originate those rules without the organization’s model being expressed to it.
It is the system that models the work that must be able to govern it. Identity can be delegated, but responsibility for access belongs with the operational system.