What Is Shadow AI?

AI adoption inside most organisations doesn't wait for a rollout plan. It starts in a browser tab, a Slack integration, a plugin someone installed to get through a Tuesday. By the time a formal AI programme gets funded, a meaningful amount of AI use is often already happening — just not anywhere central IT, security or governance teams can see it.
The first AI security problem is often not controlling AI.
It is knowing where AI is being used at all.
What is shadow AI?
Shadow AI refers to AI tools, models, agents or services being used inside an organisation without appropriate visibility, approval, governance or security oversight. The contrast is straightforward: approved AI has gone through some form of review — however lightweight — and is known to the people responsible for security and governance. Unmanaged AI hasn't. It exists, it's doing something, and no one with that responsibility knows it's there.
Shadow AI isn't confined to one category. It shows up across:
- Software
- Models
- Agents
- Data connections
- SaaS features
- APIs
- Employee workflows
Why shadow AI emerges
Shadow AI is rarely the result of anyone trying to circumvent security. It's usually a symptom of speed outpacing process. Common, entirely ordinary causes include:
- Employees seeking productivity gains from tools that are one signup away
- Teams experimenting before central approval exists to seek
- Slow procurement processes that don't match how quickly AI tools ship
- AI features quietly appearing inside SaaS tools already approved for other reasons
- Developers wiring up external model APIs directly, because it's the fastest path to shipping
- Fragmented ownership — no single team clearly owns "AI" as a category
- Unclear or nonexistent AI policy, leaving no obvious rule to follow
- Business pressure to move quickly, with AI often the fastest available lever
None of this is a story about careless employees. It's a story about governance processes that haven't caught up to how easy AI is to start using. Treating it primarily as a visibility and process problem — not a discipline problem — leads to better outcomes and better cooperation from the teams closest to the tools.
Shadow AI vs shadow IT
Shadow AI is a close relative of shadow IT — unapproved software or services running without central sanction — but it isn't simply shadow IT with a new label. AI systems add a layer of complexity that most shadow IT doesn't carry, because they may:
- Process sensitive data, not just store or display it
- Generate outputs that get acted on downstream
- Take actions rather than remain passive
- Call tools and other systems on their own initiative
- Access APIs with real permissions attached
- Make probabilistic decisions rather than deterministic ones
- Operate semi-autonomously, with a person only reviewing the outcome
An unsanctioned spreadsheet tool is a visibility problem. An unsanctioned AI agent with API access and a standing set of credentials is a visibility problem and a behavioural one — which is why shadow AI generally warrants its own response, not just an extension of an existing shadow-IT programme.
The main risks of shadow AI
Put together, unmanaged AI use tends to create the same handful of risks, in roughly this shape:
- Sensitive data exposure
- Data shared with a tool or model that was never assessed for what it does with it.
- Uncontrolled data retention
- No clarity on how long inputs, outputs or logs are kept, or by whom.
- Unclear model/provider handling
- Not knowing whether a provider trains on submitted data, or what its own security posture is.
- Permission sprawl
- Tools and agents accumulating access that was never deliberately scoped.
- Credential exposure
- API keys and tokens held by unmanaged tools, outside normal credential hygiene.
- Regulatory/compliance risk
- Regulated data processed somewhere that was never evaluated against the relevant obligations.
- Unmonitored autonomous actions
- Agents doing things — sending, changing, deleting — with no one watching.
- Inconsistent policies
- Different teams applying different, informal rules to functionally the same category of risk.
- Lack of auditability
- No record to reconstruct what happened if something needs investigating later.
- Third-party dependency risk
- Reliance on an external model or service the organisation didn't choose and doesn't track.
- Prompt injection / tool misuse
- Unmanaged tools are typically also unmonitored ones — issues can run for a long time before anyone notices.
- Difficulty responding to incidents
- You can't investigate, contain or remediate a system you didn't know existed.
Shadow AI becomes harder with agents
A shadow AI tool that only answers questions is a real but bounded problem. A shadow AI agent is a larger one, because unmanaged agents may connect to enterprise systems, use standing credentials, call tools, modify records, communicate externally, execute multi-step workflows, or interact with other agents — all without the identity, permissions and policy controls a managed agent would be expected to have. The underlying issues here overlap heavily with what we cover in AI agent security: shadow AI is largely how ungoverned agents come to exist in the first place.
You cannot secure what you cannot see
Visibility is the prerequisite for control. Before an organisation can apply policy, assign risk, or set permissions, it needs a genuine, current picture of what it's actually running. That means discovering:
- Models
- AI services
- AI-enabled SaaS features
- Agents
- APIs
- Data connections
- Permissions
- Users
- Credentials
- External destinations data flows to
It's worth being precise about what discovery does and doesn't give you. An inventory tells you what exists. A control layer is what helps determine what those systems are actually allowed to do. The first without the second is a list; the second without the first has nothing to act on.
How organisations can discover shadow AI
No single source gives complete visibility. In practice, discovery is the product of several overlapping signals, cross-referenced against each other:
- SaaS / application inventory
- Network and API discovery
- Identity and access logs
- Browser and endpoint tool telemetry
- Cloud provider logs
- Model and API usage logs
- Endpoint visibility
- Procurement records
- Employee self-declaration
- Agent registries
- Data-access monitoring
Any one of these will miss things. Together, they tend to converge on a reasonably complete picture — which is also why an ongoing process, not a one-time audit, is what actually keeps an inventory accurate.
Build an AI inventory
A useful enterprise AI inventory is structured enough to actually drive decisions, not just list names. At minimum, each entry needs:
| FIELD | WHAT IT CAPTURES |
|---|---|
| System name | What it's called and how people refer to it. |
| Owner | Who is accountable for it — a person or team, not a department. |
| Type | Model, agent, SaaS feature, API integration, etc. |
| Model / provider | What's actually powering it, and who operates that. |
| Business purpose | What it's for, in plain terms. |
| Users | Who actually uses it, and how broadly. |
| Connected data | What data it can read or write. |
| Connected tools | What other systems and APIs it can call. |
| Credentials | What access keys or tokens it holds. |
| Permissions | What it's actually authorised to do. |
| Deployment environment | Production, staging, sandbox, personal account. |
| Risk classification | A deliberate rating, not a guess. |
| Approval status | Whether it's actually been through review. |
| Policy status | Which policies apply, and whether it complies. |
| Last reviewed | When someone last actually checked the above. |
Discovery is not enough
An inventory answers “what exists.” It doesn't, by itself, answer “is this okay,” “who's responsible,” or “what happens if it misbehaves.” After discovery, the work that actually reduces risk is:
- Ownership
- Risk classification
- Permissions
- Policy
- Monitoring
- Approval controls
- Audit trails
- Remediation
- Containment
As a progression, it looks roughly like this:
Moving from a static inventory to that kind of ongoing control is essentially what an AI control plane is architecturally for.
Shadow AI governance
The instinctive response to shadow AI is often to lock everything down. That tends to backfire — it just pushes AI use further into the shadows, since the underlying pressure to use these tools doesn't go away. A more pragmatic governance model gives teams a real, fast path to legitimate use rather than only a prohibition. That usually includes:
- A shortlist of approved tools for common use cases
- Clearly restricted data types that must never go into unapproved systems
- A safe environment for experimentation that doesn't require full production sign-off
- Risk tiers, so low-risk use isn't held to the same bar as high-risk use
- Lightweight registration — a form, not a committee
- Central policies that are actually written down and findable
- Defined ownership for every system, not just the risky-looking ones
- Periodic review, so approvals don't quietly go stale
The goal of governance here isn't to minimise AI use. It's to make the approved path faster than the unapproved one — the wider governance model this fits into is covered in What Is Enterprise AI Governance?.
A practical shadow AI checklist
- Identify AI-enabled tools already in use.
- Catalogue AI models and services.
- Identify autonomous agents.
- Map connected enterprise data.
- Map connected tools and APIs.
- Identify owners.
- Review credentials and permissions.
- Classify systems by risk.
- Define approved and prohibited use.
- Monitor external data destinations.
- Establish an AI registration process.
- Review AI-enabled SaaS features specifically — not just standalone tools.
- Create an incident response path for AI-related issues.
- Reassess the inventory continuously, not once.
Where Sentinel fits
Shadow AI is one of the problem areas Porthos Labs is exploring with Sentinel. Sentinel is being designed to provide organisations with greater visibility into AI systems and agents, understand how they connect to data and tools, and create a stronger foundation for policy, monitoring and control.
Closing
AI adoption will increasingly happen across organisations whether security teams initiate it or not. That part isn't really in question. The question is whether that adoption remains invisible.
Before organisations can govern AI, secure it, or trust it, they need to know where it exists.