AI Agent Governance: How to Govern Agentic AI That Doesn't Live in a Browser

AI Agent Governance: How to Govern Agentic AI That Doesn't Live in a Browser

The short answer

AI agent governance (or agentic AI governance) is the practice of controlling what autonomous and semi-autonomous AI tools can access, which accounts they run under, and what data they send to model providers. The hard part: agents rarely run in a browser tab. They run in desktop apps, IDE assistants, command-line tools, and scripts that call model APIs directly.

That means browser extensions and DNS filters can't govern them. You need an enforcement point at the operating-system level that sees every process on the device. That's where dope.security's on-device secure web gateway sits.

Why agents break traditional AI governance

Chat-based AI was easy to picture: a person, a browser tab, a prompt. Agents are different. A coding assistant reads your repository and sends context to a model API. A desktop AI app uploads files in the background. A Python script loops through customer records and calls an LLM on each one. An MCP server connects an AI client to internal tools.

Look at what the network sees:

Originating processDestinationBusiness context
chrome.exechatgpt.comEmployee chatting in a browser
ChatGPT.exechatgpt.comDesktop app, outside browser controls
cursor.exemodel provider APIIDE agent sending source code
python.exeapi.anthropic.comScript processing data in bulk

The domain alone doesn't explain the risk. The originating process does. (More on detecting AI in desktop apps, IDEs, and CLIs.)

Where each control type stops

  • DNS security sees destinations, not prompts, processes, or accounts.
  • Browser extensions and enterprise browsers stop at the browser boundary. They can't see ChatGPT Desktop, Claude Desktop, IDE agents, or scripts.
  • Provider audit logs only cover your enterprise accounts, and only after the data has reached the provider.
  • Cloud proxy SWGs can inspect native traffic when their agent steers it to a data center, but every agent call then detours through that data center.

The endpoint-native approach to agentic AI governance

dope.security intercepts traffic at the operating-system networking layer, redirects it to a local proxy on the device, inspects it, applies policy from a locally cached copy, and then lets allowed traffic go directly to the AI service. Because the control runs on the endpoint, it can associate a connection with the process that created it, and its detailed telemetry can include the process name alongside domain, full URL, verdict, and DLP findings.

For agents, that unlocks four controls:

  1. Visibility across channels. Browser, desktop app, IDE, and script traffic all pass through the same enforcement point. dope.security's Claude controls, for example, cover both the web and desktop apps.
  2. Account control. Cloud Application Control allows only your approved Claude organization IDs and ChatGPT workspace IDs, and now covers GitHub, so code and agent workflows stay on enterprise accounts.
  3. Content inspection before transmission. Dopamine DLP inspects prompts and uploads and now covers Anthropic API traffic, so a script sending customer PII to Claude can be stopped before the provider receives it.
  4. Fast oversight. AI Usage Analytics shows which AI apps and users generate the most activity, and the Dopamine Assistant answers questions like "which users sent source code to AI this week?" in seconds.

MCP servers and the new shadow AI

The Model Context Protocol lets AI clients connect to tools and data sources. Each MCP server is a new path for data to leave, and many reach the internet from developer machines. Governing them starts with seeing the traffic on the device that runs them. See MCP server security and governance and why on-device architecture fits shadow MCP.

The honest limits

Endpoint-native doesn't mean universal. Some native AI clients use certificate pinning and refuse interception certificates; those flows must be bypassed, which means their prompts stay encrypted. dope.security detects these SSL errors and lets admins bypass by app or URL, and Cloud Application Control stays enforceable even with SSL bypass enabled. Before you roll out, test the specific agents your teams use: browser, desktop clients, IDE plugins, and API calls from scripts.

An agent governance checklist

  1. Inventory AI agents and clients by process, not just domain.
  2. Approve enterprise tenants for every agent that supports them (ChatGPT, Claude, GitHub).
  3. Block personal accounts for those services.
  4. Turn on DLP for prompts, uploads, and API calls to supported providers.
  5. Decide on bypasses for pinned clients deliberately and document them.
  6. Review agent activity monthly with the Dopamine Assistant.

FAQ

What is AI agent governance?

AI agent governance controls which AI agents can run, which accounts they use, what data they can send to model providers, and how their activity is monitored.

Why can't browser-based AI controls govern agents?

Most agents run outside the browser, in desktop apps, IDEs, CLIs, and scripts. A browser extension never sees that traffic.

Can dope.security see AI traffic from scripts and IDEs?

dope.security intercepts traffic at the operating-system level, so connections from browsers, desktop apps, and other processes pass through its local proxy. Dopamine DLP covers documented workflows including Anthropic API traffic. Validate the specific tools your developers use during a trial.

Govern the agents, not just the chatbots

Deploy the agent and see every AI client on your endpoints, by process and by account.

Start your free trial or book a 20-minute demo.

AI Governance
AI Governance
Shadow MCP
Shadow MCP
Shadow AI
Shadow AI
← back to blog Home