Security
Security is a chain of decisions across identity, session, policy, content, sharing and audit.
Casewelt is designed around explicit boundaries: establish identity, confirm the session is still valid, decide whether the requested action is allowed, serve content only after authorisation, keep external sharing separate and record the result.
Layered controls
Each layer answers a different security question.
Keeping these checks separate avoids common shortcuts: treating authenticated identity as blanket permission, or treating a downstream SIEM copy as the authoritative product record.
Identity & principals
Use an identity plane for sign-in, while preserving distinct human, machine and external recipient principals in the product model.
Sessions & devices
Make revocation and device context meaningful so a copied or stale session does not become permanent access.
Authorisation
Evaluate specific actions against specific resources after authentication, with deny behaviour that is observable.
Content handling
Keep file access behind authorisation. Browsers and recipients receive bytes only from Casewelt, never a customer-facing object-storage URL.
External sharing
Give outside recipients a separate, limited path instead of extending employee credentials across the boundary.
Auditability
Keep security and content events queryable so the organisation can reconstruct significant decisions.
What to observe
A reviewer should be able to exercise these boundaries directly in the product.
These checks do not depend on a certification pack: they depend on observable product behaviour.
A signed-in user is denied
The same valid session may be allowed to read a file and denied when creating an external share. The denial should be reported clearly as a policy decision.
A revoked session stops
After revocation, previously permitted work should not continue on a copied token or leftover browser state.
A share can end independently
Revoking or expiring external access should not require changing employee credentials or emptying the workspace.
Bytes follow authorisation
Content should not be served because a URL was guessed or a session existed somewhere else in the product.
Recipient access is distinct
An outside recipient should not inherit staff workspace navigation, administration or organisation-wide listing.
The record survives the event
Create, access, deny, expire and revoke should remain queryable after the share or session has ended.
Isolation & placement
Keep organisation data, shares and administration on separate surfaces.
Workspace content, external sharing and privileged administration run on distinct surfaces with controls appropriate to each risk. Each organisation runs in an isolated tenant, with a home region and envelope encryption keyed to that organisation.
Staff sign in through the organisation’s identity provider. Recipients use the share surface. Machines enrol with device certificates and mTLS. A write that conflicts with home-region policy is rejected and surfaced as a placement conflict.
See encryption, identity and tenancyOrganisation boundaryWorkspace + policy + audit
External boundaryRecipient share surface
Operational boundaryAdministration + automation
Placement boundaryOrganisation home region
Controls in depth
The same file is protected at rest, in policy and in the audit trail.
Content is encrypted per version with a data encryption key wrapped by the organisation’s key. Authorisation is default-deny: a valid login still has to win an action on a resource. Session revoke takes effect without waiting for the access token to age out.
The audit store is append-only. Selected events leave on signed webhooks, with replay protection and retry, while the product record remains the source for “who opened it?”.
Review boundaries
Review the control boundaries that matter to your team.
Choose the actions, trust surfaces and evidence your security review needs to exercise.