Should an AI Sensitivity Label Automatically Control Document Access?
Use AI classification to inform a governed access decision, with protected attributes and review of permission changes
Published
An AI model labels an uploaded document INTERNAL. An access rule reads that value and makes the file visible to every employee. The document contains legal advice and personal information. One classification error has become a permission change.
An AI sensitivity proposal should pass through a governed decision before it broadens access. Use classification to identify likely handling needs and route review. Let an explicit policy determine which validated attributes, approvals, and context permit a user to read, change, or share the document. The organisation may approve automation for defined cases, but that authority should come from its access policy and evidence about the workflow.
Separate the proposal from the attribute that policy trusts
Maintain two records: what the classifier proposed, and what the access-control process approved. Use distinct fields and update paths so a retry, bulk reprocessing job, or model change cannot silently replace an approved access label.
- 1 · Propose
Capture the classification result
Record the proposed label and the exact content version analysed. Keep uncertain or incomplete results visible to the review process.
- 2 · Validate
Apply the approval rules
Check the result against the handling policy, source evidence, current version, and the authority required for a permission change.
- 3 · Enforce
Evaluate access from approved state
Use controlled attributes and trusted identity context for each operation. A proposal alone should not grant a wider audience.
| Record | Example fields | Who may change it |
|---|---|---|
| Classifier proposal | proposedSensitivity, source version or checksum, processing status, model and taxonomy versions, run reference, and supporting indicators. | The processing service writes its result without permission to approve a broader audience. |
| Approved access state | approvedSensitivity, validation status, approved source version, decision maker or rule, effective time, and reason. | An authorised approval path validates the change and records its authority. |
| Exception | Case reference, requested audience and action, accountable approver, expiry, and review outcome. | A designated exception owner grants only the approved scope and duration. |
Field separation is useful only when the write paths enforce it. Review generic attribute updates, service credentials, imports, console actions, and administrative tools as well as the approval screen. Apply the required restrictions at an enforceable API or service boundary; hiding a field in the interface does not protect it. Test that a classifier identity and an ordinary uploader cannot write the approved access state through another route.
Define the audience while classification is unresolved
Give unclassified content an explicit intake policy. Authorised processing identities and assigned reviewers may need access, while a wider business audience waits for validation. Missing, unknown, conflicting, stale, or failed results should take a defined exception path instead of falling back to a permissive label.
Broadening access
Moving from a restricted group to every employee changes the potential exposure. Require the approval or independently validated rule specified by the handling policy. A model's self-reported confidence is insufficient authority on its own.
Narrowing access
A restrictive signal can trigger protected handling pending review. Also consider availability: a false positive can block an urgent case. Provide an accountable escalation path and a limited, expiring override where justified.
The labels PUBLIC, INTERNAL, CONFIDENTIAL, and RESTRICTED are an example taxonomy. Define their audiences and permitted actions explicitly. “Internal” might mean a department or case team rather than all staff, and an approved public label need not trigger publication automatically.
Work through a misleading INTERNAL proposal
Consider a fictional supplier case containing a signed agreement and an annex with personal contact details and legal advice. The classifier sees a routine agreement and proposes INTERNAL. The organisation's handling policy requires restricted review for this combination.
Keep the intake boundary
The package remains available to the authorised intake service and assigned case reviewers. The INTERNAL proposal is recorded without changing that audience.
Resolve the evidence
The reviewer checks the source and annex, records the applicable handling rule, and approves RESTRICTED for the relevant content version. The decision record links to protected evidence instead of copying sensitive passages into a broadly accessible log.
Evaluate a real access request
A user outside the approved case team requests the document. The configured access policy uses the approved state and trusted user context to deny the operation. The classifier's INTERNAL proposal remains available for quality review but does not grant access.
Handle the next version
A replacement annex arrives. The configured version check marks the earlier approval inapplicable to the changed content and routes the new version for validation. A delayed result for the earlier version must not approve the replacement.
This example defines desired configured behaviour. Verify how updates and approvals interact in the actual integration, including simultaneous uploads and late results. Do not assume that separate metadata fields by themselves prevent an update race.
Follow the decision into previews, search, and sharing
A protected download endpoint is one part of the exposure model. Test search titles and snippets, OCR text, previews, thumbnails, derived PDFs, attachments, exports, and external sharing paths. Decide whether a package inherits its most restrictive member's handling or whether each item has independent controls, then test the chosen rule.
When a label changes, inspect caches, indexes, previously issued links, and copies already exported. Define how each path expires, refreshes, or revokes access; a new attribute value does not necessarily invalidate a previously issued URL or retrieve a downloaded copy. Include direct storage access and integration identities in the deployment's access review.
Keep a useful decision record without logging the document
Retain the document and source-version reference, proposal run, approved label, rule or reviewer, access-policy version, requested operation, outcome, and correlation identifier needed to investigate a change. Give that record its own access and retention rules.
Where OPA decision logging is enabled, its decision-log documentation describes recorded query inputs and masking policies for sensitive fields. Configure and test the logging behaviour for the deployment. Avoid storing document bodies, extracted personal details, or secrets merely to make an access decision easier to debug.
Test the permission boundary before enabling automation
- Submit known false-negative, false-positive, ambiguous, and unsupported-file examples.
- Fail or time out the classifier and confirm that the wider audience still has no access.
- Attempt to update approved fields using the classifier identity and an ordinary uploader.
- Replace content during processing and verify that a late result cannot approve the new version.
- Check an unauthorised user's search results, previews, downloads, and sharing paths.
- Exercise a justified override and verify its scope, expiry, and review record.
Make the permission change an explicit decision
AI classification can help teams find sensitive content and prioritise review. Keep the authority to broaden access in a controlled policy and approval path. Protect the fields that path writes, bind the decision to the content it covers, and verify the resulting access across every delivery route.