Skip to content

v0.24.0

Latest
Latest

Choose a tag to compare

View all tags
@cjellick cjellick released this 24 Jul 01:26
v0.24.0
8766dd0
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

We're excited to announce the v0.24.0 release of the Obot Platform. This release expands Device Management with AI client audit logging and MDM support, brings full audit logging to the LLM Gateway, and adds AWS Bedrock and Azure support to the LLM Gateway. It also reworks Obot's MCP proxy to substantially reduce its resource footprint.

Big Updates

Enhanced Device Management: AI Client Audit Logging and MDM Support

Obot's Device Management feature expands this release, built around a new companion tool called Obot Sentry. Administrators can define an MDM configuration, issue enrollment keys, and generate per-platform install packages so devices enroll themselves. Enrolled devices authenticate with device-bound keys and submit scans over short-lived signed tokens.

Once installed, either manually or pushed through an MDM, Obot Sentry does two things: it submits periodic device scans, and it installs managed hooks for supported local AI coding tools, currently Claude Code, Codex, Visual Studio Code, and Cursor. Every tool call those tools make is submitted back to Obot and recorded in the MCP Audit Logs, normalized into the same event schema as MCP tool calls so the two appear side by side. See the Upgrade Notes below if you export audit logs today, as the exported format has changed.

We are initially shipping with first-class support for Microsoft Intune, and plan to add other MDM providers such as Jamf in future releases.

Device Management, including MDM enrollment, remains in Beta, and the obot scan CLI command has been removed in favor of Obot Sentry-based scanning. See #7249 for details.

See the docs for details.

LLM Audit Logs

Obot now keeps a full audit trail of LLM Gateway activity. Every request that flows through the gateway is logged with its model, provider, user-agent, token usage, and outcome, and users with the Auditor role can view full request and response bodies. A new Audit Logs page under LLM Gateway supports filtering by provider, model, request path, status, user-agent, and session, along with one-time and scheduled export to S3, GCS, or Azure.

See the docs for details.

New LLM Gateway Model Providers: AWS Bedrock, Azure, and Generic Responses

The LLM Gateway adds three new provider options this release. AWS Bedrock can be configured with either static IAM credentials or a Bedrock API key, and routes Anthropic, OpenAI, and Google model families hosted on Bedrock through AWS inference profiles. Azure can be configured with an API key or an Entra ID service principal, covering both Azure OpenAI and Microsoft Foundry deployments. The Generic Responses provider, now out of experimental, lets Obot call any OpenAI Responses API compatible endpoint such as Ollama or LiteLLM.

If you were already using the previous Bedrock provider, you may need to update your API keys and reselect models, since credentials are scoped differently under the new provider. See the docs for setup details.

Composite MCP Servers: GitOps Support

Composite MCP catalog entries can now be defined through the Git-backed MCP catalog like any other server type. Component servers are referenced by a stable entry key instead of an internal catalog-entry ID, so a composite entry can reference components from its own catalog source or from a different one entirely.

MCP Proxy Rework: A Smaller Footprint

Obot's MCP proxy has been rewritten this release. Previously, remote and composite MCP servers were fronted by a distributed proxy, meaning every remote or composite server required its own Kubernetes pod or Docker container just to proxy traffic to it, consuming significant additional resources across a deployment. That proxy has now been moved entirely into the main Obot server process.

The result is a substantially smaller footprint: Obot now only deploys a pod or container when you choose to actually host an MCP server yourself (via the npx, uvx, or containerized runtimes), rather than for every remote or composite server it fronts.

See the Upgrade Notes below if you run Obot with the Docker backend.

Built-in Local Authentication

Obot now includes a built-in local authentication provider backed by its own database, so users can get up and running quickly when trying out Obot instead of spending time to integrate with an OAuth provider. It's aimed at development and testing and is not suited for production deployments.

Administrators enable the Local provider from Admin > Auth Providers, restrict it to specific email domains (or allow any), and create user accounts from a "Manage Users" dialog, which also handles password resets. Local users cannot change their own password; an admin must reset it, which signs the user out of all existing sessions. Passwords are hashed with Argon2id and are never stored or returned in plaintext.

Local authentication is intended for development and testing, not for production use.

See the docs for setup details.

Getting Started Guides

Obot now includes an in-app guided tour that highlights real interface elements and steps users through common tasks, replacing an older static tour. Separate guide tracks are available for end users, covering connecting to an MCP server and installing skills or the CLI, and for administrators, covering catalog entry creation and MCP access policies.

Guides can be hidden or re-enabled from the profile menu under My Account.

Improvements

  • Shared, admin-managed Git credentials can now be reused across Skill Repository and MCP Catalog sources instead of pasting a personal access token into each one.
  • SkillRepository sources can now sync from any Git host using a Personal Access Token, not just GitHub.
  • MCP config secret bindings can be managed directly from the UI when creating or configuring multi-user MCP servers.
  • Client ID Metadata Documents (CIMD) are now supported, letting OAuth clients present a URL-hosted metadata document instead of performing dynamic client registration.
  • Administrators can cap CPU and memory maximums for MCP servers with new environment variables, blocking catalog entries and defaults from requesting more.
  • Database connection settings (max open and idle connections, connection lifetime) can now be configured separately for the primary database, kinm, and the auth provider.
  • Users connecting to an MCP server for the first time from an external client can now supply required configuration inline instead of the connection failing outright.
  • Deprecated catalog entries now show a notice in the catalog, connect, and server-management views.
  • Administrators can configure an app-wide notification banner, grouped with Branding and License under a new App Management section.
  • LLM Gateway usage is now tracked with estimated USD cost per model, based on a new pricing pipeline.
  • SSRF protections against loopback, private, and link-local addresses now also apply to Client ID Metadata Document fetching and general OAuth URL fetching.

Upgrade Notes

This release contains several behavior changes and known issues. Review carefully before upgrading.

Known issue with Obot Sentry: macOS manual installs create multiple device identities. When Obot Sentry is installed using the macOS standalone binary instructions, audit hooks can use a different device identity from device scans. As a result, hook audit logs and inventory scans appear under different device IDs. See #7298 (#7298) for status and updates.

Helm chart configuration overhaul. Kubernetes installations now separate sensitive settings into a Secret and non-sensitive settings into a ConfigMap. Update your custom values before upgrading:

  • Rename config.existingSecret to secret.existingSecret.
  • Move credentials and other sensitive values from config.* to secret.*, including database DSNs, API keys, encryption keys, bootstrap tokens, license keys, and artifact-storage credentials. Known sensitive values left under config now cause chart rendering to fail.
  • External Secrets must provide all required sensitive values; bootstrap tokens are generated and preserved only for chart-managed Secrets.
  • When combining secret.existingSecret with mcpImagePullSecrets, provide OBOT_SERVER_MCPIMAGE_PULL_SECRETS in the external Secret.
  • OBOT_SERVER_MCPBASE_IMAGE no longer receives an automatic chart-version tag, so configure an explicit image tag if you relied on that behavior.

Additional Helm changes in this release:

  • A startup probe now gives Obot up to 20 minutes to become healthy.
  • Ingress configurations require at least one host when enabled.
  • MCP namespaces can be configured with a Kubernetes ResourceQuota.
  • Setting persistence.storageClass to "-" explicitly disables dynamic storage-class selection.
  • Configuration changes now automatically trigger pod rollouts.

See #7252 for details.

obot scan CLI command removed. Device scanning now happens through Obot Sentry, installed manually or via MDM, instead of the CLI. If you have scripts or automation calling obot scan, they will need to move to Obot Sentry instead. See #7249 for details.

Audit log export format has changed. The JSON shape of exported audit logs (S3, GCS, or Azure) has changed completely, replacing the old flat per-log-type shape with a single normalized event envelope shared by MCP and local-agent tool-call events. Anything consuming exported logs downstream will need to be updated to the new shape. See #7174 for details.

Old Slack MCP server deprecated. The original Slack MCP server in Obot's default catalog is now marked deprecated in favor of a new official Slack MCP server. There is no automatic migration; existing users should switch manually. The legacy Slack server will be removed completely by the end of August 2026. See #7173 for details.

Docker-mode users should clean up old shim containers. As part of the MCP proxy rework above, Kubernetes deployments clean up old shim containers automatically, but Docker-mode deployments will not remove them on their own. Remove them with:

docker ps -aq --filter "label=mcp.deployment.id" | xargs docker rm -f

See #7100 for details.

What's Changed

New Contributors

Full Changelog: v0.23.1...v0.24.0

Contributors

ibuildthecloud, cjellick, and 7 other contributors
Assets 9
Loading