GovernorAIby SentinelLayer Request a briefing
Find and qualify
Discovery & Shadow AIInventory the AI activity nobody registered AssuranceEvaluate an agent snapshot before production
Decide and enforce
Policy & GovernanceKeep the policy engine you already run Runtime EnforcementDecide at the action boundary Inference & Model GovernanceGovern the model call itself Multi-cloudOne policy, each cloud's own controls
Prove and observe
Evidence & ComplianceTamper-evident record, mapped to controls Decision ObservabilitySee the decision behind the action
Risk and security
RiskScore the action, and act on the score ContainmentStop a runaway run before it lands Security architectureHow the control plane itself is built
By persona
SecurityPer-call authorization and stop controls GRCEvidence chains and control mapping Platform & AI EngineeringGovern without touching the agent
By risk
Shadow AIUnmanaged agents and connections Data leakageIn prompts, completions and tool calls Destructive actionsChanges to systems of record
By platform
AWS BedrockInbound path, guardrail attachment ServiceNowNow Assist discovery and scoped control SalesforceAgentforce and Einstein Bots, in-org MCPRegistry, proxy, argument-aware inspection
By cloud and runtime
AzureConnect, discover, govern at the gateway Google CloudValidated connect mode, bootstrap session DatabricksCluster-side egress, pinned at create Kubernetes & sidecarIn your cluster, on the agent host

USE CASES / DATABRICKS

Governance a cluster cannot be created without.

Notebook and job code on a Databricks cluster reaches the network directly. GovernorAI governs it at the host: an egress agent on every node, pinned by a cluster policy, so a cluster created from that policy cannot omit governance at create time.

Host-level egress governance Pinned at cluster-create Fail-closed on any init error
ARCHITECTURE SELECTED ON uname -m x86_64 · amd64 amd64 binary, published SHA-256 sidecar aarch64 · arm64 arm64 binary anything else fails closed The cluster policy pins the init script and HTTPS_PROXY, so a cluster created from it cannot omit governance. The control is at creation, not at review.

Notebook and job code reaches the network directly, so the egress agent runs on every node — pinned by a cluster policy, which is what makes it impossible to create a cluster that omits governance. An unrecognised architecture fails closed rather than running unguarded.

pinned at createSHA-256 sidecarfails closed

THE INSTALL KIT

Two artifacts, and what each one guarantees.

Artifact
Role
Cluster-scoped init script
Runs on every node at cluster start. Downloads the egress agent, verifies it, and supervises it. Any error in that sequence fails closed rather than starting an ungoverned node.
Cluster policy template
Pins the init-script path and the HTTPS_PROXY environment variable. A cluster created against this policy cannot be defined without governance — the control is at creation, not at review.
Egress agent
Governs the CONNECT tunnel at the host, so the decision applies to traffic the notebook makes directly.
SDK transport
A Python egress session for the SDK path, where the workload is instrumented rather than governed at the host.

ARCHITECTURE HANDLING

Both architectures, and a refusal for the third.

Release publishes signed binaries for both supported architectures; the init script selects on uname -m.

Cluster architecture
Behaviour
x86_64 / amd64
The amd64 binary, with a published SHA-256 sidecar for verification.
aarch64 / arm64
The arm64 binary, same verification. The cluster policy's runtime-version pattern admits ARM variants, so no manual mirror step is required.
Anything else
Fails closed. An unsupported architecture will not start ungoverned. Two explicit environment variables must both be set to take the documented mirror-binary escape hatch.

Windows and macOS clusters are out of scope, because Databricks runs Linux.

Honesty note

Per-cluster posture is in the product, with two caveats. The console reads it from /databricks-clusters/posture over a lookback window. Activity arriving only through the SDK transport cannot always be pinned to the cluster it came from, so those rows group under a synthetic unknown cluster and the response carries an attribution note saying so. The underlying table is scoped to the organisation rather than to one connection, so an organisation running several Databricks workspaces sees their clusters pooled in one view. The cluster policy and the agent remain the authoritative check.

Release status. The cluster-egress lane shipped as a four-part implementation, and every piece this page describes is in the product: the egress agent, the init-script and cluster-policy templates, the Python SDK transport, and a harness for verifying the lane end to end against a workspace. Two limits that were open at first release are now closed — a cluster that reaches the internet through a corporate egress proxy is handled, and a cluster running both the agent and the SDK transport can be told to stop recording the same call twice. TLS interception, the third shape specified alongside these two, is deferred indefinitely and is not offered. The customer-facing install guide ships with the operator kit rather than separately from it, so the guide and the two artifacts it describes travel together and cannot drift apart between releases.

Continue

DiscoveryWhat is running on the estate IntegrationsEvery enforcement point in one table Data leakageWhat egress control is for