SecOps / Security for AI

Shadow AI discovery: find it, classify it, govern it

You cannot secure AI you do not know about. Discovery turns an unknown estate into an inventory with owners, risk levels and a decision for each item.

Shadow AI is the AI your security team did not approve and cannot see: a team's personal-account chatbot, a coding agent installed on a laptop, a browser extension with model access, an API key in a project nobody reviewed. This page is about the operational side, the discovery and triage workflow. The shadow AI explainer covers the concept.

Build with AI Talk to our team

The problem: AI adoption outran the asset inventory

Classic shadow IT left traces in procurement and network logs. Shadow AI leaves fewer. A model call is an HTTPS request to a well-known domain. An agent runs on a laptop and uses the developer's own credentials. An API key sits in an environment variable. An MCP server is a process that starts on login. Meanwhile, the people doing it are usually the most productive in the company and are not trying to hide anything.

The risks are specific. Sensitive data flows to providers under terms no one reviewed. Agents hold broad credentials with no owner. Unknown non-human identities appear in cloud accounts. When an incident happens, the SOC has no way to answer the first question: what AI was involved, and what could it reach?

A ban does not fix this. It drives usage further out of sight and costs the business the real productivity it was getting. The effective response is discovery followed by a governed path, so that the sanctioned option is easier than the unsanctioned one.

How the workflow runs on Swfte

Discovery is a recurring SecOps workflow with defined outcomes, not a one-off audit. Each finding ends in a decision recorded against an owner.

1. Discover
Surface unmanaged agents, unsanctioned model providers and unknown non-human identities through the connected sources: agent runtime capture, identity and cloud inventories, and gateway logs. The sources available depend on your connectors. <supported discovery sources - founder to fill>
2. Classify
Each finding gets a risk level from what it can reach: which data classes, which systems, which actions, under whose identity. The identity graph shows blast radius, so a harmless-looking key that reaches production is not rated like a sandbox toy.
3. Decide
For every item the owner picks one outcome: sanction it, replace it with a governed equivalent, restrict it, or retire it. Nothing stays in an unknown state.
4. Migrate
Sanctioned use moves behind the model gateway and the governed runtime, where identity, policy, data controls and audit apply. The aim is that doing it the approved way is the easy way.
5. Monitor
New findings keep arriving. Policy checks run continuously, and a finding shows exactly which policy failed and where, rather than a screenshot of a settings page.

Where it sits on the platform

One platform with several entry points. Each product below plays a defined part in this capability.

Platform products and the role each plays
Platform entry point	Role in this capability
Nexus	Shadow-AI detection for unmanaged agents, unsanctioned providers and unknown non-human identities; inventory, identity graph and blast radius.
BuildX	The sanctioned route to models. A governed gateway is what makes the approved path attractive.
Studio	Rebuild a useful shadow workflow as a governed agent with an owner and a Trust Profile.
Trust Fabric	Identity, data controls, policy and monitoring applied to what discovery finds.

What a discovery agent can and cannot do

Discovery itself can be an agent. This is a Trust Profile for one, which shows the privacy stance as well as the capabilities.

AI Discovery Agent

Inventories AI usage and prepares findings for the owner to decide.

AI Discovery Agent: what it can do, cannot do, requires approval for, and records
Can	Cannot	Requires approval	Records
Read inventories from connected identity, cloud and runtime sources Match activity to known model providers and agent types Rate findings by reachable data and systems Draft the finding and the recommended decision	Read prompt text or message content at the default privacy tier Revoke or delete a key on its own Install software on user devices Mark a finding closed without an owner decision	Revoking a credential or blocking a provider Contacting the person or team using the tool Escalating a finding to HR or legal	Source and time of each finding Classification and reasoning Owner, decision and date Policy that failed Outcome and follow-up

Controlled autonomy for discovery and enforcement

Finding is low-risk. Blocking and revoking are not, because they interrupt people's work. Levels reflect that.

L1 Assist
The agent lists and classifies findings. People decide everything.
L2 Approve
The agent prepares the block, revoke or migrate action; an owner approves it.
L3 Supervise
Within limits, for example restricting a clearly unsanctioned provider on a managed device, with monitoring and an easy undo.
L4 Autonomous
Policy-defined responses for well-understood categories, with sampled review.
L5 Adaptive
Detection rules are tuned from the record. Changes are gated and versioned.

The five-level model is described in full on the controlled autonomy page.

Frameworks the design is mapped to

Mappings of intent between controls and published risk lists. Not an assessment result.

Framework entries and how the controls are designed to address them
Framework	Entry	How the design addresses it
OWASP Top 10 for Agentic Applications (2026)	ASI10 Rogue Agents; ASI03 Identity and Privilege Abuse	Inventory and ownership for every agent and non-human identity, so an unregistered one is visible.
OWASP Top 10 for LLM Applications (2025)	LLM02 Sensitive Information Disclosure; LLM03 Supply Chain	Provider and data-flow visibility, and a governed route for approved models.
MITRE ATLAS	AML.T0010 AI Supply Chain Compromise	Knowing which models and components are in use is the precondition for assessing them. Confirm current technique IDs at atlas.mitre.org.

EU angle: personal data and accountability

Unsanctioned AI use is a data-protection and a governance issue at once.

EU instruments and what Swfte supports evidence for
Instrument	Reference	Supports evidence for
GDPR	Art. 32 security of processing; Art. 5(2) accountability	Supports evidence that you know where personal data goes and can demonstrate the measures you applied.
EU AI Act	Art. 4 AI literacy; deployer obligations	You cannot meet obligations for AI systems you do not know you deploy. An inventory is the starting evidence. Which obligations apply depends on the system and your role.
NIS2	Art. 21 asset management and supply-chain security	Supports evidence of an asset inventory that includes AI services and their suppliers.
DORA	ICT third-party risk	Supports a register of AI providers in use, for financial entities in scope.

Swfte is built compliance-by-design. It provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. Nothing on this page is legal advice. Swfte's own security attestations are listed on the trust page.

What this page does not claim

No discovery method sees everything. Personal devices, personal accounts and encrypted channels are partial or invisible without the right agreements and controls.
Nexus detection is strongest for agents it can hook or import; coverage of other categories depends on connectors.
We state no figure for how much shadow AI exists in a typical organisation, because we have none we can source here.
Nothing here claims that your use of the platform is compliant with any regulation. Swfte's own security attestations are listed on the trust page.

Frequently asked questions

How do you discover shadow AI?

By combining sources: agent runtime capture, identity provider and cloud inventories, gateway and network logs, and expense or procurement data. Each source finds a different slice, and the union is the inventory. The sources available to you depend on your connectors.

Does discovery mean reading employees' prompts?

It need not. At the default privacy tier Nexus records prompt fingerprints and length only, not prompt text. Discovery is about which tools and identities exist and what they can reach.

Should we block unsanctioned AI?

Blocking is one outcome among four: sanction, replace, restrict, retire. Blanket bans tend to push use out of sight. A governed alternative that is as easy as the shadow tool is usually more effective.

What is the difference between this and the shadow AI page?

The shadow AI page explains the phenomenon and the risks. This page is the SecOps workflow: discover, classify, decide, migrate, monitor.

How does this connect to non-human identity?

Many shadow AI findings are credentials: API keys, service accounts and tokens belonging to agents. Treating them as first-class identities with owners is how they become manageable.

The rest of SecOps

Nine pages cover both halves. Each has a different job.

AI for security operations

Security for AI

Frameworks and evidence

Back to the SecOps hub.

Build Shadow AI discovery with Swfte

Start with one agent and one policy, or talk to the team about your environment, your data and your regulators.