AI Data Restriction
Your AI policy bans payroll data. Which agent can read it anyway?
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 →
The 1Security platform
AI Data Restriction is just the beginning
AI Data Restriction is one screen of the 1Security platform for Microsoft 365. Locations, devices, apps, AI agents, logs, permissions, sensitive data, compliance, reports and actions run on the same read-only connection, on the licence you already have.
- Microsoft 365 Alerts ToolOne alert model across policies, activity and anomalies - with the evidence attached and the alert threshold in your hands.
- Microsoft 365 Monitoring ToolReal-time monitoring that catches a mass download while it is unfolding - across users, files, apps, AI agents and devices.
- Copilot Security ToolEvery AI agent's real blast radius - quantified before rollout, watched and constrained after.
- Shadow Device DetectionEvery device touching your data, reconstructed from real activity - including the machines that never enrolled anywhere.
- Impossible Travel DetectionLocations as identities, not IPs: country, city and network for every action, first-seen origins, travel timelines with verdicts - no E5, no P2.
- Conditional Access MonitoringDeclared Conditional Access compared against observed sign-ins: coverage verdicts, ungoverned traffic share, and the ranges your offices outgrew.
- Office 365 Access ManagementEffective access, resolved - who can reach what, through which grant, and one place to take it away.
- SharePoint Governance ToolEvery site ranked by exposure and abandonment - links, guests and Copilot access under control.
- Office 365 User ProvisioningLifecycle access from day one to offboarding - reach, dormant accounts and license reclaim in one flow.
- Microsoft 365 Audit ToolUp to three years of searchable activity history - every action tied to an actor, device and location.
- Microsoft 365 Inventory ToolEight live inventories on one permission graph - including the sites, devices and AI agents that were never registered anywhere.
- Office 365 ReportingAnswers, not exports - regulator-grade numbers, saved views and a read-only API for your SOC.
- Microsoft 365 File PermissionsWho has access to any file, and why - people, links, apps and AI agents on one map, with the fix in the same place.
- Sensitive Data DiscoveryWhere regulated data lives and everything that can reach it - two detection engines, no premium licence required.
- Office 365 Email MonitoringOutbound sensitive content, delegated-send abuse and whole-thread evidence that survives deletion.
- Purview Label CoverageWhat your sensitivity labels actually cover, and which of them protect anything at all.
- AI Agent InventoryEvery agent in the tenant with its real reach counted, its blueprint reviewed, and guardrails you can verify.
- AI Spend TrackingInteractions, Copilot credits and Azure tokens in one ledger per agent - with the spend column next to what each agent can reach.
- Microsoft 365 User Access ReviewEvery identity with what it can reach, what it did, and whether it should still exist - including SharePoint-only guests that live outside the directory.
- Group Access AnalysisWhat membership in a group actually unlocks - nesting resolved, external members surfaced, blast radius counted.
- App and OAuth Consent GovernanceEvery app with a foothold in the tenant: how it got in, who let it in, and what it can actually read.
- Remediation AutomationFindings become fixes at tenant scale, counted before you enable them and staged behind a review window.
- Microsoft 365 Licence OptimizationThe seats you pay for and nobody uses - unassigned units, licences on guests, and dormant accounts still billing.
- Microsoft 365 Anomaly DetectionEvery policy, user, app and agent measured against its own baseline - with an alert line you move and see the answer to at once.
- Office 365 Sign-in LocationsEvery place your tenant is reached from, with your Conditional Access configuration laid over observed reality.
- Microsoft 365 Unified Audit LogWho did what, when, from where and on which device - retained up to three years on a standard licence.
- SharePoint Site InventoryEvery site, channel site and OneDrive in one list, ranked by external reach, abandonment and what Copilot can read.
- Microsoft 365 Activity AnalyticsThe extremes rather than the averages - a mass download inside the hour, and everything nobody has touched in a year.
- Microsoft 365 Trend TrackingAny number in the tenant followed over time, with the change and the deviation attached - and alerting on the same object.
- Microsoft 365 Compliance MonitoringReadiness for eleven regulations measured from live tenant data - with weekly snapshots and a dated evidence pack per framework.
- Microsoft 365 Security ScoreMicrosoft Secure Score beside the score measured from what actually happens - one worklist ranked by points still on the table.
- External Domain MonitoringEvery organisation your tenant exchanges data with, resolved to a real company - with drift flags and an enforceable verdict per domain.
- All featuresExplore everything
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.