Shadow AI in K-12 Schools: Audit, Detect, Approve, or Block

Current status: Last reviewed August 11, 2026. AI products and interfaces change frequently. This resource explains an operating model and current Tenet product boundaries. It is not legal advice.

Shadow AI in a K-12 school district is any AI product or capability operating outside the district’s recorded inventory, review, approval, or control process. It can be a personal chatbot account, an AI writing panel added to an approved application, a browser tool, a teacher-selected service, or an AI operation inside a district application.

The practical response is not to block every unknown tool automatically. Districts need to find the use, identify its owner and purpose, evaluate the exact product and data path, then choose one of four outcomes: approve it, approve it with conditions, block it, or retire it.

Last reviewed August 11, 2026. Product names, web routes, interfaces, and account controls can change after this review. Districts should validate the exact surface they deploy.

Shadow AI is a governance status, not a judgment about intent

Most shadow AI is not introduced by a person trying to evade policy. It often appears because useful AI capabilities spread faster than district review processes.

Common examples include:

an educator using a free personal AI account for lesson preparation;
a student opening a chatbot the district has not evaluated;
an AI assistant appearing inside a writing, productivity, or learning application that the district previously approved for a different purpose;
a browser add-on or sidebar that can read or transform page content;
a department buying an AI-enabled service outside the central procurement path;
a pilot continuing after its owner, terms, model, or data use has changed;
a district application sending data to a model API without being recorded in the AI application register.

The governance problem is missing context. The district may not know who owns the use, which users are eligible, what data moves, which account terms apply, whether the instructional purpose is approved, or how to stop the use.

The U.S. Department of Education advises teachers to check whether an application is approved and to consult district administration and IT before classroom use. Its broader student-privacy guidance recommends maintaining an inventory of online educational services and applying an approval process to free services as well as paid products. That operating principle applies directly to AI.

Inventory, detection, blocking, and deep support are different controls

These terms answer different questions. Treating them as synonyms creates both blind spots and overclaims.

Control	Question it answers	What it produces	What it does not prove
District AI inventory	What AI uses has the district recorded?	An accountable register with owner, purpose, users, data, deployment, status, and review date	That every real use has been found
Discovery and detection	What unrecorded or unexpected AI might be present?	Leads from records, people, network and identity systems, or browser-visible interface signals	That the tool is unsafe, prohibited, or deeply supported
Approval decision	May this exact use operate under defined conditions?	Approved, conditional, pilot, blocked, or retired status	That policy will be followed without implementation controls
Technical blocking	Can a configured control stop this destination or interface?	A denied site, disabled feature, or covered panel	Complete visibility across every device, app, API, or vendor change
Deep governed support	Can policy be applied inside this named and validated product surface?	Tested product-specific controls such as guidance, supported prompt checks, or DLP	Coverage of every feature made by that vendor

NIST’s AI Risk Management Framework includes an outcome for inventorying AI systems according to organizational risk priorities. It also calls for third-party risks and controls to be mapped and monitored. An inventory is therefore a maintained governance record, not a one-time export of detected domains.

Why a domain list cannot be the whole audit

AI is no longer confined to dedicated chatbot websites. It can appear as a panel, compose button, agent, writing surface, search result, summarizer, or assistant inside an application the district still needs.

A domain-level web filter is useful for governing destinations. It may not distinguish an unapproved AI panel from the rest of an approved learning or productivity site. Conversely, a browser-visible detector may see a panel but know nothing about an AI call made from a native mobile application or a district server.

Use several discovery sources and state what each can and cannot see:

Procurement and contracts: paid products, DPAs, renewals, card purchases, and departmental subscriptions. This can miss free accounts and features added after purchase.
Identity and OAuth records: applications connected to district identities, scopes, users, and administrators. This can miss personal accounts and uses that require no district login.
Managed-device and browser records: installed tools, managed policies, observed destinations, and supported browser-visible interfaces. This can miss unmanaged devices, native apps, and backend calls.
Network and security records: domains and services contacted from district networks. Encryption, shared infrastructure, remote use, and embedded services limit what a domain proves.
Application-owner review: product roadmaps, release notes, enabled features, model providers, and connected data sources. This depends on timely vendor and owner reporting.
People and workflow evidence: surveys, help-desk tickets, classroom walkthroughs, instructional technology teams, student reporting, and a safe self-reporting channel. People may not recognize that a feature uses AI.
Backend application review: model endpoints, service accounts, model aliases, retrieval systems, and tools called by district applications. Browser discovery does not inventory this plane.

No one source is authoritative for the complete environment. Reconcile them into the district AI application register, assign an owner, and preserve the source and date of each finding.

How Tenet detects some browser-visible shadow AI

Tenet Edge includes optional unapproved-AI interface blocking for Tenet Basic and Tenet District on district-managed Chrome. The district must enable the control. Detection runs locally on the managed device and follows two paths.

1. Known-interface signatures

Tenet maintains curated patterns for selected AI chat and writing panels inside web applications. A signature can use the current hostname, route, and browser-visible interface structure to identify a mapped panel with higher confidence than a generic guess.

When a mapped interface is not approved and the district has enabled blocking, Tenet can cover or disable the detected AI panel while leaving the surrounding web application available. The exact response depends on the mapped surface and district configuration.

This path is precise only while the signature and vendor interface still match. A renamed control, changed page structure, new hostname, inaccessible frame, or redesigned application can require retesting and a signature update.

2. Local multi-signal heuristic detection

For an unmapped surface, Tenet can evaluate a combination of browser-visible signals associated with AI chat or generative writing. Examples include an editable prompt area, AI-specific labels, nearby model or assistant language, conversation structure, generation controls, upload affordances, interface attributes, and relevant host or route context.

Tenet uses combined signals and a threshold instead of treating one word such as “chat” as proof. Known safe contexts and district controls reduce unnecessary blocking. Even with those measures, heuristic detection is probabilistic.

A human-support chat, search field, writing form, or redesigned application can resemble AI. An AI interface can also hide its purpose, use unfamiliar language, render inside an inaccessible frame, or avoid the signals the detector knows. Districts should expect both false positives and missed interfaces, provide a reporting route, and review patterns after material vendor changes.

Detection is not deep governed support

A detected panel can be blocked without Tenet claiming that it can apply prompt policy, DLP, classroom guidance, or response monitoring inside that product.

Deep governed support is reserved for a named and validated product surface in the dated Tenet supported-products capability matrix. It requires product-specific testing of the relevant interaction path. The current matrix also separates direct-use web experiences from native applications, files, voice, images, connectors, and newly released features.

This distinction matters operationally:

Detected and blocked: Tenet identifies a covered unapproved interface and stops access to that interface.
Approved but not deeply supported: The district allows a product, but Tenet does not claim in-surface governance capabilities for it.
Approved and deeply supported: The exact named surface has defined and tested Tenet controls for the district’s rollout.
Unknown: The district has not yet established enough evidence to approve, block, or claim support.

Unknown should be a temporary review status, not a permanent assumption of safety or wrongdoing.

Grammarly shows why shadow AI can appear inside an approved tool

Grammarly’s August 2025 product announcement described eight specialized AI agents, a new AI-native writing surface called Docs, and an integrated AI Chat. The company later noted beta availability for Grammarly for Education plans. Those are Grammarly’s product statements, not a claim about district approval or Tenet compatibility.

The example is important because a district may have originally evaluated Grammarly as a writing aid, then encounter a materially different AI surface that can brainstorm, summarize, generate suggestions, evaluate work against rubrics, or provide other agent capabilities. Prior approval of the brand does not automatically answer whether every new feature is appropriate for every student, grade, assignment, data class, or account.

As of this page’s review date, Tenet has a product-specific signature for a validated Grammarly web surface. If that AI panel is outside the district’s approved list and unapproved-AI blocking is enabled, Tenet can block the detected panel while leaving the surrounding web application available. Coverage does not extend automatically to every Grammarly route, product, account, native application, browser surface, or future redesign. Product names are trademarks of their owners, and this example does not state or imply a Grammarly partnership, endorsement, or certification.

Approval, allowlists, and bypasses must remain district decisions

Discovery software should not silently become the district’s policy authority. A district needs an explicit record of which AI products and use cases are approved, conditional, in pilot, blocked, or retired.

For Tenet’s managed Chrome controls:

approved AI products remain governed by the district’s configured approved list;
district allowlists and authorized bypass domains remain authoritative for the applicable blocking layer;
enabling unapproved-AI blocking is a district choice;
detecting an interface does not itself approve the tool or prove misconduct;
a bypass should identify its owner, scope, reason, expiry, and review date;
a materially changed product should return to review even if its domain is unchanged.

A bypass is not a substitute for deep support. It only changes the blocking decision within its configured scope.

A repeatable shadow AI review workflow

Step 1: define the audit boundary

Name the executive sponsor, operational owner, reviewers, covered users, device types, networks, applications, and time period. State whether the audit includes staff use, student use, direct web use, native applications, browser tools, and backend AI operations.

Step 2: collect candidate uses

Pull evidence from procurement, identity, OAuth, managed-device policy, network records, application catalogs, help-desk data, instructional teams, and self-reporting. Record the evidence source and date rather than calling every observed domain an AI application.

Step 3: describe the exact surface

Record the product name, account tier, hostname or application, feature, eligible users, owner, purpose, data sources, outputs, model deployment if known, integrations, and whether the use is direct or backend.

Step 4: triage immediate risk

Escalate a use when it involves sensitive student data, consequential recommendations, action-taking capability, broad OAuth scopes, an unmanaged personal account, no accountable owner, or a product already prohibited by district policy. Triage determines review priority, not a final legal conclusion.

Step 5: make a documented decision

Use one status and define its conditions:

Approved: allowed for the named users, purpose, data, account, and surface.
Conditional: allowed only under documented restrictions such as grade, role, data class, feature, or supervision.
Pilot: time-limited evaluation with an owner, cohort, evidence plan, stop condition, and review date.
Blocked: not permitted in the defined scope, with an approved alternative where practical.
Retired: approval removed and access, credentials, data, integrations, and records handled through a closure plan.

Use the AI tool vetting and approval template and AI vendor and DPA review questions to structure the decision.

Step 6: implement the decision at more than one layer

Depending on the risk and surface, implementation can involve procurement, identity, OAuth, browser and device policy, network controls, application configuration, in-surface controls, training, and classroom expectations. A policy entry without a working control or clear user instruction is incomplete.

Step 7: verify and retest

Test the exact user role, account, route, and feature. Confirm both intended blocks and important non-AI near-misses. Retest after vendor release notes, interface changes, new agents or connectors, account-tier changes, contract changes, or reports of a false positive or missed interface.

Step 8: close the loop

Update the register, communicate the decision, publish an approved alternative when appropriate, set the next review date, and record who can resolve a disputed block. Do not treat a detection event alone as proof that a student or employee violated policy.

Copy-ready 30-day shadow AI audit checklist

Use this checklist in a project ticket, governance meeting, or working document.

Scope and ownership

Name an executive sponsor and one operational owner.
Include technology, curriculum, privacy, security, procurement, accessibility, legal, and school-level representation as appropriate.
Define whether the review covers students, educators, staff, direct use, embedded features, browser tools, native apps, and backend applications.
Set a 30-day collection window and a recurring review cadence.

Discovery

Export current AI and online-service records from procurement and contract systems.
Review district identity applications, OAuth grants, and managed-browser configuration.
Review relevant network and security records without treating a domain hit as proof of use or misconduct.
Ask instructional technology teams and school leaders which AI features are appearing in existing products.
Provide a low-friction channel for staff and students to report useful or concerning AI tools.
Review district-built applications for model APIs, service accounts, retrieval, and agent tools.

Register quality

Give every candidate use an owner or mark it ownerless for escalation.
Record the exact product, account, feature, route, role, and user population.
Document purpose, data sources, outputs, retention, integrations, and model route when known.
Distinguish observed, self-reported, contracted, approved, and technically validated evidence.
Assign approved, conditional, pilot, blocked, retired, or pending-review status.

Controls and verification

Check whether the district needs a full-domain decision, an embedded-interface decision, or deep in-surface governance.
Configure approved lists, blocks, allowlists, and time-bounded bypasses with named owners.
Test current known signatures on the exact managed Chrome route.
Test heuristic blocking against representative AI interfaces and legitimate non-AI forms or human chat.
Document native apps, mobile apps, unmanaged devices, inaccessible frames, APIs, voice, and other unobserved surfaces as coverage gaps.
Publish a route for false-positive and missed-interface reports.

Follow-through

Communicate approved alternatives when a tool is blocked.
Train staff on how to request review before enabling a new AI feature.
Set material-change triggers for new agents, connectors, models, data access, terms, or account types.
Reconcile findings into the district AI application register.
Report counts by status and age without claiming that the inventory is complete.

Measures that reveal progress without overstating certainty

Track the health of the process, not a fictional percentage of all AI that has been found.

Useful measures include:

candidate uses awaiting an owner;
known uses with a documented purpose, user group, data boundary, and review date;
median time from discovery to a recorded decision;
conditional approvals and bypasses past their expiry date;
material vendor changes awaiting retest;
false-positive and missed-interface reports resolved within the district target;
blocked uses with an approved alternative communicated to affected users;
backend AI applications recorded separately from direct-use web tools.

Avoid reporting “100 percent of AI detected.” The relevant denominator is unknowable when products, personal accounts, embedded features, and backend systems continue to change.

Frequently asked questions

What is shadow AI in K-12 schools?

Shadow AI is an AI product, account, embedded feature, browser tool, or backend use that operates outside the district’s recorded inventory, evaluation, approval, or control process. It can be useful, harmful, or neutral. Shadow describes the governance gap, not the intent of the person using it.

How can a school district find shadow AI?

Combine procurement and contract records, identity and OAuth grants, managed-browser configuration, network records, application catalogs, staff and student reporting, classroom workflow reviews, and browser-visible interface detection where appropriate. No one source provides a complete inventory.

Can a web filter detect AI embedded inside an approved website?

A domain-level filter can allow or block a destination, but an AI panel can appear inside a site the district still needs. Browser-visible interface controls can address some supported embedded panels without blocking the surrounding application. Coverage depends on what is visible to the managed client and on the current vendor interface.

Does Tenet detect every AI chatbot or writing tool?

No. On district-managed Chrome, Tenet can check curated interface signatures and local multi-signal patterns when the district enables unapproved-AI blocking. It can miss an interface, and a heuristic can produce a false positive. Native apps, mobile apps, unmanaged browsers, inaccessible frames, APIs, voice interactions, and vendor changes are not universally covered.

Can Tenet block Grammarly AI without blocking all of Grammarly?

On a currently validated Grammarly web surface, Tenet can use a product-specific signature to block a detected unapproved AI panel while leaving the surrounding web application available. This does not cover every Grammarly product, route, account, or future interface, and it does not imply a Grammarly partnership or endorsement.

Is detecting an AI interface the same as governing it?

No. Detection can support a discovery or blocking decision. Deep governed support requires a named and validated product surface where specific policy, guidance, DLP, or response controls have been tested. A detected interface does not automatically gain those capabilities.

Primary references

For a district-wide operating model, continue with how school districts govern student AI tools, the K-12 AI governance guide, K-12 AI data boundaries, why data loss prevention matters in K-12 AI, and the state K-12 AI laws and guidance tracker.