The AI Agent Risk Nobody Can Patch With a DLP Rule
A few years ago, the uncomfortable AI security question was simple: "Did somebody paste customer data into ChatGPT?"
That question still matters. It matters a lot. But it is no longer the whole story.
The more interesting shift in the last week of AI security coverage has been the move from data leakage to agency. Google News is full of the theme: Help Net Security writing about the enterprise AI governance gap, Palo Alto Networks positioning agentic AI governance inside the browser, Forbes arguing that the real risk is not just what agents see but what they can do, and Lookout tying mobile AI usage back to shadow AI governance. Different vendors, different angles, same underlying problem.
AI has moved from a chat window to a work surface.
That changes the security model.
From "what did the employee paste?" to "what can the agent touch?"
Traditional AI governance often starts with content inspection. Watch prompts. Detect sensitive data. Warn the user if they try to send a contract, a source file, or a customer record to an unmanaged tool.
That is sensible. It is also incomplete.
An agent can read a calendar, summarize a board pack, create a ticket, draft a pull request, query a CRM, send a message, update a workflow, and trigger another system. Sometimes it does this inside a sanctioned product like Microsoft Copilot or ChatGPT Enterprise. Sometimes it happens inside a developer tool, a browser extension, a mobile app, or a team-built automation that security has never seen.
The risk is no longer only the data leaving the building. It is the action coming back in.
A DLP rule can catch an employee pasting a tax file into a public chatbot. It cannot easily answer: which agent had access to the finance drive, why did it summarize the board folder, who approved the connector, and did it just invite an external user to the wrong workspace?
That sounds dramatic, but the everyday version is boring and therefore more dangerous. An employee connects an AI note taker to meetings. A team lets a research agent crawl internal documents. A developer gives a coding agent broad repository access because the sprint is slipping. A sales ops team wires a helpful assistant into the CRM and Slack. Nobody is trying to be reckless. They are trying to get work done.
Security teams are then left governing a system that looks less like software inventory and more like a growing set of semi-autonomous coworkers.
Mobile makes the visibility problem worse
The mobile AI governance angle is easy to underestimate.
Most enterprise AI programs still think in desktop terms: browser controls, SaaS logs, identity provider events, endpoint agents, maybe CASB coverage. Meanwhile, employees are using AI from phones and tablets because that is where work happens between meetings, in airports, on client sites, and at home after dinner.
Mobile is where the boundary between personal and corporate gets messy. A personal AI app can summarize a screenshot. A keyboard extension can rewrite a customer response. A voice assistant can capture meeting notes. A consumer productivity app can touch files synced from corporate accounts. Some of these tools are excellent. Some are opaque. Many sit outside the control plane security leaders actually monitor.
This is why the emerging regulatory and vendor attention around mobile AI governance is worth taking seriously. It is not a niche MDM issue. It is part of the same shadow AI problem, just on a device class where visibility has historically been weaker.
If your AI inventory only covers managed SaaS and desktop browser traffic, it is probably undercounting the real adoption curve.
The browser is becoming a governance battleground
Another clear signal: enterprise browsers and secure access vendors are racing to become the place where agentic AI gets governed.
That makes sense. The browser sees a lot. It can observe which AI tools employees use, apply policy at the moment of interaction, and reduce risk without forcing every team into one approved assistant. For many companies, that is much more practical than trying to block AI outright.
But browser-level governance is only one layer.
Agents do not live exclusively in browser tabs. They live in desktop apps, IDEs, mobile apps, workflow platforms, chat tools, document suites, and internal automations. They also increasingly call APIs directly. A browser can be a strong choke point for some behavior, but it is not a complete map of enterprise AI usage.
The companies that get this right will treat the browser as a sensor and control surface, not the entire governance strategy.
What security teams should do now
The old advice was "write an AI policy." Fine. Write the policy. But the useful work is more operational.
Start with four questions.
First: what AI tools and agents are actually being used across the company? Not what procurement approved. Not what the policy mentions. The actual tools.
Second: what data can each tool or agent access? Separate read access from write access. Summarizing a document is different from editing it. Reading a CRM note is different from creating an outbound sequence.
Third: what actions can these systems take, and under whose identity? This is the agentic identity question. If an AI assistant files a ticket, updates a record, or sends a message, your logs should make that clear. "Bastien did it" is not good enough if Bastien clicked one approval and an agent performed ten downstream actions.
Fourth: where should employees be guided rather than blocked? A warning at the right moment can be more effective than a blanket ban. If someone is about to paste confidential data into an unmanaged AI tool, give them a safer path. If a team is using an agent for legitimate work, help them bring it under governance instead of driving it further underground.
This is the practical middle ground: discover, tier, govern, and coach.
The uncomfortable part: adoption is already ahead of governance
Most employees are not waiting for the AI steering committee. They are trying tools, connecting assistants, and building small automations because the productivity gains are obvious. That is not a failure of culture. It is the normal pattern of useful technology adoption.
The failure would be pretending it is not happening.
Security teams do not need to become the department of no. They need enough visibility to know where AI is being used, enough context to separate useful adoption from unacceptable risk, and enough guardrails to keep employees moving safely.
That is the direction the market is pointing: not AI blocking, not one-size-fits-all chat governance, but a workforce AI security layer that can see tools and agents across the company, understand risk, and intervene in context.
The next governance gap will not be caused by an employee pasting the wrong paragraph into a chatbot. It will be caused by an agent with too much access, too little auditability, and no one quite sure who owns it.
That is the gap worth closing now.
