Classification and clearance
How Scrydon classifies information, what enforcement denies, and how to grant a member clearance.
Scrydon classifies information on a Bell–LaPadula ladder and enforces no-read-up: you cannot read something classified above your clearance. The control is on by default for every organization — there is nothing to switch on.
It aligns with ISO 27001:2022 A.5.12 (Classification of information) and NIST SP 800-171 3.1.3.
The default ladder
Every organization starts on the four-tier scrydon.default scheme.
| Rank | Label | Meaning |
|---|---|---|
| 0 | PUBLIC | Approved for external release. |
| 1 | INTERNAL | Internal use only. The baseline for members and for unlabelled uploads. |
| 2 | CONFIDENTIAL | Limited distribution; clearance required. |
| 3 | RESTRICTED | Narrow need-to-know; highest sensitivity. |
Ontology data created before the ontology adopted platform scheme ids is marked
with the scheme id default. That is the same scheme as scrydon.default, and
clearances apply to it identically. For that reason default is reserved: a
custom scheme cannot use it as its id.
A member with no explicit clearance holds INTERNAL. They are internal employees, so they can read their organization's ordinary content without an administrator granting anything. CONFIDENTIAL and above always require an explicit grant — the baseline is a floor, not a blank cheque.
What enforcement actually denies
Only content somebody deliberately classified. An upload that nobody classifies is stored unlabelled and stays readable by anyone with access to its knowledge base.
When a document is classified, a read or write is denied if your clearance is below its rank. Search results are filtered the same way, in every mode — a search never surfaces a document you are not cleared to see.
That is the no read-up half. The other half is no write-down: a workflow
run that has read classified content may not send it to a lower-rated
destination. The run carries the highest rank it has read — across child
workflows and across the tools an Agent block calls — and a tool call to an
endpoint rated below it is refused in Enforce with
CLEARANCE_EGRESS_VIOLATION.
The same "only what somebody classified" rule applies: a run that read nothing classified carries no mark and nothing is refused. The rating that matters on the other side is the endpoint's, set under Settings → Governance → Identity → Endpoints. An endpoint nobody rated counts as the level your organization chose under Unrated endpoints count as (see Unrated endpoints). The Endpoints tab shows that level above the list. Rate the endpoints that need a different level before turning Enforce on, or run in Audit first and read the recorded would-be refusals.
See Security → DLP for the response shape and the current coverage.
Your clearance also decides which model answers you. When Wand writes for you, or a knowledge base answers your question, the model connection is chosen with your clearance: a connection that requires a higher clearance is not used, and one at or below it is. A workflow bound to a service account uses the account's clearance instead — see Run As.
Granting a member clearance
Settings → Governance → Identity → Members. Pick the member, set their clearance, save. The change is audited.
You cannot grant a clearance higher than your own. Ranks above yours appear in the picker but are disabled, with the reason shown.
Changing the enforcement mode
Settings → Governance → Identity. The Enforcement mode selector sits in the page header and applies to every clearance surface.
| Mode | Behaviour |
|---|---|
| Enforce (default) | Deny on violation. |
| Audit | Log only. The would-be denial is recorded; the action proceeds. |
| Disabled | Checks off. Requires an exception reference and an expiry, capped at 90 days. |
Search stays clearance-strict in all three modes. Lowering the mode relaxes per-document read, write, and delete decisions only.
Adopting the scheme as your policy of record
Until you change something, the Clearance tab shows "Product default · not yet adopted" — you are running Scrydon's packaged scheme, and improvements to it reach you automatically.
The first change you make records you as the approver, with a date. From then on the scheme is your organization's own and Scrydon will not modify it. If an auditor asks who approved your classification policy and when, that is the record.
Editing the defaults
The Clearance tab exposes three organization-wide defaults:
- Default member clearance — what a member holds with no explicit clearance.
- Unlabelled data — what an unclassified upload is treated as.
- Unrated endpoints count as — the level an endpoint nobody has rated is treated as. See Unrated endpoints for which endpoints that covers.
Member clearance may not sit below unlabelled data. That combination denies every member every unlabelled document in their own organization, so it is rejected on save.
Unrated endpoints
The setting covers three kinds of endpoint:
- an account nobody has rated, until someone rates it or its connection;
- an MCP server nobody has rated, until someone rates it;
- a connection that has no account — API-key, basic-auth, bot-token and no-auth connections — until someone rates the connection.
Rate a connection under Settings → Governance → Identity → Endpoints, in the Connections group. A connection's rating covers the calls made through it without an account, and any of its accounts that has no rating of its own. An account's own rating always wins over its connection's.
This setting is INTERNAL by default. A new organization starts there, and an organization that existed before the setting was added and was still at PUBLIC on the default scheme was moved to INTERNAL on upgrade. Unrated endpoints can then receive internal data, and a room or run classified CONFIDENTIAL or above is still refused until someone rates the endpoint that high. An organization on a scheme of its own, or one that had already chosen a level other than PUBLIC, kept its level. If you want unrated endpoints to count as PUBLIC, set it back here: every unrated endpoint is then refused anything classified above PUBLIC.
The Endpoints tab shows each unrated row as Unrated, counts as followed by the level. It is shown in a neutral style when that level is above the lowest level of your scheme, and as a warning when it is the lowest. When Cortex is refused a tool because its account is not rated, the fix card offers an organization admin both ways out: rate that account, or change this setting.
Raising the level is a trade-off. Every account, MCP server and account-less connection anyone sets up from then on can receive data up to that level without anyone looking at it first. Set it to the highest level you are willing to send to an endpoint nobody has reviewed, and rate the accounts and MCP servers that need more.
HTTP-request and webhook destinations do not follow this setting. An HTTP Request or Webhook step can send to any host, so its destination cannot be rated: it keeps rank 0, the bottom of every scheme, whatever you choose here, and is refused any data classified above rank 0. On the default scheme that is everything above PUBLIC; on the EU scheme, whose lowest level is RESTREINT UE, it is every level.
If you switch to another classification scheme, the stored level is kept as a number. When the new scheme has no level at that rank, the picker shows Custom rank N until you choose one of the new scheme's levels.