Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to handle shadow AI usage?

The sequence that holds up is find what is in use, publish rules tied to data categories, offer an approved alternative people will actually use, and enforce in graduated steps. A ban standing alone skips three of those steps, and use moves onto personal accounts and devices where the organization can no longer see it.

Several shadowed application paths converge through review controls into an approved workflow.

The sequence that holds up is find what is in use, publish rules tied to data categories, offer an approved alternative people will actually use, and enforce in graduated steps. A ban standing alone skips three of those steps, and use moves onto personal accounts and devices where the organization can no longer see it. Most organizations that handle shadow AI usage credibly do four things in order: they find out what is in use, they publish clear rules tied to data categories, they provide an approved alternative that is usable in practice, and they apply graduated controls with monitoring rather than relying on a ban. Guidance from the UK NCSC and frameworks from NIST point in the same direction, and breach data from IBM shows why the access control and governance gaps behind shadow AI are costly. The thread through all four steps is Least Exposure: each AI service or agent reaches only the data its task requires, for the duration of the task, under an identity that can be audited. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Bans alone are not the recommended approach: the NCSC advises organizations to provide approved, secure alternatives and to build open communication so staff do not conceal use (NCSC, 2026).
  • IBM reported that 63 percent of breached organizations in its study had no AI governance policy, and that high shadow AI levels added 670,000 dollars to average breach cost (IBM, 2025).
  • Microsoft found that 60 percent of leaders said their company lacked a vision and plan to implement AI, while employees adopted tools on their own (Microsoft, 2024).
  • The NIST AI Risk Management Framework separates governance into Govern, Map, Measure, and Manage, which gives handling efforts a structure beyond a single policy document (NIST, 2023).
  • OWASP lists sensitive information disclosure as the second ranked risk for LLM applications in its 2025 Top 10, which frames the main harm from unmanaged use as data exposure (OWASP, 2025).
  • Handling is a continuing process with reassessment, not a one time cleanup, because approved products keep adding AI features; NIST's Govern function calls for monitoring whether the risk management process itself remains effective (NIST, 2023).

What does handling mean, beyond having a policy?

A policy is a statement of intent. Handling is the operating work around it: an inventory that is refreshed, decision rights that are named, a request route for new tools, training that reflects real tasks, technical controls that match the stated rules, and a response path when the rules are broken. IBM's figures illustrate the difference between the two. Having a policy did not, on its own, mean an organization audited for unsanctioned use, and 63 percent of breached organizations had no AI governance policy at all (IBM, 2025).

NIST structures this work in the AI Risk Management Framework. Govern is the cross cutting function covering culture, accountability, and risk tolerance, while Map, Measure, and Manage operate around each system (NIST, 2023). Applied to shadow AI, Govern answers who decides, Map answers what exists, Measure answers how risky each use is, and Manage answers what will be done and in what order. A handling program that can answer all four questions in writing is in a materially different position from one that has only an acceptable use paragraph.

Should shadow AI be banned, tolerated, or brought under governance?

Three broad postures are available, and each has a documented weakness. A blanket ban is simple to state and hard to enforce, particularly for web services reachable from personal devices. The NCSC does not recommend stopping AI use, and warns that where policy cannot meet business needs, employees will adopt services before the organization can assess them (NCSC, 2026). A ban can therefore increase concealment while reducing the organization's visibility, which is the opposite of the intended effect.

Unmanaged tolerance has the reverse problem. It preserves productivity and avoids conflict, but it leaves data flowing to services whose retention, training, and security terms the organization has never reviewed. OWASP identifies sensitive information disclosure as a leading LLM application risk, covering personal data, credentials, and proprietary information leaving through model interactions (OWASP, 2025). Tolerance without controls accepts that risk without measuring it.

The third posture, managed adoption, is the one the guidance supports. The organization assesses tools, approves some outright, approves others for defined data classes, prohibits a small set, and gives staff a fast route to ask about the rest. Managed adoption is slower to describe than a ban, and it requires continuing effort, but it is the only posture that reduces both the exposure and the incentive to hide. It also creates a record that regulators and auditors can examine, which neither a ban that is ignored nor tolerance that is undocumented can provide.

How should rules be written so employees can actually follow them?

Rules fail most often at the level of data, not tools. Telling staff not to use a named product is clear for a week and obsolete within a quarter. Telling staff which categories of information may never leave approved systems, which may be used in approved AI services, and which are unrestricted, gives them a test they can apply to a tool nobody has mentioned yet.

A workable rule set therefore starts with classification. Public information, internal information, confidential information, and regulated personal data each get an explicit AI handling rule. NIST's Generative AI Profile treats data privacy as a distinct risk for generative systems, including leakage and unauthorized disclosure of personal and sensitive data, which supports writing rules around data rather than around brands (NIST, 2024). Rules should also cover outputs: AI generated text, code, and analysis that enters a customer deliverable or a system of record needs review by a named person, because the organization remains accountable for it.

Clarity also means naming the exceptions and the decision maker. If a rule has no exception path, staff will invent one. A short request form, a named owner, a stated decision time, and a published list of decisions already taken will do more for compliance than a longer policy. Finally, rules should state what happens when they are broken, in proportionate terms. If every breach of an AI rule is treated as gross misconduct, disclosure dries up. If nothing ever happens, the rules are decorative. Graduated, predictable consequences are the middle position that published governance practice supports.

What does a usable approved alternative require?

An approved alternative fails when it is approved in name and unusable in practice. Common failure modes include a long provisioning delay, a model or feature set well behind the consumer tool it replaces, no access from the devices staff actually use, and no training or examples tied to real tasks. Microsoft reported that leaders recognized AI adoption as competitively important while many also said their company lacked a plan to implement it, a gap that helps explain why employees supplied their own tools (Microsoft, 2024).

Provisioning should therefore be treated as part of the control. Enterprise agreements matter for data reasons: they are the mechanism by which an organization obtains terms on retention, on whether inputs are used for training, on deletion, on sub processors, and on breach notification. The NCSC notes that information given to consumer services may be stored, retained, or used to improve the service unless specific privacy controls are in place (NCSC, 2026). An enterprise agreement with those controls documented is a concrete security difference, not a procurement preference.

Usability also includes guidance at the point of work. Short, task based examples, such as how to summarize a meeting using approved tools without including customer names, teach the boundary more effectively than a policy PDF. Teams should also agree on which tasks are out of scope for AI assistance altogether, for example final decisions on employment, credit, or clinical matters, and state those limits in the same place as the examples. Providing an alternative and providing instruction are separate tasks, and both are required.

Which controls belong in a graduated response?

Graduated controls match the response to the data and the destination, instead of treating every interaction as equal. At the low end, monitoring and awareness: log access to known AI services, publish the approved list, and remind staff of data rules at the point of use. In the middle, warning and justification: Microsoft documents endpoint DLP policies that can warn a user who is about to share sensitive information with a third party generative AI site, or block the action, depending on configuration (Microsoft, 2025). Warning with an override creates a record and a moment of reflection, and its override data shows where the policy and the work disagree.

At the high end, blocking and substitution: prohibit specific services that present unacceptable terms, block uploads of defined sensitive types to unmanaged destinations, revoke OAuth grants that reach regulated data, and remove browser extensions whose permissions exceed their function. High end controls should be reserved for cases where the risk is clear, because overuse pushes activity to personal devices where there is no telemetry at all.

Access control is the thread connecting these levels. NIST's zero trust architecture states that access to individual resources is granted on a per session basis with the least privilege needed for the task, and that access is determined by dynamic policy (NIST, 2020). Applied to AI, that means an AI service or agent should reach only the data its task requires, for the duration of the task, under an identity that can be audited. IBM's finding that 97 percent of organizations with an AI related breach lacked proper AI access controls indicates how often that thread is missing (IBM, 2025).

Incident handling completes the set. When sensitive data has already been shared with an unapproved service, the response includes identifying what was shared, checking the service terms for retention and deletion, recording the event, and deciding whether notification duties arise, with legal advice. A response plan written before the first incident is what keeps that sequence orderly.

How can leaders tell whether handling is working?

Useful indicators are measurable and mostly unglamorous. Coverage: the proportion of discovered AI tools with a completed assessment and a named owner. Speed: the median time from a new tool request to a decision. Substitution: the proportion of disclosed tools that were replaced by an approved alternative within an agreed period. Exposure: the number of DLP events involving regulated data sent to unmanaged AI destinations, tracked over time rather than as a single snapshot. Persistence: the yield of each repeat inventory, which should decline if handling is effective.

Outcome indicators matter as well, but they are slower and harder to attribute. IBM's breach cost findings provide a sector level reason to act, not a scorecard for one organization (IBM, 2025). Leaders should be cautious with vanity measures, such as counting policy acknowledgements or training completions, which show that a communication was sent and not that behavior changed.

A review cadence ties the indicators together. NIST's Manage function is about prioritizing and acting on risk on an ongoing basis, and its Govern function calls for monitoring whether the risk management process itself remains effective (NIST, 2023). A quarterly review that examines new AI features in approved products, changes in vendor terms, repeat disclosure themes, and control override rates will catch drift that an annual review misses. Handling should also be revisited after organizational change, such as an acquisition, because inherited tools and contracts rarely match the acquiring organization's rules.

Where does RedactSure sit?

None of the four steps holds if the approved route cannot do the work people are measured on, and the work that drives most shadow AI use involves sensitive values: a customer record, a claim file, a vendor's bank details. For agent work on that kind of data, RedactSure is the approved route the sequence points to. A supervised AI co-worker completes the browser workflow in the tools staff already know, with no per-application integration and no change to user permissions. The Planner sets which values become tokens on each screen before any model reads it, so the model works with ACCT_001 and PATIENT_001 rather than the real identifiers, and real values resolve only at approved destinations at the moment of an approved action.

A named person confirms that policy beforehand and approves consequential actions at the moment they run, with no always allow, under Supervised Delegation. Every tokenized screen, action, and approval is recorded in the AI Control Record and exports to the customer's own SIEM, so the graduated controls above have a record to run against. Keys stay with the customer and the model is swappable. Deployed in pilot, handling becomes a governed alternative employees can choose, not only a ban they route around. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The page synthesizes published guidance and research, read as of October 13, 2026: the NCSC's 2026 guidance on the hidden risks of shadow AI (official guidance), the NIST AI Risk Management Framework 1.0 and its Generative AI Profile, NIST AI 600-1 (standards and official guidance), NIST SP 800-207 on zero trust architecture (standard), OWASP's Top 10 for LLM Applications 2025 (standards body guidance), IBM's Cost of a Data Breach Report 2025 (industry analysis), the Microsoft and LinkedIn Work Trend Index 2024 (industry survey), and Microsoft Learn documentation on endpoint data loss prevention (vendor documentation). Statistics are cited to their original publishers and describe those publishers' samples, methods, and dates, not a new measurement.

No organization was surveyed or interviewed, and the internal program of no specific organization is reported. No AI service, DLP product, or governance platform was tested hands-on; Microsoft's endpoint DLP behavior is described from its documentation and not from configuration in any tenant. Vendor features and government guidance change, and this page carries its date and is revised when the sources change. The meeting summary, customer record, and claim file examples describe task types, not any organization; no customer or prospect is described. The indicators in the measurement section are practitioner recommendations, not findings from a measured program.

Recommendations are general and must be adapted to sector regulation, employment law, and collective agreements, which vary by jurisdiction. Whether a given control meets an organization's obligations, what consequences an employer may apply to staff, and whether past disclosure to an unapproved service is a reportable event belong to the organization's counsel, assessor, privacy officer, and compliance officer, not to the page.

What the record shows

Handling shadow AI is a sequence, and order matters. Discovery comes first, because rules about unknown use govern nothing. Rules tied to data categories follow, so staff can judge a real task rather than memorize banned names. Graduated controls and monitoring handle the remainder, but none of it holds if the approved route cannot do the work people are measured on. The test is one question: for the task a staff member was doing in an unapproved tool, can the organization name the approved route that does it, and the data categories it may use? Where the answer is a ban and nothing else, the use has not ended; it has moved out of sight.

Frequently asked questions

Is blocking a specific AI service ever the right response?

Yes, as one step inside a graduated response, aimed at a named service or a data category where the risk is clear, and applied with monitoring so its effect can be seen. What the guidance warns against is the blanket ban standing alone, with no approved route for the underlying task. That pattern does not end use; it moves use onto personal accounts and devices where the organization can no longer see it at all.

How often should a handling program be reviewed?

Continuously, on a cycle rather than after an incident. Handling is a continuing process with reassessment because the target moves: approved products keep adding AI features, new services appear, and staff change how they work. A policy reviewed once a year describes an estate that no longer exists. Regular review of discovery results, rule exceptions, and the approved tool list keeps the four parts aligned with the use actually happening.

What is an early sign that handling is working?

The clearest early sign is disclosure behavior: staff surface tools before discovery finds them, ask about borderline uses, and move work onto approved services whose use then grows in the records. The opposite sign is just as informative, an estate where official use looks tidy while gateway and expense signals keep revealing new services. Handling works when the visible picture and the measured picture converge, which is why monitoring stays part of the model rather than a final audit.

Why should AI rules be written around data categories rather than named tools?

Because a list of banned products is obsolete within a quarter, while a data rule applies to a tool nobody has mentioned yet. Public, internal, confidential, and regulated personal data each get an explicit AI handling rule, and staff can test any new service against it. NIST's Generative AI Profile treats leakage and unauthorized disclosure of personal data as a distinct risk, which supports writing rules around data rather than brands.

What should happen when sensitive data has already been shared with an unapproved AI service?

Identify what was shared, check the service's terms for retention and deletion, record the event, and decide with legal advice whether notification duties arise. Consequences for the staff member should be proportionate and predictable; treating every breach as gross misconduct dries up the disclosure the program depends on. A response plan written before the first incident keeps that sequence orderly instead of improvised.

What makes an approved AI alternative usable enough that staff stop using their own tools?

Fast provisioning, a model and feature set close to the consumer tool it replaces, access from the devices staff actually use, and short task based examples tied to real work. The enterprise agreement behind it matters for data reasons: terms on retention, training use, deletion, sub processors, and breach notification. Providing the alternative and providing instruction on it are separate tasks, and both are required.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.