Block vs Sanction vs Coach: Choosing a Shadow AI Stance per App and Data

Most organisations answer "should we block ChatGPT?" once, for every AI tool and every kind of data, and then discover that the answer was wrong for half of them. Blocking, sanctioning an approved tenant and coaching users in the moment are three different control stances, each with its own enforcement point, its own leakage paths left open and its own way of pushing use out of sight. This guide sets out decision criteria for choosing a stance per AI app and per data class, what each stance actually enforces, where users go when you apply it, how to measure it, and when to move an app from one stance to another. It is written for CISOs, SSE and DLP owners and AI governance leads who already have discovery in place and need a defensible policy for what to do with what they found.

Key takeaways

• Choose a stance per app and data class, not per organisation. The same consumer chatbot can be blocked for source code, coached for internal documents and allowed for public text.
• Every stance leaves a path open. Blocking misses personal devices and OAuth grants; sanctioning misses personal accounts on the approved app; coaching relies on the user making the right choice.
• Blocking without an alternative displaces use. The NCSC notes shadow IT is rarely malicious and usually means sanctioned tools fall short, so a block needs a sanctioned route on the same day.
• Sanctioning is a contract and an identity decision. An approved enterprise tenant only helps if sign-in is forced through corporate identity and personal instances of the same app are restricted.
• Measure movement, not just blocks. Track blocked, coached, proceeded and switched-to-sanctioned events per app; falling coaching overrides and rising sanctioned use show the policy is working.

The short answer

Block AI apps whose terms or ownership make them unacceptable for any company data, and block every app for your most sensitive data classes regardless of stance elsewhere. Sanction one or two enterprise AI services that cover most demand, with contracts, single sign-on and logging, and steer users to them. Coach on everything in between: unreviewed but low-risk apps, and medium-sensitivity data in apps that are not yet approved. Review the stance of each app on a fixed cycle and when triggers fire. The control tooling is the same for all three (a secure web gateway or CASB in an SSE platform, browser controls, DLP and identity), so the stance is a policy decision, not a product decision. For which tool sees which traffic, see AI Gateway vs CASB/SSE for Controlling Shadow AI.

The three stances compared

Block: threat model, architecture and failure modes

Threat model: the risk you are removing is sensitive data reaching a service whose terms allow training on inputs, whose retention or jurisdiction is unacceptable, or whose operator you cannot assess. OWASP LLM02:2025 Sensitive Information Disclosure notes that users need to understand the risk of unintentionally providing sensitive data that may later appear in model output. Blocking also suits apps that request broad account access, and agent tools that act on systems.

Architecture in words: traffic from managed endpoints and offices is steered to an SWG or SSE proxy; the destination is matched against a URL category or app catalogue entry for generative AI; a rule denies the request and shows a block page. DNS filtering adds a coarse layer for devices outside the proxy. For API use, egress firewall rules deny direct connections to model provider endpoints except from an approved gateway. See the Secure Web Gateway and Web Filtering Guide.

Displacement: a blocked user with a real need moves to a personal phone, a home laptop or a mobile app on a cellular network, where you have no visibility at all. The block counter still shows success. The NCSC warns that blaming or punishing staff makes their peers reluctant to report their own unsanctioned practices.

Paths left open:

• OAuth grants: a block on the website does not revoke a grant already given to the AI app on a corporate mail or file account. In the Vercel Context.ai OAuth breach, an employee's broad grant to a consumer AI suite was later used to take over the employee's corporate account. See the Consent Phishing and Illicit OAuth Grants Guide.
• Embedded AI features: assistants inside already sanctioned SaaS use the SaaS vendor's domain and pass straight through an app-level block.
• Browser extensions and desktop apps: these may call APIs on domains your category does not cover.
• New and renamed services: catalogue coverage lags launches.

Failure modes: blanket category blocks that also break sanctioned tools; exceptions granted by email with no expiry; and treating the block as the control while the data exits from personal devices.

Sanction: threat model, architecture and failure modes

Threat model: sanctioning accepts that AI use will happen and moves it into a service you have assessed. The residual risks are the vendor itself (retention, sub-processors, breach), over-sharing inside the tenant, and employees using a personal account on the same service instead of the corporate one.

Architecture in words: procurement signs an enterprise agreement that states whether inputs are used for training, retention periods and data location; the tenant is connected to the identity provider with single sign-on and group-based licensing; the SSE platform applies instance or tenant restrictions so that only the corporate tenant of that service is reachable from managed devices; DLP and audit logging run on the tenant; OAuth app consent is limited to admin-approved apps. NIST AI 600-1 suggests maintaining approved GenAI provider lists (GV-6.1-007), updating acceptable use policies to cover GenAI (GV-6.1-010) and including data privacy and security in vendor due diligence (GV-6.1-009). See the AI Acceptable Use Policy Template.

Displacement: low, as long as the sanctioned tool meets demand. If it lags the consumer version in features or models, power users drift back to personal accounts, which is why measurement of sanctioned share matters.

Paths left open:

• Personal accounts on the approved service: the domain is allowed, so without tenant restrictions or inspection a user can sign in personally. The NCSC notes that a CASB will not identify unapproved use of approved cloud services without intercepting encrypted traffic.
• Over-broad tenant access: an assistant connected to all company files returns what users could reach but never found. Fix permissions before connecting data sources.
• Feature creep: vendors enable new agent, plugin or connector features after approval; each needs review.
• Agents and API keys: developers using personal keys for the same provider bypass the tenant entirely. Route them through an approved AI gateway. See the AI Gateway and LLM Gateway Guide.

Failure modes: approving a tool and never removing the block on the category, so users see conflicting messages; approval without SSO; and approval treated as permanent although the vendor's terms change.

Coach: threat model, architecture and failure modes

Threat model: coaching accepts residual risk in exchange for visibility and learning. It suits apps that are not yet reviewed, data that is internal but not restricted, and periods when a sanctioned alternative is being rolled out. The risk you carry is the user who proceeds with data they should not share.

Architecture in words: the SWG, CASB or browser control intercepts the visit or the upload and shows a notice: what the policy is, which tool is approved, and a choice to switch or proceed with a typed business justification. The event is logged with user, app, action and justification. DLP can sit behind the coaching prompt and still hard-block specific content, such as source code or payment card data. In-browser controls can coach on paste and upload actions inside the page, which network controls cannot see. See the Enterprise Browser and Browser Security Guide and the Endpoint DLP Guide.

Displacement: lowest of the three, because the user is not denied; the cost is that some users stop reading the prompt.

Paths left open:

• Click-through: justification fields filled with a single character. Review them and escalate repeat patterns to a manager conversation, not a penalty.
• Unmanaged devices: no prompt appears on a personal laptop.
• Content the prompt does not inspect: coaching on the visit does not inspect each paste unless browser or DLP controls are in the path.

Failure modes: coaching prompts that fire on every page load, causing fatigue; prompts that say "this is risky" without naming the approved alternative; and justifications nobody reads. EU AI Act Article 4 requires providers and deployers to take measures to support AI literacy among staff using AI systems, applicable from 2 February 2025; well designed coaching is one practical contribution, alongside training.

Decision criteria per app and data class

Classify each discovered AI app into a risk tier using its terms and access, then read the stance from the matrix against your data classification. Discovery methods are covered in the Shadow AI Discovery Guide and the Shadow SaaS and Unsanctioned App Discovery Guide.

Use these questions to place an app in a tier:

1. Training and retention: do the terms allow training on inputs, and can it be turned off for business accounts?
2. Access requested: does it ask for OAuth scopes on mail, files or calendars, or run as an extension with page access?
3. Action capability: can it take actions (send, commit, purchase) rather than only answer?
4. Operator and jurisdiction: is the operator identifiable, and where is data processed?
5. Demand: how many users and teams use it, and for what? High demand with acceptable terms is a candidate for sanctioning, not blocking.
6. Substitute: does a sanctioned tool already meet the same need?

Small versus large organisations: a small organisation without an SSE platform can sanction one enterprise AI service, block the riskiest category through DNS filtering and manage OAuth consent at the identity provider, accepting coaching through policy and training rather than prompts. A large organisation can run the full matrix with per-group policies, but must staff the review queue, or the "not yet reviewed" tier becomes permanent.

When to move between stances

Run the review every quarter and on any trigger. Record each decision, the evidence and the owner in the AI register described in the Shadow AI Policy Template.

How to implement

1. Baseline: run discovery in monitor-only mode for two to four weeks; list apps, users and volumes.
2. Sanction first: stand up at least one enterprise AI service before any broad block, with SSO and logging.
3. Coach the category: switch the generative AI category to coaching, with the approved tool named in the prompt.
4. Block the top tier: apply blocks to prohibited apps and DLP blocks for restricted data, in a pilot group first.
5. Close side doors: restrict user OAuth consent to admin-approved apps, review existing grants to AI apps, manage browser extensions and restrict direct model API egress to the approved gateway.
6. Roll out in rings: extend from pilot to departments; keep a rollback rule that returns a group to coaching if a block breaks a business process.
7. Review: run the quarterly stance review and publish changes to staff.

Worked scenario

A 3,000-person professional services firm finds 140 AI apps in proxy logs. Two consumer chat assistants account for 80% of traffic; legal staff are pasting client documents. The firm already licenses a productivity suite with an AI assistant.

• Sanction: the suite's assistant is enabled for all staff with SSO, the firm's sensitivity labels and audit logging; it becomes the named alternative on every prompt.
• Coach: the two popular chat assistants move to coaching for internal data; DLP blocks uploads carrying the "Client Confidential" label.
• Block: 30 apps whose terms allow training on inputs and all AI browser extensions not on an allow list are blocked; 12 OAuth grants to AI apps are revoked.
• Result after one quarter: the firm tracks coaching proceed rate, the share of AI sessions in the sanctioned tool and DLP blocks on client data, and moves one specialist legal research tool from coaching to sanctioned after a vendor review.

The lesson from the Samsung ChatGPT source code leak applies: written warnings alone did not stop staff pasting source code into a public tool, and the response was a restriction on company devices. Combining an approved alternative with enforced data controls avoids having to choose between a leak and a ban.

Detection and measurement

Log every stance decision as an event: user, device posture, app, app tier, data class (where DLP classifies it), action (blocked, coached, proceeded, switched) and justification. Correlate with OAuth grant events from the identity provider and with egress to model APIs. Exfiltration of files to a web service maps to ATT&CK T1567 Exfiltration Over Web Service. See the AI Usage Monitoring Guide and the Proxy and Web Gateway Log Detection Guide.

• Sanctioned share: AI sessions in sanctioned tools as a share of all observed AI sessions; should rise each quarter.
• Coaching proceed rate: proceeded events divided by coached events, per app; a falling rate means users are switching.
• Block attempt trend: repeated attempts per user on blocked apps; a rise without a falling trend signals unmet demand.
• Restricted data DLP hits: blocked uploads of restricted data to any AI app, per 1,000 users.
• Review backlog age: median days an app spends in "not yet reviewed".
• AI OAuth grants: count of active user-consented grants to unapproved AI apps (target zero).

Common failure patterns

• Ban first, alternative later: use moves to personal devices and the organisation loses all visibility.
• Allowing the domain, not the tenant: sanctioning a service without tenant restrictions lets personal accounts through the same door.
• Ignoring OAuth and extensions: web blocks leave existing grants and extension access in place.
• Coaching with no destination: prompts that warn without naming the approved tool train users to click through.
• Static decisions: stances set once and never reviewed while vendor terms and features change.
• Punitive follow-up: disciplining people who proceeded stops voluntary declaration of new tools.

Framework mapping

Practitioner checklist

• Define app tiers and data classes, and publish the stance matrix.
• Stand up at least one sanctioned AI service with SSO and logging before broad blocking.
• Apply tenant or instance restrictions so only corporate accounts reach sanctioned services.
• Name the approved alternative on every block page and coaching prompt.
• Restrict user OAuth consent and review existing grants to AI apps.
• Control AI browser extensions and direct model API egress.
• Log blocked, coached, proceeded and switched events with justifications.
• Review stances quarterly and on vendor term changes, incidents or demand shifts.
• Track sanctioned share, proceed rate and restricted-data DLP hits for the risk committee.

Standards and references

• NCSC: Shadow IT
• NIST: AI 600-1 Generative Artificial Intelligence Profile
• OWASP: LLM02:2025 Sensitive Information Disclosure
• EU AI Act: Article 4 AI literacy

Related NHI Mgmt Group resources: Shadow AI Policy Template · AI Usage Monitoring Guide · AI Gateway vs CASB/SSE for Controlling Shadow AI · AI Usage Control and Shadow AI