The Obot Platform v0.24.0 release is out. It adds audit logging for AI activity that previously happened outside Obot. A new companion tool, Obot Sentry, captures tool calls made by Claude Code, Codex, Visual Studio Code, and Cursor on developer machines and sends them to Obot’s existing audit logs. This release also adds full LLM Gateway audit logs, three new model provider options, and a reworked MCP proxy that substantially reduces the resources required to run Obot.
Teams are trying to understand what AI is doing across their organizations, but there is no single deployment pattern. Some route model traffic through an LLM gateway. Others allow a range of local AI clients to connect directly to models and tools. Most have a mix. v0.24.0 gives administrators more ways to build the level of visibility and control that fits their environment.
Obot Sentry: Device Management and Local AI Client Audit Logs
Device Management started in v0.22.0 with inventory. Administrators could scan a workstation and see its AI clients, MCP servers, skills, and plugins. The missing piece was deployment: a user had to run obot scan, and the scan only described what was installed at that moment.
v0.24.0 replaces that command with Obot Sentry, a lightweight companion agent that enrolls a workstation with Obot, submits device inventory on a schedule, and maintains audit hooks for supported AI clients. Device Management remains a Beta feature.
Administrators set it up from the new Configuration view under Device Management. The workflow creates an enrollment key, selects an installation method and operating system, and generates the corresponding install package and instructions. Enrollment keys can be named, given expiration dates, and revoked independently. Once a device enrolls, it uses device-bound credentials and short-lived signed tokens when submitting scans and audit events.
The first managed deployment path is Microsoft Intune for Windows. Obot generates an .intunewin package that an administrator can assign to device groups from the Intune admin center. The package installs Obot Sentry when those devices check in, then runs scans and maintains audit hooks automatically. Windows users can also install an MSI themselves, while macOS users can run the standalone Obot Sentry binary. The default scan interval is 60 minutes and can be configured from 15 minutes to 24 hours.
We started with Intune because it is the most common MDM platform among the teams we work with. Jamf, the leader for macOS device management, is the next integration we are evaluating. We are also looking for design partners using other MDM platforms so the next integrations reflect how their fleets are actually managed.
Inventory is only one of Sentry’s jobs. It also installs managed hooks for Claude Code, Codex, Visual Studio Code, and Cursor. When one of those clients calls a local tool, Obot Sentry sends the event to Obot. Obot normalizes it into the same audit schema used for MCP calls, so an auditor can review activity from local agents and MCP servers side by side instead of reconstructing it from unrelated client logs.
This matters because the AI client ecosystem is diverse. Different clients expose tools, MCP servers, model access, and session data in different ways. An LLM gateway can provide a strong audit point for model traffic, but it is not the right or only answer for every environment. Sentry adds another option to the tool belt and covers activity that never crosses a centralized gateway.
Longer term, we plan to use Obot Sentry to collect chat session and token information for reporting and cost analysis. We are also exploring enforcement hooks that can reject unauthorized local tool calls or MCP servers. At the other end of the control spectrum, we are looking at fully hosting existing AI agents in a sandbox. Different organizations will choose different levels of governance, so we want the platform to support a range from visibility to enforcement and isolation.
Full Audit Logs for the LLM Gateway
The LLM Gateway can already give coding agents a single endpoint for models while Obot controls which users can access which models. v0.24.0 adds the audit trail around that traffic.
Every request through the gateway now records the user, provider, requested and target models, request path, user agent, client session, IP address, token usage, duration, response status, and outcome. Administrators can filter by provider, model, path, status, client, session, user, or time range. This makes it possible to follow one coding session across a set of model requests or isolate failed requests to a particular provider.
Sensitive request and response content is encrypted in the database. Admins can view operational metadata, while only users with the Auditor role can decrypt and inspect full bodies and headers. Logging happens asynchronously rather than in the model request path.
The same page supports one-time and scheduled JSONL exports to S3, Google Cloud Storage, or Azure. The default retention period is 90 days, so scheduled export provides a path for organizations that need longer retention or want to send the data to their existing compliance and analysis systems.
Together, Obot Sentry audit events, MCP audit events, and LLM Gateway audit events cover three different places where agent activity can occur. Teams can use the pieces that match their architecture rather than forcing every client and model through one path.
We don’t think getting a complete audit trail should require a company to standardize on one AI client or route every interaction through one model provider. The ecosystem is too diverse for that. Our goal is to meet teams where their activity already happens and bring those signals together in Obot.
AWS Bedrock, Azure, and Generic Responses Providers
The LLM Gateway adds three provider options in this release: Amazon Bedrock, Azure, and a Generic Responses Compatible endpoint.
Amazon Bedrock can authenticate with static IAM credentials or a Bedrock API key. Obot exposes Anthropic Messages and OpenAI Responses compatible routes over Bedrock Mantle, covering Anthropic, OpenAI, and Google model families available as AWS Bedrock models. Claude Code can use the Anthropic-compatible route, while Codex can use the Responses-compatible route. Users still authenticate to Obot with an Obot API key, and Obot applies the same Model Access Policies used for other providers.
Azure support covers Azure OpenAI and Microsoft Foundry deployments. Administrators can configure an Azure API key or an Entra ID service principal. Obot uses the request endpoint to select the Anthropic Messages or OpenAI Responses dialect, while clients address each model by its Azure deployment name.
The new Generic Responses provider connects Obot to any OpenAI Responses API compatible endpoint, including Ollama and LiteLLM, with an optional upstream API key. This provides one supported route for local models and third-party gateways instead of requiring provider-specific implementations.
We don’t expect enterprise model stacks to consolidate around one provider. Teams want to choose models based on capability, cost, data requirements, and existing cloud commitments. Obot should give them that flexibility without creating a different governance model for every provider.
Existing users of the previous Bedrock provider should check their configuration during the upgrade. The new routes use differently scoped credentials and a different model list, so API keys or Model Access Policy selections may need to change.
Composite MCP Servers Through GitOps
Composite MCP servers combine selected tools from multiple MCP servers behind one connection. They could be created through the Obot UI, but they did not work through Git-backed catalogs. That left a gap for teams managing the rest of their MCP catalog through GitOps.
In v0.24.0, composite catalog entries can be defined and managed through the same Git-backed workflow as other server types. Teams can keep composite definitions in version control, review changes before they are applied, and synchronize them into Obot with the rest of the catalog. A composite can include components from its own catalog source or another source, so teams can build curated tool collections without moving their underlying server definitions into one repository.
A Smaller MCP Proxy Footprint
The MCP proxy has been moved into the main Obot server process. Previously, every remote or composite MCP server required its own Kubernetes pod or Docker container just to proxy traffic. Hosted npx, uvx, and containerized servers also ran a proxy sidecar next to the server itself.
Remote and composite servers no longer create those deployments at all. Hosted servers now run only the MCP server container. Authorization, audit logging, filters, and the external connection behavior remain the same, but deployments with many remote or composite entries no longer pay a per-entry infrastructure cost for proxying them.
A remote MCP server is fundamentally a connection, and registering one should not require deploying another workload. Moving the proxy into Obot makes the runtime architecture better match that model.
Kubernetes installations clean up the old proxy workloads automatically. Docker installations need a one-time cleanup of the old containers; the command is included in the upgrade notes below.
Built-in Local Authentication
Obot can now authenticate users with an email address and password stored in its own database. It is designed for quickly trying Obot and for development or test environments where configuring GitHub, Google, Entra ID, or another external OAuth2 identity provider would add unnecessary setup.
An administrator enables the Local provider under Admin > Auth Providers and creates accounts from the Manage Users dialog. This provides a short path from installing Obot to signing in and exploring the platform. Local authentication can also run alongside other configured providers.
In-App Getting Started Guides
Obot now includes in-app guides that point to real controls in the interface. End-user guides walk through connecting to an MCP server, installing a skill, and installing the Obot CLI. Administrator guides cover creating hosted, remote, or composite catalog entries and configuring MCP access policies.
The Getting Started control appears for new users and remains available while they work through the guides. It stays out of the way on forms where it could overlap Save and Cancel buttons, and users can hide it or re-enable it later from My Account.
Additional Improvements
Shared Git credentials can be reused across Skill Repository and MCP Catalog sources.
Skill repositories on any Git host can authenticate with a Personal Access Token.
MCP configuration secret bindings can be managed from the UI.
Administrators can set CPU and memory maximums for hosted MCP servers.
Database connection pools can be tuned independently by service.
OAuth clients can use Client ID Metadata Documents.
LLM Gateway usage now includes estimated model costs.
External MCP clients can provide required configuration on first connect.
Deprecated catalog entries now show notices throughout the UI.
Administrators can configure an application-wide notification banner.
Upgrade Notes
Helm chart configuration now separates sensitive and non-sensitive settings.
The obot scan command has been removed in favor of Obot Sentry.
Audit log exports use a new normalized event format.
Docker installations may need to remove old MCP proxy containers after upgrading.
The legacy Slack MCP server is deprecated in favor of the official Slack server.
See the v0.24.0 release notes for the complete list of improvements and detailed upgrade instructions.
Get started
That is v0.24.0: better visibility across local agents, MCP, and model traffic, with more ways to govern AI and less infrastructure to manage.
