AI Data Restriction
"Card numbers are off-limits to AI." Now it is a setting, not a memo.
Every AI usage policy names data categories the AI must not touch - payroll, health records, payment cards. What actually decides is permissions, and nobody can read a policy off a permission graph. 1Security turns the sentence into a declared restriction: pick the data type, pick the level, and every agent, app and user that can still reach it becomes a live violation to work down. The declaration is recorded - who, when, and the exposure at that moment - which is exactly the shape the EU AI Act asks deployers to produce.
- 3 levelsmonitored, no AI access, no access - you choose what the badge means
- 300+detection types a restriction can attach to, found by two engines
- 4 channelsagent violations counted per access channel - app-backed, tenant-wide, admin-consent, scoped
The problem
The policy lives in a document. The access lives in a graph.
Every organization now has the sentence somewhere - in an AI usage policy, a DPIA, a board minute: this category of data is not to be processed by AI. The sentence is easy. The tenant is not: the data sits in thousands of files across hundreds of sites, and reach comes through nested groups, sharing links, app consents and agent knowledge sources that nobody assembled on purpose.
Before AI, the gap between policy and permissions was survivable, because finding the files took effort. Semantic search removed the effort. An agent grounded on a site answers from whatever the site holds, and the first person to learn that payroll was reachable is whoever asked the right question.
Regulators have caught up with the sentence too. The EU AI Act asks deployers to control what data their AI systems are exposed to and to keep evidence of doing so - a memo does not survive that question. What survives is a declared control with a record: restricted since this date, by this person, these violations found, this many remaining.
What you get
A declaration that counts its own violations.
The restriction attaches to the data type - the same rows the discovery engines fill - so it covers every carrier file at once, present and future.
A declared state, not a note
Mark a sensitive information type as monitored, no AI access, or no access. The level is a visible badge and a filter, the declaration is stored with who made it and when, and lifting it keeps the history rather than erasing it.
Blast radius before you commit
The restriction dialog shows what the declaration will cover before you confirm: the files, users, apps, AI agents and emails that currently reach each selected type - so the level you pick is an informed decision, not a hope.
Violations, live and per channel
Every agent that can still reach a restricted type is listed with the channel that gives it access - app-backed, tenant-wide, admin-consent or scoped - next to the apps and users. Each count is a click into the list behind it.
Policies spawned per restriction
An enforcing restriction creates its own detection policy: no-access watches every carrying file, no-AI-access watches every agent with reach. Level changes re-point the policy; lifting the restriction retires it with the history kept.
Event history and attestation
Declared, modified, lifted - every event carries an exposure snapshot. The attestation reads them back as the regulator-shaped answer: restricted since date X, N violations found, current exposure, accesses since declaration.
Who actually read it
Reach is who could. The access-activity view shows who did: reads of restricted content are stamped as they arrive from the audit log, so "has any AI touched this since we restricted it" is a filter, not an investigation.
How deep it goes
From declaration to zero, with the evidence attached.
One restriction, followed end to end - the loop most tenants run in their first week.
Declare payment cards no-AI-access. The dialog shows the blast radius - the files, the users, the three apps and two agents that reach the type today - and the confirmation writes the declaration with your name on it. From that moment the violations are counted live, and honesty is part of the design: the badge says declared and watched, and enforcement happens through the staged actions you approve.
Work the list down. The tenant-wide agent loses the site from Copilot org-wide search; the forgotten survey app gets its sign-in disabled; the anyone links on the worst files expire - each a proposal in the 72-hour review window, each recorded. The violations list shrinks as the actions land, and nothing on it disappears without a reason attached.
Then hand over the record. The attestation reads the event history and the access log together: restricted since March, twelve violations found, ten remediated with the actions listed, zero AI reads since April. That page is the difference between claiming a control and demonstrating one.
In practice
Four steps from policy sentence to auditable control.
The workflow follows the policy document you already have.
- 01
Pick the types the policy names
Open Sensitive Info and find the categories your AI policy already forbids - payment cards, health data, payroll, credentials. The discovery engines have been filling these rows since day one; the restriction attaches to them.
- 02
Read the blast radius, pick the level
The dialog shows what each declaration covers before you commit. Start with monitored where you are unsure, no-AI-access where the policy is explicit, no-access for the categories nobody should reach at all.
- 03
Work the violations with staged actions
Every violation resolves through an existing lever - block the site from Copilot search, revoke the grant, disable the app, expire the links - staged behind the review window and recorded in the audit trail.
- 04
Hand the attestation to the auditor
The restriction record, the remediation trail and the access log come out as one answer, mapped to the frameworks the compliance view evaluates - EU AI Act, NIS2, GDPR Article 32, DORA, ISO/IEC 42001.
The difference
What a declared restriction adds over a filter
The counts existed before. The declaration is what turns them into a control.
- A restriction level on the data type itself, covering every carrier file at once - present and future
- Blast-radius preview per type before the declaration is committed
- Agent violations broken out by access channel, next to apps and users
- A detection policy per enforcing restriction, created and retired automatically
- Event history with exposure snapshots - declared, modified, lifted
- Access-time tracking: who actually read restricted content, stamped from the audit log
- The attestation: restricted since, violations found, remediation trail, current exposure
- Restriction status feeding the compliance view - the same declaration answers the AI Act data-governance articles
Licensing and scope
Standard licenses, both engines, every resource type.
Restrictions attach to detection types found by either engine - 1Security's own 300+ detectors on a Business Basic license, or imported Purview Sensitive Information Types where you have them. Declaring is part of the read-only product; the staged actions that close violations are the separately consented write module, reviewed like everything else.
- 183 dayslog retention attested in the evidence pack - past the EU AI Act's six-month floor
- 72 hdefault review window on every action that closes a violation
- 2 enginesrestrictable types come from 1Security detectors and imported Purview SITs alike
Related
Where this fits
A restriction is the control on top of two other layers: discovery finds the data, and the agent inventory knows who can reach it. The three pages below are the rest of the loop.
Sensitive data discovery
The 300+ detectors and reach counts the restriction attaches to.
See discovery →AI agent inventory
Every agent with its reach resolved - the population the violations list draws from.
See agents →Copilot security
The rollout view: what Copilot itself would read, and the levers that constrain it.
See Copilot →
FAQ
Questions teams ask first
Is this enforcement or monitoring?
Both, honestly labeled. The declaration itself is monitoring with teeth: violations are counted live and verified continuously by the spawned policy. Enforcement happens through the staged actions that close each violation - blocking, revoking, expiring - each behind a review window. The product never claims a restriction is enforced while violations remain on the list.
Which regulations does this map to?
The EU AI Act's data-governance obligations for deployers are the closest fit - controlling what data an AI system is exposed to, with logs kept past the six-month floor. The same declaration and attestation feed GDPR Article 32, NIS2 and the other frameworks the compliance view evaluates, so one control answers several auditors.
Do we need Purview or an E5 license?
No. Restrictions attach to detection types found by 1Security's own engine, which runs on a Business Basic license. If Purview Sensitive Information Types are present, they are imported and restrictable in exactly the same way - existing investment carries over, none is required.
What exactly can be restricted?
Any sensitive information type on the Sensitive Info screen - payment cards, national IDs, health identifiers, credentials, and the rest of the 300+ catalog. The restriction covers every file and email carrying the type, including ones scanned after the declaration - new carriers join the violation counts automatically.
What happens when a restriction is lifted?
Verification stops, a final exposure snapshot is written, and the full history stays - who declared it, every level change, every violation counted along the way. An auditor two years later sees the control existed, when, and what it found. Nothing is erased by lifting.
Declare the first restriction this week.
Connect read-only, find the types your AI policy already names, and see the blast radius before you commit. The violations list is usually shorter than feared - and finally finite.
Or keep the policy as a sentence in a document.