Databricks has implemented a new session-based policy in its Omnigent framework designed to prevent data leaks by tracking private data, untrusted content, and outbound actions, avoiding the ‘lethal trifecta’ scenario in AI security.
Databricks has set out a new contextual policy for its Omnigent agent framework that is designed to stop one of the most awkward failure modes in AI security: when a single session combines access to private data, exposure to untrusted content and a route to send information outside the system. The company says the policy targets the so-called “lethal trifecta”, a term popularised by Simon Willison to describe the exact mix that can turn an otherwise ordinary agent into a data-leak channel.
The underlying problem is that conventional authorisation tends to judge each action in isolation. A model may be allowed to read an internal document, inspect a user-submitted ticket and send an email, because none of those steps is inherently suspicious. But, as Willison has argued, the risk emerges from the sequence itself: untrusted content can embed instructions that steer the agent towards reading confidential material and then pushing it out through an approved outbound channel.
Databricks’ answer is to keep state across the session. Its policy records whether the agent has touched private data, ingested untrusted content or attempted an exfiltration step. Once the first two conditions are present, the outbound action is blocked. The company says this means ordinary work can continue, but the final leg of the attack is cut off before data leaves the system.
The example Databricks uses is a support assistant with three tools: one to read internal documents, one to read customer tickets and one to send email. In the attack scenario, a ticket contains a planted instruction that tells the agent to retrieve sensitive revenue figures and copy them to an external mailbox under the guise of a routine renewal workflow. Without the contextual policy, the agent follows the chain and leaks the data. With the policy in place, the email step is denied once the session has already touched both private and untrusted material.
Databricks also argues that the safeguard is not meant to be overly broad. A session that only reads a ticket and replies to a customer is still allowed. A failed lookup that does not actually expose sensitive information should not trigger the private-data flag either. The company says the policy is deliberately aimed at the dangerous combination, not at normal agent activity.
A further design point is that the classifications are defined by a human in the agent configuration, not by the agent itself at runtime. Databricks says that matters because a prompt injection should not be able to persuade the system to reclassify a confidential source as harmless. The policy can also inspect tool arguments, which lets it distinguish, for example, between a fetch of an external URL and a safe internal request.
The release extends a broader line of defence in Omnigent, which Databricks has positioned around contextual policies that look at session history rather than single calls. Together with earlier controls for slow-burning attacks and declared intent, the company is trying to move AI security from one-step checking to sequence-aware enforcement. That approach reflects the broader warning from security researchers that agents become risky when private data, untrusted input and external communication are allowed to coexist in the same workflow.
Disclaimer: This content is intended for informational purposes only. Readers are advised to exercise their own judgement, conduct due diligence, or consult a qualified expert before acting on any information provided.
