How do I discover shadow AI agents and tools?

Summary

• You discover shadow AI by making the governed path the default path, then reading the logs: route every model, agent, and tool through one control plane and each request shows up attributed in queryable system tables.
• Shadow AI is any model, agent, or tool a central team hasn't sanctioned or can't see, and the risks are concrete: data leaving through unmonitored endpoints, unattributed spend, unvetted providers, and tools acting with no audit trail.
• On Databricks, Unity Gateway (generally available) sits in front of foundation models, external providers, MCP services, and agents, and a workspace enforcement setting turns off legacy bypass paths.
• Every request is logged to the system.ai_gateway.usage Unity Catalog system table, so one SQL query shows which principals call which models or agents and where the spend goes.
• Models, agents, MCP services, and skills are registered as Unity Catalog objects with grant-based access control, so anything off the catalog or off the gateway is your shadow inventory.

How do I discover shadow AI agents and tools?
You discover shadow AI by making the governed path the default path, then reading the logs. Route every model call, agent, and tool through one control plane, enforce that routing so nothing bypasses it, and each request shows up attributed in queryable system tables: who called which model or agent, from where, and at what cost. Pair that telemetry with a catalog of approved models, agents, and tools, and your shadow inventory becomes whatever is not on the list or not flowing through the gateway. Discovery is a governance problem before it's a detection problem, because you can't find rogue usage you never route or record.

What is shadow AI?

Shadow AI is the use of AI models, agents, or tools that a central team hasn't sanctioned or can't see. It shows up as developers calling external model APIs with personal keys, teams standing up their own agents, or coding assistants and MCP tools wired straight to a provider outside any governed path. The risks are concrete: sensitive data leaving through an unmonitored endpoint, spend nobody can attribute, models from unvetted providers, and tools acting on systems with no audit trail. You can't govern what you can't see, so the first job is to pull that usage onto a path you control.

Key capabilities to evaluate

Capability	Why it matters
Central routing and enforcement	A single governed path, enforced at the workspace, means model and agent calls can't quietly bypass oversight.
Queryable usage telemetry	Per-request logs of requester, model, tokens, and cost in system tables turn invisible usage into a report you can run.
Asset inventory	A catalog of approved models, agents, and tools defines what sanctioned means, so anything off it stands out.
Identity and attribution	Tying each call to a principal, and separating human from agent callers, is what makes usage accountable.
Access control	Grant-based permissions and attribute policies block unapproved models and tools, not just report them.
Audit and payload capture	Audit logs and optional request and response capture support investigation and compliance review.

How Databricks approaches discovering shadow AI

Unity Gateway, generally available since August 2026, is the control plane for this. It sits in front of foundation models, external model providers, MCP services, and agents, and a workspace enforcement setting routes AI traffic through it so legacy bypass paths are turned off. Every request is logged to the system.ai_gateway.usage Unity Catalog system table, with requester, endpoint, token counts, cost, and request tags, so a single SQL query surfaces which principals are calling which models or agents and where the spend is going. Request tags let you attribute usage by team or project.
Discovery works because the gateway also holds the inventory. Models, MCP services, agents, and skills are registered as Unity Catalog securable objects, so there's one governed list of what's approved and who can use it. Access is granted the way it is for tables and volumes: a caller needs EXECUTE on the target model or tool, and admins can set attribute-based policies on foundation models using properties like provider, country of origin, and approval status. Usage that doesn't match the catalog, or a principal calling a model they shouldn't, becomes visible rather than hidden. For investigation, audit logs in system.access.audit and identity metadata separate human callers from agents, and optional inference tables capture full request and response payloads into your own Unity Catalog Delta tables.
Once usage is visible you can control it. Per-principal rate limits and spend caps throttle or halt runaway calls. Service policies, in Beta, enforce guardrails on every request, evaluated before the model runs and after it responds, including PII detection and redaction, unsafe-content and jailbreak blocking, and hallucination checks. Custom policies can be written as rules or as an LLM-as-judge classifier.

FAQs

Can Unity Gateway find AI usage that isn't already routed through it?

Not directly, because a call that never touches the gateway leaves no gateway record. The approach is to make the gateway the enforced path so new usage is captured, then use billing and access audit logs to investigate endpoints and providers that predate enforcement.

How do I tell an agent's calls apart from a person's?

Every request is attributed to a principal, and identity metadata records whether a call ran as a user or on behalf of an agent. Querying system.ai_gateway.usage and system.access.audit by requester shows the split.

Are the governance guardrails generally available?

Unity Gateway itself is generally available. Service policies, which enforce the PII, safety, and jailbreak guardrails, are in Beta, so treat that layer as evolving and confirm its current status before you depend on it.

What counts as a tool in this context?

Tools are the MCP services and functions an agent can call. Registering them as Unity Catalog objects means tool access is governed and logged the same way model calls are.