one of the most alarming things a security executive said in a recent MIT survey on enterprise AI risk wasn't about a specific attack or breach. it was this: the concern was "not knowing the number of AI agentic tools internal to the tenant or way of determining the number."
sit with that for a second. a technical executive at a large company doesn't know how many AI agents are running inside their own infrastructure. not "we're worried about unauthorized access." not "we can't audit the outputs." the problem is more fundamental: they can't even enumerate what's there.
this is the shadow IT problem, except the shadow is now autonomous.
how we got here
shadow IT has existed as long as enterprise software has. employees want tools that work better than whatever IT approved. someone downloads Dropbox. someone pays for a Slack workspace with a credit card. IT eventually finds out, usually after the fact, and either blesses it or bans it.
the shadow AI agent problem is the same dynamic with a different consequence profile. when someone connects a third-party AI agent to their Salesforce via OAuth, they're giving that agent access to customer data, deal history, communication logs. the agent can read and write. if the prompt injection surface is exposed, the agent can be manipulated by a malicious email in the inbox it's processing.
the difference from the Dropbox scenario is the agent is active. it takes actions. it calls APIs. it sends emails. it makes decisions. shadow Dropbox stores data in a place IT doesn't control. shadow AI agents do things in contexts IT doesn't control, with whatever permissions the employee granted on a Tuesday afternoon when they were trying to automate their email triage.
the Microsoft Copilot incident is the template
in February 2025, a zero-click vulnerability was disclosed in Microsoft Copilot. hackers could access user data without any interaction from the user at all. no phishing email to click. no malicious link. the attack worked because Copilot had broad access to the user's context and the attack could be delivered through content that Copilot was going to process anyway.
this is the threat model that matters for AI agents specifically: the attack surface isn't the agent's interface. it's everything the agent reads. an AI agent that monitors your email is a prompt injection target for anyone who can send you an email. an AI agent that reads your Notion workspace is a prompt injection target for anyone who can edit a page you've shared. the attack surface is defined by the agent's data access, not by what the agent exposes.
and now imagine an employee has connected six different AI agents to their work accounts, none of which IT knows about. each one is an attack surface. each one has its own access policy, its own security posture, its own supplier chain of model providers and third-party APIs. the organization has no visibility into any of it.
why enumeration is so hard
with traditional software, you can inventory what's installed. add a software asset management tool, poll the endpoints, compile a list. agent deployments don't work this way. most enterprise AI agents connect through OAuth, through API keys stored in personal accounts, through browser extensions. they don't install anything on the endpoint. they sit in the cloud, attached to the SaaS tools your employees already use.
there's also a definitional problem. what counts as an AI agent? is a Zapier workflow that calls a GPT API an agent? is a spreadsheet with a GPT function an agent? is Microsoft Copilot itself — which was installed by IT as a blessed tool — an agent that could behave in ways IT didn't anticipate? the taxonomy is unclear, which makes the inventory harder.
and the deployment pace is outrunning governance. at the current rate of AI product launches, a new agentic tool capable of enterprise integration ships somewhere every few days. IT policies written for last year's threat landscape are already stale.
the asymmetry that makes this dangerous
the standard enterprise security posture assumes you know your attack surface. you know what's connected to what. you know what has what permissions. you can model the blast radius of a compromise.
AI agents break this assumption because their deployment is decentralized to the employee level. the organization didn't decide to give a third-party AI access to its CRM. an individual employee decided that, probably by clicking "allow" on an OAuth screen without reading it. multiply that by thousands of employees across dozens of AI tools, and the organization's effective attack surface is radically larger than anyone in security has visibility into.
the financial services CEO who said they were worried about "infiltration, in and out in seconds and leaving no trace" is describing exactly this. a compromised AI agent with broad access can exfiltrate data or take actions in a way that's hard to detect, because the agent's normal operating behavior looks similar to its compromised operating behavior. anomaly detection built for humans behaving oddly doesn't necessarily flag an agent behaving oddly.
what good looks like
the organizations ahead of this problem are treating AI agent access as a first-class governance problem, not an IT hygiene problem. that means: OAuth scope visibility at the organization level, not the individual level. policies about which SaaS connectors are permitted for AI agents. mandatory disclosure for employee-deployed AI tools that touch customer data. logging at the API call level, not just the user session level.
some of this is just extending existing practices. you already restrict which software can be installed on endpoints. the same principle applies to which agents can connect to which systems. but it requires recognizing that the threat is real, which requires being willing to enumerate a surface you currently can't see.
the conversation about AI risk is mostly about outputs — what does the AI say, does it hallucinate, is the answer harmful. the harder problem is inputs and access — what does the AI see, what can it touch, and who else can steer it once it's embedded in your infrastructure. the companies that figure out the second problem before they have a breach will have a significant advantage over the ones that figure it out after.