What is Shadow AI?
Shadow AI is AI usage that falls outside an organization's approval or management controls. The gap can involve the application, account, data, purpose, or actions. A known application can still be used outside its approved scope.
For a concise definition, read the Shadow AI glossary entry.
The label does not, by itself, establish malicious intent, a data leak, or a lack of logs. It identifies a governance question that needs an accountable decision. An unknown approval status should remain unknown until the organization can establish the relevant facts; it is not automatically proof of prohibited use.
The practical goal is to connect observed activity to the organization's AI governance policy: identify the use, determine its scope, assign an owner, and verify the applicable decision. Some legitimate uses can be approved with conditions. Others require restriction or further investigation.
Why an application inventory can miss AI usage
An inventory answers the questions its records were designed to answer. A list of installed software can identify a desktop application without describing an account used in a browser. A list of approved services can name an application without recording which features, data, or purposes the approval covers.
The inventory remains useful. Its limits should be explicit. NIST's AI RMF Playbook, GOVERN 1.6 calls for mechanisms to inventory AI systems and an assigned responsibility for maintaining them. It does not make the presence of an application in an inventory proof that a particular use is approved.
Hypothetical example: an analyst uses an AI application that appears on the approved list. The policy permits it only through an organization-managed account for specified business uses. A browser activity record identifies the service, but not the account or the submitted content. The team has evidence of access and a question to resolve, not yet a complete description of the interaction.
Common Shadow AI surfaces
Look for the form the activity takes and the evidence available for it. These surfaces can overlap: an autonomous agent might run through a CLI, while a coding assistant might be embedded in a desktop application. This matrix is an assessment aid, not a product coverage table.
| Surface | Evidence that may be available | What that evidence alone does not establish |
|---|---|---|
| Browser apps | A visit to a recognized service or a supported interaction event | Which account was used, what was sent, or whether a visit included a prompt |
| AI browser extensions | Installation records, granted permissions, and relevant activity | Whether an AI feature ran or which page content it processed |
| Coding assistants | IDE configuration, service connections, and recorded requests | Which suggestions were accepted or whether code reached an external service |
| Desktop AI apps | Application inventory, process activity, and exported telemetry | Account, prompt content, or a complete history when those fields are absent |
| CLI agents | Invocation records, runtime configuration, and tool events | Whether a proposed action was authorized or completed |
| Autonomous agents | Schedules, workflow ownership, credentials, and action records | Who authorized each delegation or whether every step was observed |
Verify those evidence sources in the actual environment. A configured collector, an installed integration, and a successfully received event are different facts. For workflows that delegate actions, AI agent governance examines the authority and execution controls in more detail.
What data can leave the organization
Identify the actual data path before assigning consequences. Depending on the workflow, the material involved could be prompt text, an uploaded document, selected source code, retrieved records, or arguments sent to a tool. Those are possible paths to assess, not a finding that all of them occurred.
Keep four questions separate: was content transmitted, was it retained, was it used for training, and could another party access it? Evidence of one does not establish the others. Answer service-specific questions from the relevant configuration, agreement, documentation, and available records rather than assuming a provider's behavior.
In the hypothetical analyst workflow, the initial visit record cannot establish whether confidential material was sent. Even a confirmed transfer of a public report would not prove a transfer of internal data. Record the content evidence available and the boundary it supports. If content is unavailable, preserve that limitation instead of treating it as either proof of safety or proof of exposure.
Apply the same care to evidence collection. A governance investigation can itself create another copy of sensitive content. Collect what is necessary to establish the decision, define access and retention, and avoid requesting credentials or entire conversation histories by default.
Why blocking domains is not enough
Blocking a domain can restrict access through the path where that rule is enforced. It is a useful response when the policy prohibits that destination and the control covers the relevant traffic. It does not, alone, describe the account, content, or authority involved in a permitted connection.
In the analyst example, a blanket block would also affect the approved workflow on the same service. Leaving the domain open would not establish compliance with the account requirement. The team needs a control and a verification method that address the actual rule.
Other paths need their own assessment. A local tool action is not necessarily governed by an external domain rule, and an approved application can contain features outside the original approval. Document which paths the control covers and check its effect. Do not infer a limitation of an entire security product category from the limits of one rule.
Discovery vs governance
Discovery produces signals and candidate records. Governance turns sufficient context into a decision with an owner, scope, and means of verification. More discovery data does not automatically resolve whether an interaction was permitted.
A useful finding separates three statements: what the evidence shows, what is not yet known, and which policy question depends on the missing information. For example: “Access to an approved AI service was observed. The account is not established. Policy requires an organization-managed account.” That is precise enough to assign follow-up without asserting a leak or violation that has not been established.
Sources may disagree. A procurement record may describe an enterprise subscription while a session record concerns a different account. Check identifiers, time, and scope before combining them. Preserve conflicting evidence until the relevant difference is resolved.
From inventory to policy
Use a decision process that can close a finding without erasing uncertainty. NIST's AI RMF Playbook, MAP 1.1 emphasizes documenting intended purpose, users, and the context of deployment. The following workflow applies that idea to a discovered use.
Establish the observed activity
Record the application or destination, relevant time, evidence source, and any verified account or action context. Keep observations distinct from inference. Missing prompt content does not prevent documenting access, but it limits conclusions about the data sent.
Assign an owner and confirm the purpose
Identify who can explain the business use and who can approve its scope. Ask what work the application supports and why the current workflow was chosen. A user report is evidence with a source, not automatically a complete technical account.
In the hypothetical example, the analyst reports using a personal account to summarize published market reports. Record that explanation and compare it with available session evidence. The legitimate purpose can inform a supported alternative without overriding the account restriction.
Make a scoped decision
State what is allowed, restricted, or awaiting review. Include the application, permitted account, data classes, purpose, and relevant actions. If an exception is warranted, name its approver, limits, review date, and the conditions that would end it. An unresolved field should not silently become approval or a confirmed incident.
For the analyst, the decision could be to move this use to the managed account, permit published reports for that purpose, and keep confidential material outside the scope. That decision governs future use. It does not answer unresolved questions about earlier activity.
Apply the control and verify the result
Choose the control that addresses the rule and verify its behavior in the relevant workflow. Confirm the approved path remains usable and the restricted path receives the expected treatment. Capture the resulting evidence and note any coverage gaps.
For the hypothetical decision, verify the account context on subsequent activity where the integration provides it. A closed ticket, a policy document, or a configured rule alone does not establish that the behavior changed. If verification is unavailable, record that limitation and its owner.
Review changes and unresolved questions
Revisit the decision when the account, application features, data, or business purpose changes. Track pending evidence and exceptions alongside the inventory. A useful completion record explains what was regularized, what remains restricted, and what still needs review.
How KonaSense detects Shadow AI
Kona for Browser provides a browser integration for supported AI web applications. In the extension implementation reviewed for this page, site recognition uses configured application patterns and domains. A recognized AI site can generate an activity event when the corresponding event reporting is enabled.
That is a discovery signal, not proof that a particular prompt was sent or that a policy violation occurred. The interpretation depends on the policy and the context available for the interaction. Browser evidence should not be extrapolated into coverage of desktop applications, CLI agents, or every browser extension.
Kona for Browser also supports prompt policy evaluation in compatible applications. Its privacy documentation describes sending prompt content to the organization's KonaSense tenant for evaluation. Available intervention depends on the integration and inspection mode. Evaluate the installed version, configuration, and evidence for the workflow being governed.
FAQ
Can an approved application still be involved in Shadow AI?
Yes. Approval can be limited to a managed account, a purpose, particular data, or specified actions. Use outside those conditions can remain unapproved even when the application itself is known. Establish the applicable scope before classifying the activity.
Does discovering Shadow AI prove a data breach?
No. An unapproved use and a confirmed disclosure are different findings. Investigate the evidence of access, content transfer, and subsequent handling separately. Follow the organization's incident process when the evidence warrants it, while retaining unknowns in the record.
Should every discovery finding lead to a block?
The response should address the policy, evidence, and consequences of the use. A prohibited destination may warrant restriction. A legitimate task may be brought into an approved workflow. An incomplete finding may require a bounded investigation and interim controls. Record who made the decision and how its effect will be checked.