Zero-Day AI: How to Detect Unlisted AI Tools

An employee finds a document summarizer through a colleague's Slack message, opens it, and pastes in an executed vendor contract. Thirty seconds later they have a clean summary and they move on with their day. The tool sends that contract to a large language model through its own backend, retains it for an unknown period under terms nobody read, and none of this is unusual enough for anyone to think about twice.

Your security stack handled this correctly. The traffic was inspected, the session was logged, and no policy was violated, because no policy exists for a domain nobody has ever evaluated. The tool is not blocked, not approved, and not on any list.

Most AI security products will not surface this as a gap. They will surface it as low risk, because the risk score has no inputs for an application that was never inspected in the first place. The unknown tool ends up ranked safer than the sanctioned one beside it.

This article covers how to detect AI applications that appear on no list: the behavioral signals that identify one, how to attribute a background API call to the site that made it, what a risk model for discovered tools actually has to measure, and where the approach stops working.

What Is a Zero-Day AI Tool?

A zero-day AI tool is an AI application observed in an organization's environment that has not yet been classified as approved or unapproved. The application exists in traffic but not in the inventory, which means no security decision has been made about it.

The term borrows its shape from zero-day vulnerabilities, but the parallel is narrower than it first appears. A zero-day vulnerability describes something exploitable that has not been patched, whereas a zero-day AI tool describes something that has never been evaluated at all.

The application may well be a competently run commercial product with a SOC 2 report and a defensible data retention policy, or it may be a two-person side project routing every uploaded document through a third-party API with no deletion guarantee behind it.

From the security team's position those two cases are indistinguishable, because the information that would separate them has never been gathered. The exposure is not malice on the part of the tool; it is the absence of a decision on the part of the organization.

How Zero-Day AI Differs From Shadow AI

Shadow AI and zero-day AI describe different failures, and treating them as the same problem produces the wrong control.

That distinction has real operational weight, because every enforcement control an organization deploys (blocking, redaction, prompt inspection, session recording, conditional access), presupposes that the target application has already been identified. You cannot write a policy against a domain you have never seen, and you cannot inspect prompts flowing into an application your interception layer does not know to intercept. Discovery is therefore not simply a step that happens to come before governance in the sequence; it is the constraint that determines how much of your environment governance can reach at all.

Ai Tools Categorization for Shadow AI

Most AI inventories model two states, approved and unapproved, and that binary is where the problem hides. A tool nobody has assessed belongs to neither category.

Approved and unapproved are both outcomes of a review process. Unclassified is the absence of one, and it is the only state in which the organization holds no information whatsoever about what the application does with the data it receives.

An inventory that renders only two states has to force every observed tool into one of them, and in practice that means unclassified applications end up treated as permitted. Not through a deliberate decision, but because nothing in the system is designed to flag the absence of a decision as a finding in its own right.

Removing that default is the entire purpose of zero-day AI detection: once a tool is identified and moved out of the unclassified state, it becomes governable through the same process as everything else in the environment, and until that happens it sits outside every control the security team has built.

Why Shadow AI Shows as Low Risk

Shadow AI and zero-day tools show as low risk because the risk score is derived from prompt-scan telemetry (usage volume, exposure rate, block rate) and a discovered tool never enters the prompt-scanning pipeline. Those inputs return zero not because the tool is safe but because nothing measured it, and the formula then reads zero exposure as low exposure and renders the badge accordingly.

What appears on the dashboard in this situation is an artifact of the scoring formula rather than the output of a security assessment, and it will appear in any product that displays a single unified risk column across both inspected and discovered applications. The mechanism is worth working through in detail, because it is the process by which an AI inventory quietly inverts and starts presenting its best-monitored tools as its largest exposures.

How Prompt-Derived Risk Scoring Works

Risk scoring for a supported AI application rests entirely on interception. When an AI tool is on the catalogue and its traffic is being inspected, the security platform can observe every prompt submitted to it and produce three primary measurements:

• Usage — the number of prompts or sessions scanned for that application over a given time window
• Exposure rate — the share of those prompts that contained sensitive data, whether PII, credentials, source code, or regulated records
• Block rate — the share of exposed prompts that policy actually stopped before they reached the model

Residual risk is then calculated as the gap between what was exposed and what was blocked, weighted by usage volume, so that an application with heavy usage, a meaningful exposure rate, and imperfect blocking scores high while an application with light usage and consistently clean prompts scores low.

The model is sound and, applied to catalogued applications, it produces a ranking that reflects real exposure. Every term in it, however, is a measurement taken from the interception path, which means the model only works for applications that traffic through that path in the first place.

Why the Formula Degenerates on Discovered Tools

A discovered host sits outside the interception path by definition, since it was never on the catalogue that determines what gets inspected. Its prompts were never scanned, so usage, exposure rate, and block rate all evaluate to zero, and running the residual-risk calculation across three zeros produces a low score in every case.

The distinction that disappears here is between a zero that means nothing was found and a zero that means nothing was looked for. These are opposite conditions with an identical numerical representation, and the formula has no way to tell them apart. An application with a measured exposure rate of zero has been inspected across hundreds of prompts and found consistently clean, which is genuinely reassuring.

An application with an unmeasured exposure rate of zero has been inspected zero times, which tells you nothing at all. Both values arrive at the badge rendering logic looking the same, and both produce LOW.

The consequence is an inventory in which the visible risk of an application varies inversely with how much the organization actually knows about it:

The two applications the organization has invested most heavily in monitoring appear as its largest risks, while the application nobody has evaluated appears as its smallest.

A CISO reading this dashboard would reasonably conclude that the sanctioned deployments are where the exposure sits and that the discovered tool can wait for the next review cycle, when the situation is closer to the reverse: the applications ranked high are under active DLP inspection with a 94% block rate, and the one ranked low is receiving pasted contracts with no inspection whatsoever.

The Compliance Consequence

The scoring error stops being a dashboard inconvenience and becomes an audit problem as soon as the inventory is used as evidence, which is what both ISO 42001 and the EU AI Act require organizations to do. Each expects an accurate register of the AI systems in use, together with a demonstration that risk has been assessed for every entry in it.

An inventory row asserting LOW for an application that was never assessed does not represent an understated risk rating; it represents an unsupported claim about a system nobody examined. When an auditor selects that row and asks what the rating was based on, the honest answer is that it was produced by a formula operating on absent inputs, and at that point the credibility of every other rating in the register comes into question alongside it.

The underlying issue is the difference between a risk rating, which is the output of a measurement, and a risk assertion, which is a value the system generated because the field could not be left empty.

Null Is the Correct Value for an Unassessed Tool

An application that has not been assessed should return null rather than LOW, and the interface should render that null honestly, as an unassessed state, as "Assessing," or as no badge at all, instead of substituting the lowest severity available in the enum.

Most products avoid this because a suppressed badge reads as a gap in the product rather than a gap in the data, and defaulting to LOW keeps the interface looking complete. The gap is real, though, and displaying it is the accurate behaviour.

An empty badge invites someone to ask why the tool has not been assessed and creates a visible piece of work; a LOW badge closes the question before anyone thinks to ask it, converting the absence of evidence into an apparent finding of safety and filing it under a green label where nobody will revisit it.

Two design rules follow, and both apply to any AI inventory regardless of who built it:

• Never default an unmeasured application to the lowest severity. Unmeasured and low-risk are different states and need to be visually distinct so that the first one generates work rather than reassurance.
• Never score discovered tools with a formula built for inspected ones. Discovered hosts produce a different class of telemetry entirely, which means they require a separate risk model built on the signals they actually generate like detection confidence, personal-data egress, and traffic posture.

The second rule is considerably harder to satisfy, because it means building a second scoring path rather than reusing the one already running in production, and what that model needs to measure is covered later in this article. None of it applies, however, until the tool has been found in the first place, and the reason unlisted tools stay undiscovered for so long is that almost every detection method in the category works by looking them up in a list.

Why Signature-Based Detection Misses Unlisted AI Tools

Signature-based discovery resolves a hostname from network traffic and matches it against a catalogue of known AI applications, which means an AI tool whose hostname is absent from that catalogue produces no match at any confidence threshold.

This is not a low-confidence detection that a tuning pass could recover, but the complete absence of a detection event, because the only mechanism the system has for recognising an AI application is a lookup that returns nothing at all.

Definition: Signature-based AI detection is a discovery method that identifies AI applications by matching observed hostnames against a maintained catalogue of known AI domains. Detection coverage is bounded by catalogue completeness, so an AI tool absent from the catalogue generates no detection event regardless of its behaviour.

This limitation is neither hidden nor disputed by the vendors who build these systems, and it appears plainly across the category's own product documentation:

• Microsoft Global Secure Access describes its discovery process as analyzing network traffic, inspecting internet and Microsoft 365 traffic to detect connections to known generative AI applications, SaaS MCP servers, and AI model provider frameworks.
• Auvik describes the same architecture from the endpoint side, noting that its browser extensions analyze web traffic patterns and identify visits to known AI platforms drawn from the vendor's database.
• Sola differentiates on breadth rather than method, correlating findings across eleven sources including Okta, Entra ID, Google Workspace, CrowdStrike, SentinelOne, GitHub, GCP, and Azure, which widens the number of surfaces the catalogue is applied to without changing what happens when a hostname is not in it.

The operative qualifier in every one of these descriptions is known, and it establishes the effective ceiling of the approach regardless of how many observation points feed into it. An unlisted tool fails to match across eleven correlated data sources exactly as reliably as it fails to match against one.

The Three Ways an AI Catalogue Falls Behind

A catalogue represents what the vendor had identified at the moment the snapshot was taken, and three independent forces push the live environment past that snapshot faster than any update cycle can close the gap.

1. Net-new AI products. New AI applications reach general availability continuously and can enter an employee workflow within minutes of launch through a link shared in a Slack channel or a recommendation in a newsletter. Catalogue updates run on the vendor's release schedule rather than the market's, so the interval between a tool becoming usable and that tool becoming catalogued is a window in which it operates entirely unobserved, and that window reopens with every new product launch.

2. AI features added to already-approved SaaS. This vector is considerably harder to address because it does not involve a new domain at all. Existing SaaS products routinely add AI capabilities to applications reviewed and allowlisted years earlier for an entirely different purpose:

   • A project management tool ships an AI meeting summarizer
   • A CRM adds a generative email assistant
   • A support desk introduces automated ticket drafting
   • A design tool adds image generation with an upload surface

Each of these sits on a domain already on the approved list, categorised as non-AI. Because no hostname changed, a signature-based system has no trigger prompting it to re-evaluate the application, and the AI capability inside an approved product remains invisible precisely because the product itself is approved.

3. White-labelled model access. A product presents a chat interface on its own domain and calls a commercial model API from its own backend. The employee sees a vendor-branded interface throughout and never encounters an AI provider's domain in the browser at any point in the interaction, so the catalogue has no entry to match against the front-end domain. The only observable evidence that a language model is involved appears in a request the page makes in the background, and most systems attribute that request to the API vendor rather than to the site that initiated it, producing a misleading log entry rather than a finding.

What Each Shadow AI Detection Method Can and Cannot See

Detection methods differ in where they observe traffic, but most share the same resolution layer and therefore inherit the same constraint from it.

The distinction separating the final row from everything above it is the question being asked rather than the quality of the answer:

• Catalogue-driven methods ask: Does this hostname appear on a list? For an unlisted tool this resolves to no every time, regardless of how much telemetry informs it.
• Behavioral classification asks: Is this origin behaving like an AI application? This question can be answered about a domain no vendor has ever catalogued.

That difference is why behavioral classification produces findings the first five methods cannot generate at all, rather than simply producing the same findings more efficiently.

Why Client Placement Determines How Much AI Traffic Is Visible

Beyond the catalogue limitation, the position of the detection client within the environment determines how much traffic is available for classification in the first place, and browser extensions occupy the most constrained position among the placements in common use.

An extension observes traffic only within the single browser it is installed in, which produces two compounding gaps:

• Cross-browser blindness. Employees frequently maintain a work profile in one browser and a personal profile in another, and unapproved tools appear disproportionately in the personal profile where corporate extensions are not installed.
• Native client blindness. Most major AI vendors now ship desktop applications alongside their web interfaces, and none of that traffic passes through a browser extension.

A deployment built on extensions therefore operates with two independent blind spots at once, since the catalogue limits which tools it can name and the browser boundary limits which traffic it can examine before naming becomes relevant.

A client that terminates TLS at the device level removes the browser-boundary constraint by observing traffic from every browser on the machine as well as from native applications routing through the system network stack, which brings Electron-based AI desktop clients into scope alongside conventional web usage.

LangProtect's zero-day AI detection runs at this layer through the Guardia desktop interceptor, which classifies traffic as it passes rather than reconciling logs after the fact, and applies the catalogue match and the behavioral classification path as two separate stages within the same inspection flow.

Certificate pinning in some native applications still defeats interception, and that limitation together with several others is examined later in this article, but the observable surface available at the device layer is substantially larger than any single browser can provide.

Neither placement resolves the catalogue problem on its own, since observing more traffic only produces additional findings if the classification layer can recognise an AI application it has never encountered before. That capability depends on evaluating what an origin does rather than what it is called, which is the mechanism the next section describes.

How Behavioral Zero-Day AI Detection Works

Behavioral zero-day AI detection classifies an origin by what it does rather than by what it is called, evaluating how a site is built, how its traffic behaves, and whether it provides a working path for data to leave the organization. Because none of these signals depend on the hostname appearing in a catalogue, the method produces findings for AI applications no vendor has indexed, which means the discovery gap closes in days rather than at the next catalogue refresh.

Definition: Behavioral AI detection is a discovery method that identifies AI applications from observable characteristics, interface composition, traffic behaviour, and outbound model API calls, rather than from hostname matching. Detection coverage is bounded by inspection reach rather than catalogue completeness.

LangProtect runs this classification inside Guardia's desktop interceptor at the point of TLS termination, so an unlisted tool surfaces during the session in which it is first used rather than during a later reconciliation pass. The operational consequence is the one security leaders care about:

• Time to discovery drops from a review cycle to a working day
• Coverage extends to every browser on the device and to native AI clients, not one browser profile
• Findings arrive with context, so the security team assesses rather than investigates from scratch

What Signals Identify an Unlisted AI Tool?

Classification draws on four families of evidence, each answering a different question about the origin.

No single family produces a verdict, because each appears independently on sites that are not AI applications:

• A text box alone describes a contact form
• A streaming response alone describes a video player
• An embedded SDK alone describes a marketing demo

LangProtect classifies on the combination rather than any individual signal, weighted against a corpus of confirmed AI applications and confirmed benign sites. That weighting is what keeps the finding queue small enough for a security team to work through, which is ultimately what determines whether a discovery feature gets used or muted.

Why Attribution Determines Whether Your AI Inventory Is Accurate

The most consequential design decision in the pipeline is not how an AI tool is recognised, but which site the finding gets recorded against.

When an employee uses a white-labelled AI product, the browser generates two distinct requests:

1. The employee opening the site — a navigation to a domain no catalogue contains
2. The site calling a model provider in the background — on the employee's behalf, without the provider's name ever appearing in the interface

Systems that match hostnames without distinguishing between these two cases record the second request as a visit to the model provider, producing an inventory that reports usage of a tool the employee never opened while the tool they did open never appears at all.

The metadata needed to separate these cases is already present in the traffic; the question is whether the detection layer can read it. Because Guardia terminates TLS at the device layer, LangProtect has access to that metadata and attributes every background model call to the origin that initiated it. A passive network tap observes only the connection to the model provider and has no access to the information identifying which site made it, which is why tap-based deployments consistently attribute background calls to the wrong application.

The same principle governs embedded widgets, where LangProtect attributes the finding to the page host rather than the widget vendor. This vector deserves particular attention from security leaders because widget-delivered AI is one of the most common ways an approved application acquires an unreviewed AI surface:

• The domain on the allowlist has not changed
• No vendor notice was issued to the security team
• A chat interface backed by a language model is now accepting employee input on a page the organization sanctioned for something else entirely

How LangProtect Controls False Positives in AI Discovery

Before an origin is classified as zero-day AI, it must satisfy one further requirement, and this one is absolute rather than weighted.

The site must present a working path for data to leave the organization like a text submission surface, a file upload control, or a media capture input. An origin displaying AI-shaped behaviour without any of these does not become a finding.

This condition exists because the dominant false-positive class in behavioral detection is marketing content about AI products. A vendor homepage describes a language model, loads AI tooling for its own demo, and may stream a scripted response through an animated interface, producing a signal profile that resembles a working AI application while offering no route for an employee to submit anything to it.

The business case for the gate is straightforward:

• A discovery feature generating fifty findings a week, forty of which are vendor homepages, gets muted within a month
• A muted feature provides no visibility at all, which returns the organization to the position it started from
• Precision, not recall, is what determines whether discovery output ever reaches a decision

LangProtect therefore applies classification as a conjunctive condition rather than a purely additive score: an origin qualifies as zero-day AI only when the weighted signal evidence clears its threshold and a genuine egress path exists.

What a Zero-Day AI Finding Delivers to the Security Team

An origin clearing both conditions produces a structured finding rather than an alert, because the appropriate response is assessment rather than immediate blocking. Each LangProtect finding carries the context required to make a decision without further investigation:

• The site the employee actually opened, never the model API it reached in the background
• When it was first observed, which establishes how long the tool has been in the environment
• How data can leave — text entry, file upload, or media capture
• Which model providers received traffic, recorded as supporting evidence rather than as separate findings
• How many distinct employees used it, which separates one person's experiment from departmental adoption
• Classification state, which opens as unclassified because that is the accurate value and the one that generates review work

That final field carries more weight than its size suggests. A finding that arrives unclassified prompts a decision, while a finding that arrives carrying a risk level the system had no basis to assert prompts nothing at all. The section that follows examines what accurate risk assessment for discovered AI tools actually requires.

What Wrong Attribution Costs a Security Team

Attributing a background model API call to the API provider rather than to the site that made it produces an AI inventory containing sessions that never occurred, and every downstream process reading that inventory inherits the error. Enforcement policy lands on the wrong domain, usage reporting overstates the tools under management, and the audit record names systems the organization never used.

The mechanism is straightforward and covered in the previous section. What follows is what the error costs once it reaches the people who act on the data.

Four Downstream Failures From Misattributed AI Traffic

A single incorrect attribution propagates into four distinct operational problems, each affecting a different function.

The fourth failure is the one that persists longest, because the other three at least produce something visibly wrong that someone eventually questions. A missing row produces nothing. The tool continues receiving employee data for as long as the misattribution stands, and no report anywhere in the organization indicates that it exists.

Why Misattribution Breaks Enforcement Before It Breaks Reporting

Reporting errors are recoverable, because a number that looks wrong invites scrutiny and eventually gets corrected. Enforcement errors are not, because the policy appears to be working.

When a background model call is logged as a visit to the model provider, the security team's natural response is to write policy against that provider, restricting access, requiring enterprise accounts, or applying prompt inspection to its domain. Each of those controls will function correctly and produce clean policy-hit telemetry. None of them affects the actual data path, because employees are not reaching the model provider directly:

• The employee submits data to the unlisted site, which remains unrestricted
• The unlisted site forwards that data to the model provider from its own backend
• Backend traffic never passes through the browser, so no browser-level control applies to it
• Policy dashboards show enforcement working as configured

The organization now holds documented evidence of a control that does not cover the path it was written for. This is a materially worse position than having no control at all, because the residual risk has been formally recorded as addressed.

The Compliance Exposure in an Inaccurate AI Register

Both ISO 42001 and the EU AI Act require an accurate register of AI systems in use, and accuracy is bidirectional. A register that omits systems in use fails the completeness requirement, and a register that lists systems not in use fails the accuracy requirement.

Misattribution produces both failures simultaneously from the same underlying error, which is what makes it difficult to defend during an assessment:

• The omission is the unlisted AI tool that received employee data and never appeared in the register
• The overstatement is the model provider recorded as having sessions no employee initiated

An assessor testing a sample of register entries against user activity will find rows that cannot be substantiated, and the finding rarely stays contained to those rows. Once the provenance of one entry is shown to be unreliable, the evidentiary weight of the entire register drops, including the entries that were correct. Organizations in this position typically discover that the remediation cost is not correcting the inventory but rebuilding confidence in it.

What Correct Attribution Delivers

LangProtect attributes every background model API call to the origin that initiated it, which produces a register where each entry corresponds to something an employee actually did.

The practical outcomes for a security team:

• Visit counts reflect real usage, so risk prioritisation reflects real exposure
• Enforcement targets the site receiving the data, not the provider it forwards to
• Model API egress appears as evidence on the correct record, strengthening the case for reviewing that tool rather than creating a phantom record elsewhere
• Every register entry is defensible, because it traces to an observed employee session

The register is only as useful as the decisions made from it, and decisions made from misattributed data are wrong in ways that are difficult to detect and expensive to unwind.

Why Discovered AI Tools Need Their Own Risk Model

Discovered AI tools require a separate risk model because the telemetry they produce is fundamentally different from the telemetry that prompt-inspected applications produce. A model built on prompt exposure and block rates has no valid inputs for a tool that was never inspected, which is why it returns a low score by default rather than an assessment.

Building a second scoring path is more work than reusing the one already in production, and it is the only approach that produces a defensible number. What follows is what such a model has to measure, framed as a requirement of the problem rather than a description of shipped functionality.

Three Inputs a Discovery-Native Risk Model Requires

A discovered host generates a narrow but genuinely informative set of signals, and an accurate risk score has to be built from those signals alone rather than from the ones a scanned application would have produced.

Each input answers a question the security team would otherwise have to answer manually, and together they support a rating that can be explained to a governance committee rather than merely displayed.

Why Personal-Data Egress Carries the Most Weight

Detection confidence establishes that a tool is an AI application, and traffic posture establishes how it is being used, but neither answers the question a CISO actually needs settled: what is leaving.

Personal-data egress addresses that directly by identifying the categories of sensitive data present in outbound submissions to the discovered origin. Category severity varies substantially, and a defensible model weights accordingly:

• Credentials, payment data, and government identifiers represent the highest severity, since each carries direct regulatory and financial consequence
• Email addresses and phone numbers represent moderate severity, common enough in ordinary business traffic that volume matters more than presence
• Names and addresses represent lower severity on their own, though they contribute to a pattern when they appear alongside stronger categories

A tool receiving occasional email addresses is a governance item to schedule. A tool receiving payment identifiers or API keys is an item to act on this week. A model that cannot distinguish between those two cases produces a number, not a priority.

The Privacy Constraint That Makes This Viable

Any risk model built on outbound content inspection has to answer an obvious objection before a security team will deploy it: analysing employee submissions to identify sensitive data means reading employee submissions.

The constraint that resolves this is architectural rather than procedural, and it is non-negotiable for enterprise deployment:

• Detection runs on the device, so content is evaluated locally and never transmitted for analysis
• Only categories and counts leave the machine — that a payment identifier was observed, and how many times
• Raw request bodies are never uploaded, nor are matched substrings, nor URLs carrying query parameters
• Aggregates are transmitted on a rolling window, not per-request, which further limits what any single transmission reveals

A model that only functions by uploading content is one security teams correctly refuse to deploy, and privacy review will stop it regardless of how accurate its scoring is. Stating the constraint explicitly is what makes the approach credible to the people who have to approve it.

Why Unassessed Must Remain Null

A discovered tool that has not yet produced signal data has no risk level, and the model has to be capable of expressing that rather than substituting a default.

Until the first signal window completes, the correct value is null, rendered in the interface as an unassessed state rather than as a severity. This closes the loop on the problem identified earlier in this article: defaulting an unmeasured tool to the lowest severity converts absence of evidence into apparent evidence of safety, and files a genuine finding under a label that guarantees nobody revisits it.

Two rules follow, and both apply to any AI inventory regardless of vendor:

• Unmeasured and low-risk must be visually distinct, so that the first state generates work rather than reassurance
• Approval is not equivalent to safe egress, an approved tool still warrants traffic assessment, because classification answers whether the tool should exist while egress telemetry answers what is actually leaving

The second rule matters more than it initially appears. Organizations frequently treat approval as the end of the assessment, when approval only records a decision made at a point in time about a tool whose behaviour may since have changed.

What This Changes for Security Leadership

A discovery-native risk model turns an undifferentiated list of unknown tools into a ranked queue, which is the difference between visibility and actionable visibility.

• Findings arrive prioritised, so limited review capacity is spent on the tools receiving the most sensitive data
• Risk ratings are explainable, because each traces to observed categories and counts rather than to an opaque score
• The AI register becomes defensible under assessment, since every rating corresponds to a measurement rather than to a formula default
• Discovery output reaches decisions, rather than accumulating in a queue nobody can triage

The sections that follow examine where this approach reaches its limits, and how a zero-day finding moves through classification into governance.

Turning a Zero-Day AI Finding Into a Governance Decision

A zero-day AI finding is a triage input rather than an incident, and the objective is to move the tool out of the unclassified state rather than to block it on discovery. Blocking every newly discovered application produces the workaround behaviour that created the visibility gap in the first place, while classifying it brings the tool inside the same governance process that already covers the rest of the environment.

The classification decision is faster than most security teams expect, because the finding arrives carrying the context that would otherwise require investigation.

How to Triage a Newly Discovered AI Tool

Each field in the finding answers a specific question, and the answers together determine the appropriate action.

Four outcomes are available, and the finding evidence usually indicates which one applies:

• Approve with conditions — the tool serves a legitimate need and its data handling is acceptable, typically with constraints on account type or data classes
• Monitor — usage is low and the exposure is limited, so the tool is catalogued and watched rather than restricted
• Restrict — the tool is permitted for specific teams or specific data, with enforcement applied elsewhere
• Block — the data handling is unacceptable or the vendor cannot be assessed

Why Approval Does Not End the Assessment

Classification records a decision made at a point in time about a tool whose behaviour may subsequently change, which means approval and safe egress are separate questions.

An approved AI tool can add capabilities, change its subprocessors, or alter its retention terms without notifying the organization, and none of those changes trigger re-review under a classification-only model. Traffic assessment remains relevant after approval for the same reason it was relevant before:

• Classification answers whether the tool should exist in the environment
• Egress telemetry answers what is actually leaving through it today

Organizations that treat the approval decision as the end of the process accumulate a catalogue of tools assessed against conditions that no longer hold. Continuing to assess traffic on approved tools is what keeps the register reflective of current behaviour rather than of a historical decision.

Closing the Loop Back Into the Catalogue

A classified tool joins the catalogue and stops generating zero-day findings, which is the mechanism that keeps the review queue finite.

Without this loop, the discovery layer regenerates the same finding on every subsequent session and the queue grows without bound, at which point the security team stops working it. With the loop closed, the queue contains only genuinely new applications, and its size becomes a meaningful signal in its own right, a measure of how quickly AI adoption is outpacing the organization's review capacity.

This is also where discovery connects to the frameworks the organization is already accountable to. The NIST AI Risk Management Framework; see also NIST's own AI RMF resource hub; places inventory within its Map function, which requires that AI systems in use be identified and contextualised before risk can be measured or managed.

ISO 42001 requires a maintained register of AI systems as a precondition of the management system itself. Neither framework can be satisfied against an inventory that only contains tools somebody remembered to add, which is why continuous discovery is not an operational convenience but the foundation the rest of the programme depends on.

Frequently Asked Questions

Q: What is zero-day AI?

Zero-day AI refers to an AI application present in an organization's environment that has not yet been classified as approved or unapproved. The application exists in network traffic but not in the AI inventory, which means no security decision has been made about it. The term borrows from zero-day vulnerabilities but describes uncertainty rather than exploitability, the tool may be entirely legitimate, but the organization holds no information about what it does with the data it receives.

Q: How is zero-day AI different from shadow AI?

Shadow AI is unsanctioned use of an AI tool the organization already knows about, such as an employee using ChatGPT through a personal account when policy prohibits it. Zero-day AI is a tool the organization has never identified at all, so no policy exists to violate. Shadow AI requires enforcement as its control, while zero-day AI requires discovery. The distinction matters because every enforcement control presupposes that the target application has already been identified.

Q: Why does shadow AI show as low risk in most security dashboards?

Risk scores for AI applications are typically calculated from prompt-scan telemetry, usage volume, exposure rate, and block rate. A discovered tool never enters the prompt-scanning pipeline, so all three inputs return zero and the formula produces a low score. The zero means nothing was measured rather than nothing was found, but both conditions produce an identical value. The result is an inventory where the tools an organization knows least about appear safest.

Q: Can DNS or SNI filtering detect unlisted AI tools?

No. DNS and SNI filtering identify AI applications by matching hostnames against a catalogue of known AI domains, so a tool whose hostname is not in the catalogue produces no match at any confidence level. Encrypted Client Hello compounds this by concealing the destination hostname from passive observers entirely. Detecting unlisted AI tools requires evaluating what an origin does rather than what it is called.

Q: How does behavioral AI detection identify a tool nobody has catalogued?

Behavioral detection evaluates four families of evidence: the client surface an origin presents, AI frameworks and widgets embedded in the delivered page, traffic patterns characteristic of model inference, and outbound calls to commercial model APIs. No single signal produces a verdict, since each appears independently on sites that are not AI applications. Classification derives from the weighted combination, which allows a finding to be generated for a domain no vendor has indexed.

Q: Why does attribution matter in shadow AI discovery?

When an employee uses a white-labelled AI product, the site calls a model provider in the background on the employee's behalf. Systems that match hostnames without distinguishing background calls from navigations record this as a session with the model provider, so the inventory reports usage of a tool the employee never opened while the tool they did open never appears. Correct attribution records the finding against the site the employee actually opened, with the model API call as supporting evidence.

Q: How do you avoid false positives when detecting unknown AI tools?

The dominant false-positive class is marketing content about AI products, which loads AI tooling and streams scripted output while offering no way for an employee to submit anything. The control is a conjunctive requirement: an origin qualifies as zero-day AI only when the weighted signal evidence clears its threshold and the site presents a genuine path for data to leave, text entry, file upload, or media capture. Precision determines whether discovery output reaches a decision or gets muted.

Q: Does zero-day AI detection require uploading page content?

No, and a system that requires it should not pass privacy review. Detection and content classification run on the device, so only categories and counts are transmitted, that a payment identifier was observed and how many times, never the matched value, the request body, or URLs carrying query parameters. Aggregates transmit on a rolling window rather than per request, which further limits what any single transmission reveals.

Q: Can zero-day AI detection see native desktop AI applications?

Partially. A client terminating TLS at the device level observes traffic from native applications routing through the system network stack, which covers most Electron-based AI desktop clients. Applications using certificate pinning validate the server certificate directly and reject interception, so those fall outside traffic-based discovery and require endpoint process inventory instead. Browser extension deployments see no native client traffic at all.

Q: Should an AI inventory include tools the security team never approved?

Yes. Both ISO 42001 and the EU AI Act require a register of AI systems in use, and use is the criterion rather than approval. An inventory containing only approved tools describes the organization's intentions rather than its actual AI footprint, and cannot support the risk assessment either framework expects. Unapproved and unclassified tools belong in the register with their state recorded accurately.

Q: Does an approved AI tool still need traffic monitoring?

Yes, because approval and safe egress are separate questions. Classification records a decision made at a point in time, while an approved vendor can add capabilities, change subprocessors, or alter retention terms without notifying the organization. Classification answers whether the tool should exist in the environment; egress telemetry answers what is actually leaving through it today.

Q: How often should AI tool discovery run?

Continuously. New AI applications can enter an employee workflow within minutes of launch, and existing SaaS products add AI features to already-approved domains without notice. Periodic reviews capture what was known at the time of the review, which means the interval between review cycles is a window in which new tools operate unobserved. Detection that classifies traffic as it passes reduces the gap between a tool entering the environment and the security team knowing about it to a working day.