Databricks Innocent Until Combined Policy Blocks Agent Risk at the Combination Point

Databricks has published a new Omnigent security pattern that blocks an agent only after three individually ordinary capabilities form a dangerous chain. The Databricks innocent until combined approach targets the moment private data, untrusted content, and external communication become available within one session.

That combination is known as the lethal trifecta. An agent might safely read an internal file, inspect a public webpage, or send a message when each action occurs alone. Put all three capabilities into one execution path, and an injected instruction can turn legitimate access into data theft.

The important shift is not another warning about prompt injection. Databricks is moving the enforcement decision outside the model and into Omnigent, its open-source meta-harness for running and governing agents. The policy layer remembers what a session has encountered, then changes how it treats later actions.

Static permissions ask whether an agent may call a tool. Contextual policies also ask what happened before that call. This difference pressures teams using broad, persistent tool access through coding agents, browser agents, and Model Context Protocol integrations.

What Databricks changed in Omnigent

Databricks is treating an agent’s history as part of its effective permission set.

The company’s security case study extends a series of posts about contextual policies in Omnigent. Earlier examples focused on session state, slow-burn attacks, and authorization tied to the user’s original intent.

The latest example applies that model to the lethal trifecta. Security researcher Simon Willison defined the pattern in June 2025 as access to private data, exposure to untrusted content, and an external communication channel. His threat model warns that combining all three gives injected instructions a route to steal information.

Omnigent sits above an agent harness, which is the runtime that manages the model, tools, and execution loop. The project supports established coding-agent environments and custom agents, allowing a common policy layer to observe their activity.

That position matters because the policy does not need the underlying model to recognize every malicious phrase. It can govern tool use based on facts recorded during the session.

Consider an agent asked to review an internal product document. Reading that document is expected. Sending an approved summary to a company channel might also be expected.

Now suppose the agent visits a public issue, webpage, or repository containing hidden instructions. A later outbound request has a different security meaning because the session has crossed another trust boundary.

A conventional allowlist sees the same approved tools throughout the workflow. A contextual policy sees a sequence whose risk changed over time.

Omnigent policies can return an allow, ask, or deny decision. Allow permits the action, ask routes it to a person, and deny blocks it. The response can therefore become stricter as the session accumulates sensitive access or risky events.

This enforcement model does not require every source, tool, or action to be dangerous by itself. Instead, the policy watches for combinations that create an unsafe data path.

Databricks is also offering Omnigent as a managed beta connected to workspace identity and model services. Its managed deployment currently supports built-in contextual policy handlers, while arbitrary custom policy functions remain unavailable there.

That limitation separates the open-source design from the managed product. Teams evaluating the announcement must distinguish a demonstrated policy pattern from the controls available in their chosen deployment.

Still, the central change is clear. Agent authorization is becoming session-dependent rather than fixed at login or tool registration.

Why Databricks innocent until combined changes the security boundary

The risky object is no longer one tool call; it is the path connecting several allowed calls.

Traditional access control evaluates identities, resources, and actions. A service account can read one database, write to one bucket, or call one API. Those rules remain necessary because agents still operate through ordinary credentials.

They are not sufficient when untrusted language influences how those credentials are used. An attacker may never need to steal a token or exploit application code. The attacker only needs malicious content to reach a model that can access data and act externally.

The first element is private data. This category includes internal documents, source code, credentials, customer records, email, database results, and any information outside the attacker’s authorization.

The second element is untrusted content. A webpage, support ticket, pull request, email, shared file, tool response, or image can carry instructions controlled by someone outside the agent’s trust boundary.

The third element is external communication. Email and HTTP requests are obvious examples, but the category is broader. Posting a comment, pushing code, loading a remote resource, or writing into a shared system can create an outbound channel.

None of those capabilities is unusual. Their usefulness is precisely why the combination appears in so many agent designs.

A research agent needs external sources and internal context. A coding agent may read a private repository, consult public documentation, and push a branch. An email assistant reads untrusted messages, searches private correspondence, and sends replies.

Removing any capability permanently can make the agent substantially less useful. Constant approval prompts create a different problem because users can become accustomed to accepting routine requests.

The Databricks innocent until combined framing offers another option. Let low-risk operations proceed, but escalate when the session state completes a prohibited combination.

That moves the security boundary from the individual connector to the workflow. A browser is not simply trusted or untrusted. Its relevance depends on whether the same session also holds sensitive information and an outbound route.

This model resembles information-flow control, where a system tracks how data moves between trust levels. Once confidential information enters a context, later writes to a less protected destination receive stricter treatment.

Omnigent’s published policy catalog already includes a related Google Drive control. Once a session reads a declared confidential file, the policy can prevent writes outside the confidential set.

The catalog also includes a risk-score policy. It accumulates points from tool calls and sensitive-data labels, then escalates guarded tools after a configured threshold.

Those examples show why state is central. A write request does not change its API shape after the agent reads a sensitive document. Its meaning changes because of the session’s history.

The same principle applies to the lethal trifecta. The policy is looking for a dangerous composition, not a universally forbidden operation.

That distinction should interest platform teams more than another prompt filter. Filters attempt to decide whether text looks malicious. Contextual enforcement can still block an unsafe action when the model or filter fails to identify the injection.

Static permissions lose the sequence

A static allowlist can describe available capabilities, but it cannot explain how the agent arrived at an action.

Suppose a developer authorizes an agent to read a private repository, browse documentation, and open pull requests. Each permission supports a normal coding workflow.

An attacker then places an instruction inside an issue, dependency document, or retrieved webpage. The instruction tells the agent to collect a secret and include it in a public pull-request description.

The repository read is allowed. The web retrieval is allowed. Opening a pull request is allowed. A control that evaluates each request independently can approve the entire chain.

A content filter might detect the instruction. It might also miss an indirect request, encoded data, an unfamiliar language, or a payload designed around the target model.

Research supports caution about relying on model behavior alone. The WASP benchmark tested realistic prompt-injection attacks against web-agent systems using several models and scaffolds.

Its researchers found that agents began executing adversarial instructions between 16 percent and 86 percent of the time across tested configurations. End-to-end attacker success was lower, ranging from zero to 17 percent.

That gap is encouraging but not reassuring. Current agents often fail before completing a complicated attack, yet improving agent reliability can also make malicious workflows easier to finish.

A system should not count on an agent becoming confused at the right moment. It needs a control that remains effective as models get better at multi-step execution.

Static permissions also struggle with delayed attacks. The injected instruction may not trigger an immediate outbound action. It can influence a later plan, delegated task, generated file, or tool call.

A session-aware policy can retain security-relevant facts across that delay. It does not need every suspicious event to sit beside the final action in the model’s active context.

That persistence addresses a practical weakness in long-running agents. Conversation history can be compressed, summarized, or split across workers. A model might forget an earlier constraint even while its tools and credentials remain available.

Policy state should therefore live outside the text window. The enforcement layer needs its own durable account of sensitive reads, untrusted inputs, destinations, approvals, and risk changes.

This architecture also reduces dependence on the agent’s self-reporting. Asking the model whether it encountered untrusted content is weaker than recording which connector supplied the content.

The strongest signals come from infrastructure. A document system knows a file’s classification. A network gateway knows the destination. An identity layer knows the user and workspace. A tool broker knows which operation was requested.

Omnigent can combine those signals because it wraps the execution environment. The agent proposes an action, but the policy decides whether that action remains acceptable under the recorded context.

This is the pressure point for competing agent platforms. Tool-level approvals are easier to explain and implement. They become less credible when agents run longer sessions across more connectors.

Vendors will need to show whether their controls follow data and trust transitions across tools. A long list of permissions no longer answers the central security question.

Contextual policies break the chain before data leaves

The useful control point is the transition that completes the attack path, usually a sensitive read or an outbound action.

A contextual policy begins with observable events. These can include a tool invocation, a tool result, a data label, a destination, a model request, or a user approval.

The policy stores selected facts in session state. It might record that the agent consumed untrusted content, accessed a confidential object, or attempted communication outside an approved boundary.

Later events are evaluated against that state. If the next operation completes a prohibited combination, the policy can require approval or deny the request.

The order can vary. An agent might read private data before visiting an untrusted page. It might encounter the injected content first, then request access to an internal file.

A sound implementation must detect both paths. The danger comes from the capabilities becoming connected, not from one fixed ordering.

Enforcement can also occur at more than one point. A policy might block the sensitive read after untrusted content enters the session. Another design might allow analysis but prevent subsequent external communication.

Blocking egress often preserves more local utility. The agent can continue reading and drafting without gaining a route to expose information. However, egress controls must cover more than obvious send functions.

A generated link can encode data. A remote image request can transmit query parameters. A source-control push, issue comment, analytics call, or shared-document write can cross the trust boundary.

Destination context matters as well. Sending a summary to an approved internal channel differs from posting it to a public repository. Treating all writes equally would create unnecessary interruptions.

Human approval is valuable when the context and destination are clear. A useful prompt should explain that the session read confidential data, later consumed untrusted content, and now wants to contact a particular external endpoint.

A generic “allow this tool” message hides the reason for escalation. It encourages approval fatigue because the reviewer must reconstruct the workflow manually.

Hard denial fits combinations that an organization never accepts. For example, a policy can prevent any session exposed to public content from sending information from a restricted data set outside its compartment.

The policy engine must fail safely when required context is missing. A missing data label, unsupported tool, or unobserved network path can create a blind spot.

Omnigent’s broader approach combines policies with sandboxing. A sandbox restricts filesystem and network access at the operating-system boundary, reducing what an agent can reach even if the model requests it.

These layers serve different purposes. The sandbox limits raw capability. Contextual policy adjusts permission based on the session’s accumulated state.

Neither replaces ordinary identity controls, connector authorization, logging, or data-loss prevention. The announcement is most useful when interpreted as one enforcement layer within that stack.

The agentic security report from OWASP identifies prompt injection as a leading attack technique against AI systems. Its larger message is that agent security requires controls around execution, tools, identity, and data movement.

That supports Databricks’ architectural direction. A probabilistic model can suggest an action, but a deterministic boundary should decide whether the action is permitted.

What the Databricks policy does not settle

Contextual enforcement narrows the attack path, but its reliability depends on complete visibility and trustworthy classification.

The first unresolved issue is coverage. A policy cannot block a channel it does not observe.

An agent may communicate through a connector, shell command, browser request, embedded resource, or generated artifact. Every path that can move data outside the boundary must be represented in the policy model or constrained elsewhere.

The second issue is classification. The system needs to know which content is untrusted and which data is sensitive.

Simple rules can classify public webpages as untrusted and named documents as confidential. Enterprise environments contain harder cases, including shared drives, contractor accounts, copied text, generated files, and data assembled from several low-sensitivity sources.

False negatives leave the dangerous combination undetected. False positives interrupt ordinary work and can train users to approve warnings without reviewing them.

The third issue is state scope. A session is a convenient unit, but information can move between sessions through files, memory stores, caches, subagents, and copied summaries.

If a worker reads confidential data and another worker sends the result, per-session tracking may miss the combined flow. Multi-agent systems need propagation rules that preserve relevant labels across delegation.

The fourth issue is policy integrity. The enforcement layer, configuration, and event stream become security-critical infrastructure. Attackers may target policy gaps, malformed tool metadata, ambiguous destinations, or fail-open behavior.

Teams should test the actual policy boundary, not only the model. Adversarial evaluations must include alternative egress routes, delayed actions, cross-agent transfers, and incomplete metadata.

The fifth issue is usability. A control that asks for approval too often can reproduce the weakness it was meant to solve.

Risk-based escalation needs carefully chosen thresholds and informative prompts. Security teams should measure approval frequency, denial accuracy, override rates, and the reasons users accept exceptions.

The managed Omnigent beta introduces another practical constraint. Databricks currently documents support for built-in handlers, not arbitrary custom policy code, in the managed environment.

Organizations with specialized classifications or proprietary connectors should verify whether the available policies expose enough context. Open-source flexibility does not automatically translate into managed-service parity.

There is also no basis yet for treating one demonstration as universal validation. The Databricks article explains a security pattern and an implementation approach. It does not establish that every Omnigent configuration blocks every prompt-injection technique.

The correct claim is narrower. Session-aware enforcement can break a lethal-trifecta path even when each individual tool remains legitimate.

That is still meaningful. Security architecture often succeeds by removing one necessary condition from an attack, not by teaching the application to recognize every attacker message.

The strongest deployments will combine contextual policy with restricted credentials, destination allowlists, sandboxing, audit logs, and independent testing. They will also treat policy definitions as versioned security code.

Three signals will show whether the model holds

The next test is whether contextual policy becomes measurable infrastructure rather than a persuasive demonstration.

The first signal is broader coverage across tools and agent harnesses. Databricks must show that security labels and session state survive common workflows involving browsers, code repositories, document systems, shells, and delegated agents.

Support on a feature list is not enough. Teams need evidence that equivalent actions receive equivalent enforcement across different harnesses and connector implementations.

Consistent coverage would strengthen the case for a shared meta-harness. Material differences between runtimes would weaken the promise of one governance layer across agents.

The second signal is adversarial evaluation. Omnigent needs repeatable tests that attempt delayed exfiltration, indirect egress, cross-session transfer, and metadata manipulation.

Useful results should separate detection, approval, denial, and successful data movement. They should also report benign-task completion because a policy that blocks every workflow is secure but unusable.

Public test fixtures would let security teams reproduce results against their own configuration. Independent evaluation would carry more weight than a vendor-selected scenario.

The third signal is operational adoption inside managed Databricks environments. Watch for expanded policy support, clearer telemetry, administration controls, and documented integrations with enterprise data classifications.

Adoption should produce measurable outcomes. Teams need to know how often policies trigger, which capability combinations cause escalation, and whether reviewers reverse or approve the decision.

These signals matter because the underlying security problem will grow with agent utility. Better agents will complete longer tasks, use more tools, and cross more trust boundaries without constant supervision.

The Databricks innocent until combined approach offers a credible design principle: permit useful components while blocking the dangerous composition. It shifts attention from whether a model understands an attack to whether the surrounding system permits the attack to finish.

Developers should map which sessions can access private data, ingest attacker-controlled content, and communicate externally. Enterprise buyers should ask whether a platform tracks those conditions across time, tools, and delegated workers.

If all three remain available without contextual enforcement, a polished approval screen does not solve the problem. The practical next step is to identify where the third capability enters each workflow, then place a testable policy at that boundary.