A year ago, most conversations about AI governance were about the browser. Which chat tools are people pasting data into? Which SaaS copilots are switched on? Those questions still matter, but the centre of gravity has shifted. Today, the most powerful AI in your organisation is probably running on an engineer’s laptop: a coding agent in the terminal, an AI-native IDE, a desktop assistant wired to a dozen MCP servers, each one able to read files, run shell commands, and call internal APIs with the user’s own credentials.
This is a new kind of sprawl. A developer can install Claude Code, add an MCP server from a GitHub README, drop in a few skills and plugins, and be running autonomous tool calls against production data before lunch. None of that touches a procurement process, and very little of it crosses a network boundary your existing tools understand.
So the first question security and IT teams ask is simple: what is actually out there? Tools like Obot Sentry exist to answer it. But answering “what is out there” is not the same as deciding what is allowed to be out there. That gap, between visibility and control, is what this post is about, and why an endpoint agent on its own only gets you part of the way.
What an endpoint agent like Obot Sentry gives you
Obot Sentry is a lightweight companion agent that enrolls a workstation with the Obot platform, submits a device inventory on a schedule, and installs audit hooks into supported AI clients. The value is real, and it falls into three buckets.
Inventory: On each scan (hourly by default, configurable from 15 minutes to 24 hours), Sentry reports device metadata alongside the AI clients it finds, such as Claude Code, Codex, Cursor and VS Code, plus the MCP server configurations, skills and plugins each one is set up to use. For the first time, you can answer “how many machines have an unapproved MCP server configured?” with a number rather than a guess.
Audit: Sentry writes managed hooks into those clients so that when an agent calls a local tool, the event is sent to Obot and normalised into the same audit schema as traffic through the Obot MCP gateway. Local and gateway activity sit side by side, which matters when you are reconstructing what an agent did and why.
Policy, for supported clients: Obot also lets administrators define an allowlist of tools and servers, and hooked clients can be made to fail closed: a call with no matching allow rule, or from a server that cannot be identified, is blocked.
That last point is important, and it is also where the nuance starts.
Where visibility stops and control has to begin
An endpoint agent can only enforce what the operating system lets it enforce, on the clients it knows about, for as long as it stays installed and unmodified. Left to itself, on a device where the user holds local admin rights, each of those conditions is soft. This is not unique to Sentry: any solution that relies on client hooks or browser extensions has the same weakness, because a user with sufficient rights can disable the hook, remove the extension, or switch to a client that has neither.
The hooks live in files the user can edit. Sentry’s own documentation lists where its hooks go. Some are system-level, such as Codex’s requirements.toml under /etc/codex or %ProgramData%, and Cursor’s system hooks.json. Others, including Claude Code’s ~/.claude/settings.json and VS Code’s user settings, sit in the user’s home directory. A curious or frustrated developer can remove a hook entry, and the agent’s hourly re-install only closes that gap after the fact. Even system-level files are only protected if the user is not an administrator.
Coverage is per client. Hooks exist for Claude Code, Codex, Cursor and VS Code, and the docs note that local VS Code auditing does not support enforcement. Inventory may spot other tools, but a desktop chat app, a local model runner, or a freshly released agent CLI has no hook until one is built. Seeing a tool is not the same as governing it.
The agent itself can be stopped. A user with admin rights can kill the process, disable its scheduled task, or uninstall it. Sentry then simply stops reporting. You may notice the silence, but you cannot prevent it from the agent’s side.
It cannot shape the device. Sentry does not decide which applications may be installed, block a binary from running, restrict outbound traffic to an unknown MCP endpoint, or keep a non-compliant laptop away from company data. Those are operating-system and identity controls, not application-layer ones.
None of this is a flaw in Sentry. It is the natural boundary of any agent that runs inside an environment it does not own. Which brings us to the tool that does own it.
What a properly configured MDM adds
A mobile device management platform such as Microsoft Intune, Jamf or Kandji is the authority on the device. It turns Sentry’s soft conditions into hard ones. The word properly matters here: an MDM that only pushes Wi-Fi profiles and a wallpaper adds very little. Configured with AI governance in mind, it contributes five things.
Guaranteed deployment. Sentry is pushed to every device in scope, not only those whose owners ran an installer. Obot already ships an .intunewin package for this, and Sentry’s hook installer expects its path and enrollment credential to be delivered by the MDM.
Least privilege. Removing standing local admin rights, or granting them just-in-time, is what makes system-level hook files and the agent’s own service tamper-resistant. Without it, every other control is a suggestion.
Locked configuration. MDM can deliver managed preferences and policy files to system locations users cannot write to, and many AI clients now read enterprise policy from exactly those places. That moves hooks and allowlists out of the user’s home directory and into territory the user cannot quietly edit.
Application control. Allow and block lists, or tools like Windows App Control and macOS system extensions policy, decide which AI clients may be installed at all. This covers the long tail that Sentry can see but cannot hook.
Compliance and conditional access. MDM can report “Sentry installed and checking in” as a compliance signal. Tie that to your identity provider and a device that has stopped reporting also stops reaching company data, source code and internal MCP servers.
In short, MDM controls what can run and who can change it. Sentry reports what is running and what it is doing. Each is weaker alone.
Try Obot today — the open-source MCP gateway. Self-hostable, MIT licensed, full audit trail at every tool call.
The strongest pattern treats the two as one loop rather than two products.
Sentry discovers what is on each device. Administrators decide, in Obot, which clients, MCP servers and tools are approved. MDM and Sentry’s hooks enforce that decision together: MDM makes sure the agent is present, the policy files cannot be edited, and unapproved apps cannot be installed, while the hooks block unlisted tool calls inside supported clients. Audit events and compliance check-ins then verify that the policy is holding, and the next scan starts the loop again.
There is a third layer worth naming. Routing approved MCP traffic through a governed gateway, such as the Obot MCP gateway, means that even when an agent is allowed, its connections are authenticated, logged and scoped centrally. MDM decides what may run, Sentry sees what is running, and the gateway governs where it connects.
A useful way to test your setup: pick one laptop and ask what happens if its owner deletes the hook from their settings file, uninstalls Sentry, or installs a new AI client tomorrow. If every answer is “we’d see it in the dashboard”, you have visibility. If the answers are “they can’t”, “it would be reinstalled and the device would lose access until it was”, and “it’s blocked until approved”, you have control.
A practical starting checklist
If you are rolling out Obot Sentry, or any endpoint AI agent, these are the questions to settle with your device management team first.
Is Sentry deployed through MDM to every device in scope, with enrollment credentials delivered by policy rather than by hand?
Do standard users lack standing local admin rights, so they cannot stop the agent or edit system-level hook files?
Are AI client policy and hook files delivered to system locations, not left in user home directories?
Is there an application allowlist that covers AI clients Sentry cannot hook yet?
Is “Sentry checking in” a compliance signal wired into conditional access?
Is someone alerted when a device goes quiet, rather than finding out at the next audit?
Closing thoughts
Visibility is the right place to start. You cannot govern an AI landscape you cannot see, and Obot Sentry makes the local half of that landscape visible in a way few tools do. But visibility on an unmanaged, admin-rights laptop is observation with a polite request attached. Paired with a properly configured MDM, the same agent becomes part of an enforceable system: the device decides what may run, Sentry reports what is running, and the Obot gateway governs where it connects. That combination is what turns seeing into stopping.
