The Assistant in the Conference Room: Auditing the AI Tools Your Departments Deployed Without IT
Somewhere in your organization right now, a paralegal is pasting a draft contract into a chatbot. A marketing director is connecting an AI assistant to the shared Google Drive. A finance analyst is asking a copilot to summarize accounts-payable data it has permission to read — permission granted months ago, to a service nobody in IT provisioned.
None of this appeared on a change board. None of it generated a ticket. And in most US enterprises, none of it is logged anywhere your security team can see.
The shadow AI problem has outgrown the shadow IT problem of the 2010s, and it did so in a fraction of the time. The reason is simple: cloud apps stored files. AI assistants act. They hold credentials, query systems on a user's behalf, and — critically — can be manipulated into moving data in directions no human would approve.
The Inventory You Don't Have
Start with an uncomfortable exercise: ask each department head to list the AI tools their teams use. Then compare that list against what your CASB, SSO logs, and egress monitoring actually show. In engagements across the past year, the delta between the two lists routinely runs above fifty percent.
The gap exists because these tools onboard themselves. A single credit card and a corporate email address unlock enterprise-grade capabilities — including OAuth scopes that request read access to mail, calendars, and document stores. Users, conditioned by years of clicking "Allow" on consumer apps, grant them without a second thought.
Until you have that inventory, every other conversation about AI governance is theoretical. You cannot govern what you have not counted.
Prompt Injection Is a Data Exfiltration Technique
Security leaders tend to file prompt injection under "AI research problem." That framing understates the operational risk. Treat it instead as what it functionally is: a delivery mechanism for data theft that bypasses DLP controls designed around human-initiated transfers.
Consider the mechanics. An assistant with broad document access processes untrusted content — a vendor email, a shared PDF, a public web page. Embedded in that content sits an instruction the model obeys: retrieve the contents of a folder and render them into a summary, a link, or an outbound request. No malware. No credential theft. The exfiltration happens through a sanctioned integration using legitimate API calls, indistinguishable from ordinary usage in most logs.
Traditional controls fail here for a structural reason: DLP inspects what leaves the network, but an LLM integration may never move data off-network in a form the tooling recognizes. The data crosses a trust boundary inside the model's context window, then re-emerges shaped as something innocuous.
Over-Permissive Integrations: The Quiet Privilege Escalation
The second structural risk is authorization sprawl. Every AI agent you allow into the environment becomes a new identity — one that often inherits more access than the human who created it.
Audit a typical deployment and you'll find OAuth grants that outlive their purpose: a pilot project's assistant still holding read access to the HR drive six months after the pilot ended; a scheduling agent with mailbox-level permissions granted to an entire executive team; a document-summarization tool whose scopes were widened "temporarily" during a rollout and never narrowed back.
This mirrors the service-account sprawl that has plagued Windows environments for two decades, with one aggravating difference: AI agents consume permissions dynamically. What a service account can touch is enumerable. What an LLM will do with access depends on what it's asked — and by whom, or by what.
A Governance Framework That Fits on One Page
The remedy does not require freezing AI adoption, which is neither feasible nor wise. It requires applying controls your organization already understands to a new class of actor. Four steps:
First, register, don't ban. Establish a lightweight intake — a form, a two-day review — so departments have a legitimate path to adoption. Prohibition guarantees concealment; a fast lane buys visibility.
Second, scope every integration to least privilege. No AI tool needs tenant-wide access on day one. Grant by library, folder, or mailbox. Set OAuth token expiry. Re-review scopes quarterly, the same cadence you apply to privileged human accounts.
Third, log the agent as an identity. Route AI tool activity through your SSO and SIEM. You want to answer, after an incident, not only who accessed data but what instructions the assistant processed. Vendors increasingly expose audit APIs; require them contractually before renewal.
Fourth, brief users on the injection threat the way you brief them on phishing. The rule of thumb is easy to remember: untrusted content should never reach an assistant that holds trusted access. That one habit neutralizes the majority of injection-based exfiltration scenarios.
Before the Auditors Ask
Regulators are already moving. The SEC's disclosure expectations, state privacy statutes in California and Texas, and sectoral requirements in finance and healthcare all converge on the same question: can you demonstrate control over systems that process sensitive data? "We didn't know the tool existed" is not an answer that survives an examination.
The organizations that navigate the next audit cycle cleanly will not be the ones that moved slowest on AI. They will be the ones that treated every copilot, agent, and assistant as what it is — a privileged actor with a language interface — and governed it accordingly.
The assistant in the conference room already knows the password. The only question left is whether anyone at your organization is watching what it does with it.
