Inside Opus · Part 7 of 13
This series follows a hypothetical supplier-invoice exception workflow. Part 2 showed a case waiting overnight for a reviewer with no worker held. This article asks what happens to permissions during that wait. Part 1, “A piece of work through Opus”, is the map.
Access changes while the case sleeps
An analyst in accounts payable starts the invoice case on Tuesday afternoon. The purchase order is missing, so the case is dispatched to a reviewer and hibernates. On Tuesday evening, the analyst moves to a different team and their access to the accounts-payable workspace is removed.
On Wednesday morning the reviewer approves the exception. The case resumes. The final Integration node needs to retrieve the invoice attachment from file storage and write the outcome to the finance system. Whose permission is being exercised?
If the answer is “a service account that can read every file and write to every system,” then the analyst’s revoked access changed nothing and the audit log will say the platform did it. If the answer is “the analyst who started the work,” the check has to happen again now, against current permissions, and it may fail.
Both answers are defensible, and each has its place. A narrowly scoped system identity is a legitimate pattern for background work that nobody owns personally. For sensitive actions on business data, Opus takes the second answer, because it keeps the permission decision and the audit record attached to the person whose work it is. That choice is what this article is about.
The requirement
Every sensitive action, wherever in the platform it happens and whenever it happens, must be evaluated against who is asking, what they are acting on, what they want to do, and the surrounding context. The evaluation must be consistent across services and must reflect changes in permission within a bounded time. And the decision must be logged so that the Wednesday-morning file read can be explained later.
That is the design requirement. Enforcement coverage and revocation timing need verification in the deployment being assessed. The audit records retained and their later availability depend on the applicable capture, access and retention settings.
This article is about authorization for actions that originate with a user, or with an agent acting for one. Controls between services are a subject of their own.
Identity is not permission
The first distinction is between authentication and authorization. A successful login through the customer’s identity provider establishes who the actor is. Opus federates with enterprise identity providers over standard protocols, and identity can also be an API key or an MCP client acting for a user.
Authorization is a different question, asked of a particular action: may this subject perform this action on this resource in this context? A valid identity is one input to that question, not the answer.
The inputs to a decision
Opus models authorization along four inputs.
The subject is the actor: a user, an agent, an API key or an internal service, together with the groups it belongs to and the roles it holds.
The resource is the protected object. This covers more than workflows: process discoveries, files, variables, credentials, agents, code, cases, traces, audit logs, policies, integrations and APIs are all resources with a consistent identity, owner, type, scope and sensitivity.
The action is what is requested: read, write, execute, create, delete, invite, export, approve or administer.
The context is the surrounding situation, including the runtime attributes of the request.
Resources are organized into access groups that mirror how the enterprise is structured: a required organization root, a central group, and then departments, teams, projects or private spaces. Roles package permissions into reusable profiles such as administrator, builder or reviewer. This is the attribute-based model, or ABAC. Role-based permissions live inside it; roles are one of the attributes evaluated, not a replacement for the evaluation.
Beyond the gateway
The obvious place to check permissions is at the front door: the API gateway, the web application’s backend, the MCP server, the collaboration connection. Opus checks there. The more important design decision is that it does not stop there.
The same decision function, delivered through an authorization library embedded in service middleware and backed by a central policy decision point, is applied at the collaboration service when someone joins a workflow room, at the execution manager when a case is initiated, at the workers when a node runs, at the file service when an attachment is read, at the inference service when a model is invoked, and at downstream APIs.
For the invoice case, that means the analyst’s right to start the workflow is checked at initiation, the reviewer’s right to act on the human task is checked at the review gateway, and the file read on Wednesday is checked at the file service.
Continuity across the wait
Now the opening question. When sensitive downstream execution happens, the requester’s authorization context travels with the work, and the services that perform the sensitive steps re-evaluate permission at the point of action. We call these critical-path rechecks.
For the Wednesday example, assume the revocation has taken effect at the file service. The final Integration node’s file read is evaluated in the analyst’s authorization context rather than against a blanket worker identity, and the revoked workspace access produces a refusal. The case handles it in the way the workflow designer chose: fail, route to review, or wait for someone with permission. Whether a deployment reaches that result within its required time bound depends on the freshness controls below.
This is what “authorization follows the work” means in practice. The decision is not made once at the gateway and assumed thereafter. It is remade at the points where the consequences are.
Caching against freshness
Rechecking everywhere has an obvious cost. An event-driven platform makes many small requests, and each check that goes back to the policy decision point adds latency and load.
Opus caches authorization outcomes and optimizes token refresh to reduce that traffic. The design aims to bound staleness while reducing repeated policy traffic. Cache expiry, revocation-driven invalidation and token refresh are deployment controls whose behaviour must be checked together. Configured freshness settings do not, by themselves, establish an end-to-end revocation bound. Which checks use cached decisions, what invalidates them, and how quickly removed access is refused at each enforcement point are properties to verify in a specific deployment.
The revocation example is one use of a decision function shared across the platform. Its inputs and enforcement points are shown below.
The alternative, and the cost
A gateway-only check with a broadly privileged worker identity is simpler to build and faster to run. For a system where every action is equally sensitive and every user has the same reach, it may be enough.
It is insufficient for the decisions Opus has to make: this agent may read this file in this workspace but not that one; this case may be resumed by this reviewer but not written to the finance system by that integration. Those are resource- and context-specific decisions made deep in distributed work, and a gateway does not see them.
The cost of the Opus approach is repeated enforcement: latency on every check, an availability dependency on the decision point and its cache, and policy maintenance as groups and roles change. The questions to ask of any system that claims this property are the same three: which actions are refused end to end, whether a requester’s context can travel where it should not, and how quickly a revocation takes effect.
Next
Authorization decides who may act. When the action is a model inference, there is a second decision: where the data may go. Part 8 is about protecting identifiers without destroying the relationships the task depends on.