Security
Six checks stand between a request and your content.
Who is asking. Is their session still good. Are they allowed to do this particular thing to this particular file. Only then is the file served. External recipients use a separate path. Whatever happened is written down. Each step is distinct and testable.
Layered controls
Each layer answers a different security question.
Keeping the checks apart avoids the two shortcuts that cause most trouble: treating “they are logged in” as “they may do anything”, and treating a copy of your logs in another system as the definitive record of what actually happened.
Who is asking
People sign in through your identity provider. Employees, automated systems and outside recipients are kept as three different kinds of user, not merged into one.
Sessions and devices
You can end someone’s session and have it actually stop, so a stale or copied session does not quietly turn into permanent access.
What they may do
Each action is checked against the specific file it targets, and a refusal is visible rather than silent.
Serving the file
Nothing is served before the check passes, and the file always comes from Casewelt. Nobody is ever handed a raw storage link they could pass on.
External sharing
Outsiders get their own limited route in, rather than a stretched-out version of an employee login. Download counts can be capped by organisation policy.
Audit
Security and content events stay searchable, and sealed evidence packages can be requested when a screen is not enough.
What to observe
Six things to try yourself, before you believe any of this.
None of these depend on a certification pack arriving in your inbox. They are things you can sit down and watch happen (or not happen) in the product.
Refuse a properly signed-in user
Have the same person read a file, then try to send it outside. The refusal should say it was a policy decision, not leave them wondering if their login broke.
End a session and watch it stop
Revoke it, then carry on clicking in the old browser tab. Nothing should still work.
Kill a share on its own
Ending external access should not mean changing anyone’s password or moving the file.
Try to skip the check
A file should never come back just because someone had a URL, or because they were signed in somewhere else in the product.
Look around as an outsider
Open a share as the recipient and try to reach anything else. You should not be able to.
Come back a month later
The share has expired, the session is gone. You should still be able to ask what happened while they were live.
Isolation & placement
Your data, your shares and your settings are kept apart.
Everyday file work, external sharing and privileged administration each run on their own footing, with controls that match how much damage each one could do. Your organisation’s content is separated from every other customer’s, sits in a region you agreed, and is encrypted under keys tied to your organisation.
Your staff sign in through your identity provider. Recipients use the share page. Automated systems get their own certificates. And if a write would put content outside your agreed region, it is refused and reported rather than quietly moved.
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 on disk, in policy and in the record.
Each version of a file gets its own encryption key, and that key is itself wrapped by a key belonging to your organisation. Nothing is permitted unless a rule says so: the starting position is no, and a valid login does not change that on its own. When you revoke a session it stops there and then, rather than when a token happens to expire.
The audit record is written to be added to, not edited. You can forward selected events to your own monitoring over signed webhooks, but the copy in your SIEM is never what Casewelt treats as the truth: the product record is.
Review boundaries
Bring the checks your security team would run anyway.
Tell us which actions you want to see refused and what evidence you need afterwards, and we will build the session around that.