Shadow AI has become shadow agency
Employees are no longer only sending data to unsanctioned AI tools. Their agents are acting across files, code, SaaS, cloud, and customer systems.
The governance problem changes when an unapproved tool can do work instead of only generating content. Security teams need an inventory of agency, not another list of AI domains.
Why shadow AI is no longer the right mental model
Shadow AI originally meant employees pasting information into an unapproved chatbot. That is still a data problem, but agents add a second dimension. A coding agent can edit repositories and run commands. A browser agent can submit forms. A sales agent can update customer records. A homegrown workflow can keep operating after the person who built it has moved on.
The question is no longer only where data went. It is what software acted, under whose authority, against which systems, and whether the action can be reconstructed or reversed. That is shadow agency. It can exist inside a fully approved vendor when an employee creates an agent, connector, automation, or tool path that nobody owns at the organizational level.
Where agent sprawl hides
No single discovery source sees the whole estate. Endpoint inventory can reveal coding tools but miss a cloud workflow. Identity systems can see service principals but miss an agent borrowing a user's session. Provider billing can reveal model usage but not the tools the model can invoke. MCP configuration can expose connectors while saying little about the actions employees actually trigger.
Use overlapping signals and accept that inventory is a continuous process. Microsoft now treats agents as a distinct identity and governance problem, including lifecycle, sponsorship, and access. That direction is useful even outside Microsoft environments: every durable agent should have an accountable owner and a reason its access still exists.
- Endpoint software, shell history, coding tools, local agent settings, and automation
- OAuth applications, service accounts, API keys, agent identities, and delegated user sessions
- MCP servers, browser extensions, SaaS connections, automated workflows, and business platforms
- Model-provider usage, cloud spend, unusual API volume, and long-running jobs
- Live actions such as file changes, publishing, deletion, and outbound requests
Inventory capabilities, not product names
A product catalog becomes stale as soon as a team switches models or adds a tool. A capability inventory survives those changes. Record whether an agent can read or write local files, call the internet, query sensitive data, modify production, send communications, create identities, spend against metered services, or spawn other agents.
The inventory should also state what protection is actually possible. Can the company stop a dangerous action before it runs, or can it only discover the action afterward? Both are valuable, but calling after-the-fact visibility prevention creates dangerous confidence.
Make ownership operational
An owner is not a name in a spreadsheet. The owner should understand the agent's purpose, tools, data, cost center, expected behavior, and shutdown path. Ownership should expire. If an agent has no sponsor, no recent use, or no business justification, remove its authority before debating its prompt quality.
Treat material changes as new risk decisions. Adding an MCP server, enabling internet access, moving from read to write, connecting production data, or allowing unattended execution can increase the possible damage more than changing the underlying model. Those changes should create a review event that the owner and security team can understand.
Control sprawl without banning experimentation
A blanket ban pushes useful work into less visible places. A better policy gives teams a fast lane for low-risk experiments and a clear path to production. Let an agent work inside a bounded project with test data. Require stronger identity, network, data, and action controls as it reaches customer information, external communications, or production systems.
This zoned approach aligns with emerging platform guidance. Microsoft recommends risk-based governance zones for agents. Salesforce frames Agentforce security as shared responsibility, with customers responsible for permissions and agent guardrails. The common lesson is that vendor security does not remove the need for customer decisions about reach and consequence.
How Leash turns inventory into action control
Leash brings supported agent activity into one clear view, so teams can understand what agents are doing instead of merely counting installed products. It applies the same protections and records the result. Where Leash can intercept the action, it can stop or change it before harm occurs. Where a platform reports activity afterward, Leash provides visibility without overstating control.
Leash supports gradual adoption. Start with macOS and Windows computers where coding agents create immediate risk. Add Personal or Business Leash Cloud when web and optional mobile alerts are useful. Keep Personal Open Source completely local with your own provider key when cloud sign-in is not wanted. Moving between options keeps the same familiar protection.
The first inventory meeting
Ask engineering, IT, security, data, sales operations, and business application owners to bring one agent they already use or want to deploy. For each, map identity, tools, data, high-impact actions, owner, and monitoring path. Do not begin with a 200-question vendor assessment. Begin with the actions that would produce an incident report if they went wrong.
The first useful deliverable is a short agent register and three risk tiers. The second is instrumentation on a real workflow. Once leaders can see actual actions and approval volume, governance stops being hypothetical and policy becomes much easier to tune.