AI Glossary / Governance, ethics and safety / Advanced
Multi-level security
Definition
Multi-level security is an approach to processing information with different security classifications and categories while allowing authorized users appropriate access and preventing unauthorized access. It requires effective separation and control of information across those security boundaries.
What it means
A shared system may contain information that different users are permitted to see. Multi-level security concerns handling those differences without allowing information from a more restricted domain to escape through an inappropriate path.
The term has a specific security meaning. It is not simply a synonym for having several protective layers, which is usually called defense in depth. Nor does the presence of ordinary administrator and user accounts automatically establish a multi-level secure system.
For AI, the issue extends beyond source documents. Retrieved passages, generated summaries, logs and derived data may carry information from the sources used. Removing a classification label from an output does not remove the sensitive information itself.
How it works
A system associates information and relevant subjects with security attributes and enforces a policy governing access and information flow. Classification levels may be accompanied by categories or compartments, so a higher level alone need not permit access to every item.
The architecture must preserve the policy across processing, storage and transfer. An AI retrieval service should not combine restricted material into an answer delivered to someone who lacks authorization for that material. Controls need to operate on actual information paths rather than depend solely on the model following an instruction.
The detailed policy and assurance requirements depend on the environment. Formal security models can help reason about allowed flows, but real systems also require careful implementation and evaluation. This overview does not establish that a particular product meets an accredited multi-level security requirement.
Three practical examples
- A document environment enforces different classification and compartment rules for users working on the same shared platform.
- An AI search service ensures that retrieval and answer delivery respect the authorization boundaries of its source material.
- A security review examines whether logs or cached summaries expose information across domains even when direct document access is restricted.
Think of it this way
Think of a records building with rooms requiring both an access level and a particular project authorization. A visitor's permission to enter one restricted room does not necessarily authorize every other room at that level.
The analogy illustrates levels and categories. Digital information can be copied and combined, so a real security design must also address flows through processing and outputs rather than only entry to storage locations.
Worked example
A level is not the whole authorization
Consider an invented policy with two levels, internal and restricted, plus project categories Cedar and Birch. A document is labeled restricted and Cedar. One user is authorized for restricted information in Birch but not Cedar. Another is authorized for restricted information in Cedar.
Under this teaching policy, the first user cannot read the document even though their level is high enough. The required project authorization is missing. The second user may read it if the other policy conditions are satisfied.
If an AI service summarizes that document into a file labeled internal, the change of label does not itself authorize release. The summary may still reveal the protected content. The example demonstrates why access and output-flow rules need to consider the information represented, not just a displayed label.
Illustrative case study
Fictional company Rowan Research separates project documents using established security domains. It introduces an AI assistant whose retrieval component honors those boundaries, but its shared response cache is keyed only by question text.
A review finds that an answer generated for an authorized user could be reused for another user asking the same question. The team redesigns the cache boundary and evaluates other derived stores, including summaries and logs. It also tests whether the complete service preserves the intended policy.
The case shows that protecting initial retrieval is necessary but insufficient when later processing creates additional information paths. The organization does not describe an access-filtered chatbot as a fully assured multi-level secure system without the required broader evidence.
Common misconceptions and mistakes
- Multi-level security means multiple security products. The term concerns information at different classifications and authorizations.
- Higher clearance always grants every access. Categories and other policy conditions can also apply.
- A generated summary is automatically less sensitive. Its content may preserve or reveal protected information.
- Correct source permissions secure the whole AI workflow. Caches, logs and output delivery can introduce additional paths.
Business use
This concept matters to organizations that must maintain strong separation among information domains. AI capabilities can make restricted information easier to combine and restate, so the complete flow deserves examination.
Procurement teams should ask what security policy a product supports, which boundaries are enforced and what assurance evidence covers the deployed configuration. Avoid treating marketing phrases as proof of formal security properties. Where the environment requires specialist evaluation or accreditation, a general AI feature demonstration does not replace that process.
People also ask
Is multi-level security the same as role-based access control?
No. Roles can support authorization, but multi-level security specifically concerns processing across classification levels and categories.
Does it require AI?
No. It is an established information-security concept that also applies to AI-enabled systems.
Can a prompt enforce the boundary by itself?
It is not sufficient evidence of robust separation. The system architecture and enforcement mechanisms must implement the policy.
Check your understanding
A user has access to a restricted level but lacks the document's required project category. Should the system allow access solely because the level is sufficient?
Answer: No. Under a policy requiring both, the missing category still prevents authorization. The system must apply the complete rule.
Related terms
- Mandatory access control
- Least privilege
- Defense in depth (computing)
- information-flow control
- security classification
- compartment
- defense in depth
Learn next
Read information-flow control and mandatory access control. Trace a restricted document through retrieval, generation, caching and logging. Identify the security attributes and enforcement boundary at each step.
More in Governance, ethics and safety
- Model poisoning - Model poisoning is a deliberate attack that corrupts a model through control over its parameters, updates or other model-level components.
- Model risk management - Model risk management is the process of identifying, assessing, reducing and monitoring risks arising from models and their use.
- Model Selection Bias - Model selection bias is distortion introduced when a model is chosen using data and the chosen result is interpreted without accounting for that selection.
- Non-response bias - Non-response bias occurs when people who provide data differ in relevant ways from those invited or eligible to respond who do not.
- Nondiscrimination - Nondiscrimination is the principle that people should not face unjustified disadvantage or exclusion on grounds that should not determine their treatment.
- Offline learning - Offline learning is training a model from an already collected dataset rather than continually updating it as new operational examples arrive.
Sources
NIST CSRC glossary, multi-level security, citing NIST SP 800-53 Revision 5 and CNSSI terminology: https://csrc.nist.gov/glossary/term/multi_level_security. DAMA UK source-list glossary: https://www.dama-uk.org/pages/glossary. The project labels, access policy and AI-cache case here are original illustrations, not descriptions of a certified implementation.
Previous: Multi-label classification Next: Multi-model database