Databricks published an argument this month that agentic governance must track session state, because the danger in an agent session is not any single action but the sequence [1].
That argument extends a position the same team set out in July, when contextual policies were introduced as state-carrying rules that decide on history rather than on the call in front of them [9]. It is correct, and it is the write-path claim in first-party prose. What follows is not a rebuttal of the premise. It is a reading of what an enterprise installs when it accepts the premise and reaches for the shipped control.
The control that checks intent
Omnigent’s policy engine intercepts tool calls, model requests, and file operations and returns one of three verdicts: allow, ask, or deny [2]. Among the built-in policies is intent_based_authorization. As documented, it records the user’s first message as the authoritative intent for the session, then evaluates every subsequent tool call against that intent using a server-level model, denying calls that cannot plausibly serve the original task [3].
That is the description. The implementation is more specific, and the specifics are the architecture.
The policy lives in routing.py — the same module as deny_trivial_to_expensive_model, the cost policy that classifies a task as trivial or complex to keep cheap work off expensive models [4]. Authorization-by-intent and spend-routing share a file, a classifier pattern, a caching scheme, and a model client. The control that decides whether an action is legitimate and the control that decides whether an action is worth paying for are the same kind of object, built the same way, in the same place.
The captured intent is truncated to one thousand characters in session state. The judge sees the first five hundred, plus five hundred characters of serialized arguments [4]. An authorization baseline longer than a short paragraph is partially invisible to the control enforcing it.
Five ways to abstain
The policy returns no opinion — abstain, and evaluation proceeds to the next policy — under five distinct conditions [4].
The server has no model configuration block. The policy logs a warning and abstains. An operator who installed intent authorization without a server-level model has installed nothing, and the configuration surface does not say so.
The model returns a response carrying no extractable text. The policy abstains rather than treating an unanswered question as a reason to pause.
The model call raises, or the returned payload fails to parse. The exception is logged and the tool call proceeds. Transport failure and judgment failure are handled identically.
The response parses but the verdict is neither on-task nor off-task. The source annotates this path as fail-open in as many words.
No first message has been recorded as the session’s intent. Every tool call passes, also annotated as fail-open. The window before the baseline exists is ungoverned by the policy that depends on it.
Set that against the v0.3.0 release note recording that policy checks fail closed when turn context is missing [8]. The engine fails closed. The model-judged policies fail open. An operator reading “intent-based authorization” as a control has installed something that evaluates each call against the recorded intent when the classifier is reachable, coherent, and decisive, and contributes no decision otherwise — leaving the call to whatever remains in the policy chain. Availability of the judge is a precondition for the intent policy to contribute any authorization decision, and nothing in the configuration surfaces it as one.
The verdict is not what the docstrings say
Both the module docstring and the factory docstring state that tool calls unable to serve the original intent are denied before they run [4]. The implementation returns ask — pause for human approval. Only the registry description, the string rendered into the policy catalog, says so.
That gap matters beyond tidiness. Deny is an enforced terminal decision. Ask is an approval control that transfers judgment to a person, mid-session, on the strength of a one-line reason drawn from truncated intent. Both are controls; they have different owners and different assurance models. Which of the two an architect believes they configured depends on which line of the same file they read.
And the verdict persists. An on-task result is cached in session state under a hash of intent, tool name, and sorted arguments; identical subsequent calls abstain without re-evaluation [4]. One clearance ends re-evaluation by the intent policy for every identical call during the session. Other policies in the chain still run; this one stops looking.
Databricks documents the failure
The most consequential line in the file is the authors’ own. The docstring states that this is a best-effort control rather than a cryptographic guarantee, and that a sophisticated adversary can craft inputs that convince the classifier a call is on-task [4].
Read that against the containment argument. The published scenario has injected content steering an agent through a sequence, with the control firing on the last step [1]. The shipped intent control is the mechanism that would have determined whether the resulting call remained consistent with the original user instruction — and its authors state that the classifier can itself be persuaded by crafted inputs, the same underlying adversarial capability the containment scenario depends on. The classifier weakness underlying the arbitration gap is conceded in the code by the people who wrote it. Our earlier reading called that weakness an inference. It is now documentation.
Not shipped, and not runnable where it is sold
Which raises the question of what actually shipped.
At v0.8.1, the built-in policy package contains thirteen modules: shell, CEL, context, cost, GitHub, Google, orchestration, prompt, risk score, routing, safety, working directory, and the package initializer [6]. There is no policy implementing the three-leg session tracking the blog post describes. A code search for the post’s central term across the repository returns nothing. It is not a built-in, not an example, not in the security-agent example configuration.
Then there is the constraint that decides the matter. The Databricks managed documentation, last updated July 28, 2026, records a limitation the open-source documentation does not: Omnigent on Databricks supports only the built-in contextual policies as policy handlers, and custom policy functions that run arbitrary code are not supported [10]. The published containment policy is a custom policy function. On the managed product — the one sold to the enterprise, currently in beta, with model access routed through Foundation Model APIs and AI Gateway — it cannot run.
That is stronger evidence than repository absence, though it remains specific to the managed-product capability documented on July 28, 2026, and a product release can change it.
It would be wrong to say a managed customer can author nothing. One of the built-ins is cel_policy, which compiles a caller-supplied expression in Common Expression Language and evaluates it against every policy event [12]. Custom logic and a custom handler are different things: the handler set is closed, the logic is not.
What the authoring surface cannot create or update is state. CEL is non-Turing-complete and side-effect-free by design, and the response contract shows it — an expression returns a map carrying a verdict and an optional reason, and nothing else [12]. There is no channel for a state update. An authored expression can read session state that some other policy accumulated; it cannot write any. Accumulating three legs across a session is exactly the operation it has no way to perform, and on the managed product no arbitrary-code handler can be registered to perform it instead. An enterprise can author predicates over an event and over state accumulated by other policies. It cannot author the state accumulation the published containment pattern requires — which is the premise the whole argument rests on.
So the coverage questions an assurance case would ask — which tools light which leg, who maintains that classification against an expanding tool surface, what governs a read that returns nothing — have no artifact to be asked of. The containment argument circulates as prose. The arbitration control circulates as code, and abstains.
The distinction an assurance case turns on is between the architecture Databricks describes and the architecture its customer installs. A demonstration is not a control. A control is a thing with a version, a configuration surface, a failure mode, and a test.
What the engine actually does
Two first-party documents state different composition rules. The repository documentation says the engine evaluates in declaration order and a deny from any policy short-circuits the rest, with session-level policies evaluating ahead of agent-spec and administrator policies [5]. The documentation site says policies are checked in order and the first policy to return a decision wins, with only abstention passing to the next [2].
Those are not two phrasings of one rule. Under the second, an allow is a decision, so a session-level allow evaluated first would end the evaluation before an administrator’s policy was ever consulted. That is a materially different control hierarchy, and it is the kind of question a design review has to settle rather than infer. So I read the evaluator.
The engine composes as follows at v0.8.1 [11]. It iterates policies in declaration order. A deny returns immediately and short-circuits the chain. An allow does not short-circuit — evaluation continues. An ask accumulates a reason and also continues, so a deny arriving later in the chain overrides an ask raised earlier, and label writes and state updates from a pending ask are withheld until the approval lands.
The repository documentation is correct and the documentation site is not. An allow is not decisive, and a session-level allow does not preempt an administrator’s deny. The runtime protects the organizational guardrail. An earlier reading of ours implied otherwise on the strength of the documentation site, and that implication was wrong.
The defect is therefore in the documentation, not the composition — but it is the documentation a Databricks managed customer is pointed to, since the managed pages defer all policy reference to that site [10]. An architect reading the recommended source would design against a rule the engine does not implement.
What the evaluator does establish is sharper than the ambiguity it resolves. Every policy call is wrapped, and any exception a policy raises is converted into a fail-closed deny [11]. That is the engine’s stated contract: a broken policy blocks rather than passes. The intent policy catches its own exceptions and returns abstain [4]. It opts out of the guarantee the engine offers. The fail-open posture is not the engine’s; it is one policy overriding the engine’s, inside the module that also routes spend. The same pattern appears in the CEL built-in, where an evaluation error abstains, and the source comments name that outcome fail-open in as many words [12].
One concession worth making precisely. The engine does record a decision: a telemetry span carries the verdict, the reason, and the deciding policies for every evaluation [11]. That is a real record, and it is more than this thread has previously credited. It records which policy decided. It does not record whose instruction the session was following when it decided — which is the artifact an arbitration claim requires.
And the session level, the one that evaluates first, is agent-mediated. The agent holds a policy-adding tool and composes session policies on request, subject to user approval [5]. Approval is a real boundary, and I am not claiming a bypass. I am observing where it sits: a human approving a policy the agent proposed, in the channel the untrusted content travels in.
The governance property Databricks demonstrates is containment, and the demonstration is not shipped as a built-in and cannot run on the managed product. What Databricks ships in its place is not arbitration but an intent-consistency check, and its authors document it as best-effort, persuadable by crafted input, not re-evaluated when an identical call repeats after one clearance, and abstaining on five conditions including the absence of the judge. The engine offers a fail-closed contract on policy failure. This policy declines it.
This is not one isolated defect, and several findings here are plainly patchable — a health check, a fail-closed branch, cache invalidation, a documentation correction. It is a design-class mismatch: an authorization surface has inherited the failure posture of an optimizer, where abstaining is cheap and correct, rather than the posture of a control, where abstaining is the whole exposure.
