Obot Platform v0.25.0 is out. This release adds tool call enforcement for coding agents, MCP tunnels for securely reaching servers on private networks, and Agent Auth Scopes for issuing scoped credentials to autonomous agents. It also adds Obot Community to the existing Obot and Obot Enterprise offerings and makes all authentication and model providers available without an enterprise license.
Tool Call Enforcement for Coding Agents
It should come as no surprise that we see a strong centralized gateway as an important part of AI governance. It gives organizations a controlled path to models, MCP servers, skills, and other shared capabilities, backed by consistent access policies and audit logs. But not all AI activity flows through a gateway. Users can install coding agents on their workstations, connect them directly to local or remote tools, and add skills or plugins that administrators may not know about. Governing that activity is another part of the same problem.
As organizations try to get their arms around this activity, we are finding that effective workstation governance requires three steps:
Discover which coding agents people have adopted and which MCP servers, skills, plugins, and other tools they are using through them, including unapproved shadow IT.
Audit what those coding agents are doing.
Enforce rules before an action takes place.
Device management in v0.24.0 addressed the first two steps. In v0.25.0, administrators can also define an allowlist, and Obot Sentry checks each tool call against it through the coding agent’s pre-tool hook. Rules can cover broad categories, such as all MCP servers hosted by your Obot instance or all of a coding agent’s built-in tools, or identify a specific server and the tools allowed from it. This initial release supports Claude Code, Codex, and Cursor.
Enforcement fails closed. Obot Sentry blocks a call when no rule matches, when it cannot identify the MCP server behind the tool, or when it cannot reach Obot for a decision. Every decision is recorded in a new Enforcement Decisions view, where administrators can see why a call was allowed or blocked and filter activity by device, agent, server, tool type, and tool.
Tool call enforcement is experimental and is not yet recommended for production use. We recommend starting with auditing, observing the tools people actually use, and building the allowlist from that activity before testing enforcement on non-production devices. Visual Studio Code continues to support local tool call auditing but not enforcement because its pre-tool hook does not identify the MCP server associated with a tool call.
Hook-based enforcement currently depends on each coding agent exposing enough information before a tool runs. We will add support for more coding agents as demand grows, and we are also exploring network-proxy-based enforcement that would not require pre-tool hooks. We are looking for design partners and early adopters to help shape where this goes.
MCP Tunnels for Private Networks
MCP tunnels came directly from our experience operating Obot Cloud, where Obot often needs to reach MCP servers inside a customer’s private network. Until now, that meant making the server reachable from wherever Obot was running, which often required exposing it, changing the network, or moving the Obot deployment.
MCP tunnels remove that requirement. An obot tunnel process runs on a machine that can reach both Obot and the private MCP server, then opens an outbound, authenticated WebSocket connection to Obot. Requests are sent through the tunnel to the server’s existing URL and the responses are returned the same way, with no inbound port or firewall change required.
Tunnels also make it possible to expose those internal servers through Obot to hosted agents such as claude.ai, while keeping the servers themselves on the private network.
Agent Auth Scopes
Autonomous and headless agents cannot complete an interactive browser sign-in, so they need credentials they can carry. Those credentials should also be limited to the work the agent is expected to perform rather than inheriting all of its owner’s access.
In v0.25.0, users create an Agent Auth Scope, and Obot generates an API key that the agent presents as a bearer token. A scope can grant access to specific MCP servers, the Obot API, the LLM proxy, skill downloads, and device scans, and it can include an expiration date. Every scope remains bounded by the permissions of the user who owns it.
What was previously called API Keys is now Agent Auth Scopes. Users manage them from the top-level navigation, while administrators manage them under Auth Management. The feature is designed for agents running in CI and other automated systems, and it will also serve as the foundation for a more consistent authorization model across autonomous agents, connected coding agents, and hosted agents running inside Obot.
Obot, Obot Community, and Obot Enterprise
Obot is now offered as Obot, Obot Community, and Obot Enterprise, with in-app upgrades that do not require changing images or redeploying. This gives everyone access to all authentication and model providers without requiring an enterprise license. Existing deployments should review the v0.25.0 upgrade notes to see how this change affects them.
