Authorisation
Signing in establishes identity. Each action still has to pass policy.
A person can be allowed to read a sensitive file and still be prevented from sharing it outside the organisation. Casewelt keeps that distinction explicit by evaluating policy against the action and the resource after authentication.
Example
A People director needs the compensation file — but must not send it externally.
The director can read the compensation file while the external-share action is denied by policy. Those two decisions stay distinct after sign-in.
When the session is later revoked, even the previously permitted read should stop. This gives administrators a clean distinction between identity, session state and resource authorisation.
Decision model
Make each boundary visible.
Authenticate
Establish the principal.
Check session
Confirm that the session is still valid and has not been revoked.
Evaluate action
Apply policy to the requested action and resource.
Use the right surface
Keep staff, external-recipient and privileged administration paths separate.
Why it matters
Least privilege is easier to operate when “read” and “share” are not synonyms.
Many sensitive-content incidents begin with a legitimate user doing something the organisation did not mean to authorise. Fine-grained decisions make that boundary testable: the same person can succeed at ordinary work and fail safely at a more sensitive action.
This also produces better audit evidence. A policy denial is different from a broken login or an application error, and the product should preserve that difference.
See how decisions appear in auditTest a rule
Test Casewelt against a real access rule.
Describe the resource, the people who need it and the actions that must remain restricted. We’ll use that as the basis of the walkthrough.