OSS
More deployment, credential, and custom policy flexibility. You operate the server and choose the infrastructure.
Enterprise Use
How Omnigent maps to org-level governance, SSO, cost control, auditability, and managed Databricks tradeoffs.
documented rollout patterns inferred
Omnigent becomes enterprise-relevant when the control plane is shared: one server, one auth surface, server-wide policies, common cost guardrails, and auditable session resources across different harnesses.
Governance layers
Policies can apply at three levels: session, Omnigent config, and server-wide. The docs say the levels are enforced simultaneously, with session rules checked first, Omnigent config second, and server-wide policies last. Source: policy overview.
Auth and SSO
Omnigent supports built-in accounts, OIDC SSO with providers such as Google/GitHub/Okta/Microsoft, and header-based auth behind a trusted proxy that injects identity headers. Admins can manage members and server-wide policies from the web UI. Source: Auth & SSO.
Audit surface
The OpenAPI surface exposes sessions, policy registry, session policies, comments, permissions, files, terminal resources, runner status, streams, environment filesystem changes, and more. That does not automatically make a compliance program, but it gives the server a real data plane for inspection and workflow automation. Sources: OpenAPI JSON, API reference.
OSS vs Omnigent on Databricks
Managed Databricks
Databricks operates the server and integrates with workspace identity, Foundation Model APIs, AI Gateway, and Databricks Sandboxes.
Omnigent on Databricks is documented as Beta. Limitations include built-in contextual policies only, no custom YAML-based policies, no native Windows support, Databricks Sandbox model access routed through AI Gateway, and no Databricks Sandbox use with serverless egress control enabled. Source: Omnigent on Databricks.