Part 07 of 13 · Authority & Data

Why authorization has to follow the work

A permission checked at the front door is not enough when work crosses services, waits overnight and resumes under changed access.

Read the article on Substack ↗ (opens in a new tab)

Summary

An analyst starts the invoice case on Tuesday afternoon; that evening their access to the accounts-payable workspace is removed; on Wednesday morning the reviewer approves and the case resumes to read a file and write to the finance system. Whose permission is being exercised? A broadly privileged service account is a defensible answer for unowned background work, but for sensitive actions on business data Opus keeps the decision and the audit record attached to the person whose work it is.

The requirement is that every sensitive action be evaluated against subject, resource, action and context, consistently across services, reflecting permission changes within a bounded time, and logged — with the article noting that enforcement coverage and revocation timing are properties to verify in a given deployment rather than claims to accept. It distinguishes identity from permission (a successful federated login says who the actor is, not what they may do), describes the four inputs to a decision, and lists how broadly “resource” reaches: workflows, discoveries, files, variables, credentials, agents, code, cases, traces, audit logs, policies, integrations and APIs. Access groups mirror enterprise structure and roles package permissions, within an attribute-based model where roles are one evaluated attribute rather than a replacement for evaluation.

The important design decision is that checking does not stop at the gateway: the same decision function, delivered through an embedded library backed by a central policy decision point, applies at the collaboration service, the execution manager, the workers, the file service, the inference service and downstream APIs. Critical-path rechecks carry the requester’s authorization context with the work, so the Wednesday file read is refused and the case follows whatever failure behaviour the designer chose.

Caching bounds the latency cost, and the article resists overclaiming here too: configured freshness settings do not by themselves establish an end-to-end revocation bound, and it offers three questions to ask of any system claiming this property.

All thirteen parts →