Clearance & Access Control
Dominir uses a clearance level system to control access to records and agent capabilities. It is a single integer — 0 through 5 — assigned to every user and every agent. Records can also carry a classification level. The rule is simple: you can only access a record if your clearance level is at or above the record's classification.
The scale
| Level | What it represents |
|---|---|
| 0 | No access beyond public, unclassified records |
| 1 | Standard read access — general staff |
| 2 | Operational write access — coordinators, intake roles |
| 3 | Senior operational — managers, paralegals, case leads |
| 4 | Elevated — senior staff with access to financial and legal records |
| 5 | Full access — administrators and the platform's top-tier agents |
These definitions are a convention, not a technical constraint. Your organization can assign levels to roles however makes sense for your structure. The Kernel enforces the numbers — the meaning of each level is yours to define.
Granting clearance
Clearance is granted by a person who already holds clearance level 5. That person cannot grant a level higher than their own — there is no mechanism in the system to self-escalate or bypass this.
Granting a clearance level requires re-authenticating with your password at the moment of grant. A stolen session token alone is not sufficient to change another user's access level.
Clearance grants are logged permanently. Every grant, its grantor, the target user, the level, and the timestamp are written to the audit record.
Revoking clearance
Revocation follows the same rules as granting: requires clearance level 5 and password re-authentication. Revocation takes effect immediately — the affected user's next request is evaluated against their new (lower) clearance level.
Agent clearance
Agents carry a clearance level defined in their configuration. This level is set when the agent is registered and is enforced by the Kernel at runtime — it cannot be overridden by the agent's prompt or by the user who dispatches the agent.
An agent at clearance level 3 running on behalf of a user at clearance level 5 still operates at clearance level 3. The agent's ceiling is its own level, not the dispatching user's level. You cannot escalate an agent's access by dispatching it from a high-clearance account.
Delegation ceilings
Agents that can delegate work to other agents have an additional constraint: a delegation clearance ceiling. This is the maximum clearance level of any agent the delegating agent is allowed to hire.
An agent at clearance level 3 with a delegation ceiling of 3 cannot hire a clearance-level-4 agent, even if that agent exists and the user has level 5. This prevents privilege escalation through delegation chains.
Record classification
Individual records can be classified at a specific level. A record classified at level 4 is not readable by any user or agent with a clearance level below 4, regardless of their role or who dispatched them.
Reclassifying a record requires clearance level 5. The reclassification is logged in the same audit record as clearance grants.
What is not protected by clearance
Clearance levels control access to records. They do not:
- ▸Restrict which UI screens a user can see (that is controlled by your role configuration)
- ▸Prevent a user from creating new records in a store they have access to
- ▸Replace the write approval system — approval and clearance are independent gates
A user at clearance level 5 with write access to a store still cannot skip the approval process for sensitive record types. Approval is enforced by the Kernel's policy layer regardless of clearance.