What Agent Runtimes Mean for Shadow AI: Discovering Unsanctioned Agent Data Connections

Shadow AI discovery has outgrown the chat tool. The harder problem now is the autonomous agent that quietly holds a connection to your production database, runs unattended and never appears in a conventional scan. If your shadow AI discovery work still focuses on who pasted what into a public chatbot, you are mapping last year’s risk.

The central argument of this post is simple. Agents reach data through managed runtimes, database services and Model Context Protocol connectors and those paths were never visible to the CASB and DLP tooling most organisations rely on. Shadow AI discovery has to start mapping which agents hold credentials to which data stores, then verify each connection is sanctioned and least-privilege.

Why chat-tool discovery misses the real exposure

The real exposure sits in standing connections, not in human prompts. A staff member pasting a customer record into a public model is a moment in time and a user-level event your tooling can often catch. An agent wired to a managed database runs continuously, on a service credential, with no human in the loop to trip an alert.

This matters because the controls organisations bought for shadow AI were built around people and browsers. CASB watches sanctioned and unsanctioned SaaS traffic. DLP inspects content leaving endpoints and email. Neither was designed to see a managed agent runtime calling a database service inside your own cloud account, because that traffic looks like ordinary application activity.

The consequence is a discovery blind spot. The agent connection persists, runs unattended and rarely surfaces in the reports your security team reviews each week. You can pass a shadow AI audit on the chat-tool definition and still have unscoped agents reading production records.

How agent runtimes create shadow AI data connections

Agent runtimes execute autonomous tasks that call APIs, databases and managed cloud services on a developer’s behalf. When teams wire these connections without governance, the agent gains standing access to production data outside any approved register. The connection persists, runs unattended and rarely appears in conventional shadow AI scans.

The mechanism is worth understanding because it explains why the access is so durable. A developer building an agent needs it to fetch data, so they grant the runtime a service credential to a managed database or an equivalent data store. That grant lives in code or configuration, not in an access request. No one approves it as a data flow because, to the engineering team, it is just plumbing.

Model Context Protocol connectors widen this further. MCP gives agents a standard way to reach tools and data sources, which is useful for builders and invisible to governance. Each connector is a data egress path. The MCP shadow AI risk is that these connectors multiply quietly across teams, each one a route out of a controlled boundary that no register records.

What an unsanctioned agent data connection looks like

An unsanctioned agent data connection is a link between an AI agent and a data store that no one formally approved or scoped. The risk is silent data egress: the agent holds standing credentials, often with broad permissions, so sensitive records can leave controlled boundaries without triggering user-level alerts.

In practice these connections share a few traits. The credential is usually over-scoped, because a developer granted read access to a whole database when the agent needed two tables. The connection is regardless of cloud or vendor, so it shows up across managed runtimes, hosted model platforms and database services alike. And the access is rarely time-boxed, so a prototype agent from a six-month-old project may still hold live credentials.

For a regulated organisation, an NHS trust, a local authority or a professional services firm handling client data, this is the exposure that matters. A broad standing credential held by an unattended agent is exactly the kind of egress path that breaches data protection obligations without anyone noticing until an audit or an incident forces the question.

How discovery actually works for agent connections

Discovery starts with mapping which agents hold credentials to which data stores, then verifying those connections are sanctioned and least-privilege. Effective work combines network egress monitoring, cloud audit logs, identity and access reviews and database connection inventories rather than relying on any single tool.

We approach it in a deliberate order. First, inventory the runtimes: every managed agent platform, hosted model service and MCP connector in use across teams. Second, pull the service identities those runtimes use and trace each one to the data stores it can reach, using cloud audit logs and database connection records. Third, cross-reference that map against your approved register to find connections no one sanctioned.

The verification step is where governance lands. For every connection that survives the inventory, the question is whether it is approved, whether it is least-privilege and whether it should still exist. Many will fail at least one test. That failure list is your shadow AI discovery output: a ranked set of agent connections to revoke, scope down or formally bring under control.

This is why managed runtime agent access control belongs inside discovery, not after it. Finding the connection and scoping the credential are two halves of the same exercise. Discovery that stops at a list, without the access control follow-through, leaves the egress path open.

What clients ask us about agent-driven shadow AI

Does this mean our existing CASB and DLP investment was wasted?

No. CASB and DLP still do useful work on human-driven SaaS and content egress. The point is that they were never scoped to see service-credentialled agent connections inside your own cloud, so they need to sit alongside cloud audit log analysis and database connection inventories rather than be treated as complete coverage.

Who should own discovering unsanctioned agent connections?

Ownership usually sits between security and platform engineering, because the connections are created by engineers but carry data risk the security function is accountable for. The practical answer is a shared register that engineering populates and security verifies, so neither side assumes the other has it covered.

How often should we re-run agent connection discovery?

Agent connections change as teams build, so a one-off scan ages quickly. Treat discovery as a recurring control tied to your change cadence, with a fuller review at least quarterly and lighter checks whenever a new runtime or MCP connector is introduced into the estate.

If you do not know which agents in your estate hold standing credentials to your data stores, you have an open discovery problem. Our Shadow AI Discovery work sets out the inventory, tracing and verification steps in more detail, including how the map is built and what a scoped-down connection looks like. When you are ready to run it against your own estate, QL Security scopes that as a bespoke AI security project.