What counts as a shadow AI agent
A shadow AI agent is any autonomous or semi-autonomous system operating in the enterprise without formal inventory, approval, or governance. That includes more than home-grown agent frameworks. It can be an always-on local assistant, an agent embedded into a SaaS workflow, a browser extension with action permissions, or a script chain wired to email, tickets, cloud drives, or shells.
The important distinction is action. A user asking a model for a draft is not the same as an agent that watches a mailbox, decides what matters, opens attachments, queries an API, and updates a system record. Once the system crosses from content generation into tool use and persistence, the governance problem changes.
Simple test: if the system can take action after the user steps away, it belongs in your AI inventory. If it can change data, send messages, or call privileged tools, it belongs in your risk workflow too.
Where to look first
Lasso's recent OpenClaw discovery guidance is useful because it treats this as a detection problem before it becomes a policy debate. That's the right sequence. Start with four data sources that already exist in most mid-market environments:
- Endpoint telemetry: local runtimes, background services, unusual agent directories, scheduled tasks, shells launched by AI tools, and long-running processes tied to agent frameworks.
- Identity and access logs: service accounts, new OAuth grants, SaaS tokens, unusual delegated permissions, and repeated API calls from nonstandard clients.
- SaaS admin consoles: AI add-ons, automations, embedded copilots, workflow agents, browser extensions, and connector marketplaces.
- Procurement and expense signals: team-level subscriptions, pilot spend, and software reimbursement claims that never hit formal architecture review.
Most firms over-index on the first bucket and ignore the other three. That's a mistake. A lot of shadow agents arrive through sanctioned SaaS and unsanctioned permissions, not malware-like endpoint behavior.
A five-step triage model
Discovery alone creates noise. You need a triage model that turns signals into decisions.
| Step | Question | Decision output |
|---|---|---|
| 1 | Does the tool only generate content, or can it act? | Separate low-risk assistive tools from agentic systems. |
| 2 | What can it access? | Map files, mailboxes, tickets, code repos, APIs, identities, and external systems. |
| 3 | What is the blast radius if it fails? | Classify by business criticality and data sensitivity. |
| 4 | Who approved it, if anyone? | Identify owner, or escalate as unowned risk. |
| 5 | Can it stay, be constrained, or be shut down? | Allow, remediate, ring-fence, or disable. |
That sounds obvious, but plenty of teams stop at discovery and call it governance. It isn't. Governance starts when the organization can prove who owns the system, why it exists, which controls apply, and what the approved boundary is.
Risk bands worth using
I would keep the first version blunt. Band 1: assistive only, no persistent actions. Band 2: internal actions with limited scope. Band 3: actions affecting external parties, regulated data, identity, financial workflows, or consequential decisions. Band 3 should never remain shadow IT. It either enters formal governance or it gets shut down.
Related resources: use the OpenClaw governance checklist for control design, then connect the results to your readiness assessment and formal ACT Tier 1 inventory workflow.
What evidence to retain
If discovery is going to support audit, remediation, or incident response, you need a basic record. For each shadow agent you identify, retain:
- Discovery source: endpoint event, SaaS admin alert, identity log, procurement record, or user disclosure.
- System description: runtime, tool chain, model provider, connectors, and business process touched.
- Access map: credentials, permissions, data classes, and affected systems.
- Owner and status: approved owner, pending review, remediating, disabled, or blocked.
- Decision rationale: why the system was allowed, constrained, or removed.
That evidence is what turns security discovery into governance maturity. Without it, you can count sightings but you can't prove control.
Frequently asked questions
Is every unapproved AI tool a shadow agent?
No. Some are just unmanaged GenAI assistants. The term shadow agent is more useful when the system has persistence, tool use, or action capability.
Should security or compliance own discovery?
Security usually owns detection. Compliance or AI governance should own the policy boundary, evidence expectations, and periodic review. One team alone rarely covers both well.
Can we allow shadow-discovered agents after review?
Yes. Discovery should not automatically mean shutdown. The better pattern is classify, constrain, assign ownership, and then decide whether the use case is worth formalizing.
What's the first metric to track?
Count of discovered agents with no assigned owner. That tells you how much unknown exposure still sits outside governance.