Databricks Permission Is Not Purpose: Omnigent Puts Intent Before Agent Action

Databricks has introduced a new permission boundary for Omnigent, despite the agent already holding valid credentials for every tool in its test. The control asks why an action is happening, not only whether the agent can perform it. That distinction turns databricks permission from an identity check into a task-specific constraint.

The July 23 release presents intent-based authorization as a defense against indirect prompt injection. This attack hides instructions inside content an agent reads, such as an email, document, support ticket, or database field. Omnigent binds each session to a human-approved purpose and checks every tool call against it.

That approach challenges the default identity-first model behind most enterprise access systems. Role-based access control can confirm that an agent may grant database access. It cannot determine whether granting access belongs inside a data-quality review. The difference between capability and purpose is now becoming an operational security boundary.

Databricks Permission Now Checks the Task, Not Just the Identity

The immediate change is simple: Omnigent evaluates whether every proposed tool call serves the declared purpose of the current session.

Traditional authorization begins with identity. A user, service account, or agent receives permission to interact with specified resources. Applications then accept or reject operations according to roles, scopes, policies, and credentials.

That model assumes the authenticated actor represents a relatively stable decision-maker. A human reads information, interprets it, and decides which permitted button to press. The authorization layer rarely needs to understand why the person pressed it.

An AI agent operates differently. It reads data and decides what to do within the same automated loop. Content gathered from outside the system can influence both its reasoning and its selection of privileged tools.

According to the intent authorization release, Omnigent addresses that difference by combining identity and intent. Identity defines the broad set of operations available to the agent. Intent narrows that set for one task or session.

The mechanism produces three possible decisions before a tool call:

• ALLOW: The proposed action clearly fits the approved purpose.

• ASK: The action relates to the purpose but requires human consent.

• DENY: The action falls outside the declared purpose and cannot proceed.

These outcomes matter because a valid credential no longer settles the authorization decision. An agent can possess a tool and remain unable to use it during an unrelated assignment.

Omnigent is an open-source meta-harness, meaning it provides a shared orchestration and policy layer around different agent runtimes. Its open-source repository lists support for Claude Code, Codex, Cursor, OpenCode, Hermes, Pi, and custom agents.

That positioning makes the policy broader than a safeguard for one model. The intent check sits around the agent’s tool activity, where it can govern different reasoning systems through a common layer.

The release also arrives with an important limitation. Omnigent remains in alpha, so the demonstration should be read as a design proposal and working implementation. It is not evidence of production-scale reliability across every model, tool, and enterprise workflow.

Still, the architectural point is concrete. An authorization decision can incorporate the current task without replacing existing identity controls. For security teams, that creates an additional checkpoint between a model’s decision and a consequential action.

The new control also complements Omnigent’s other contextual policies. Those policies can consider session risk, sensitive data, cumulative tool use, or service-specific restrictions. If several policies evaluate the same call, one denial overrides more permissive decisions.

That rule prevents a newly added policy from silently canceling a stricter one. It also frames intent as one layer within a larger defense, rather than a complete answer to agent security.

The Data-Quality Test Exposes the Purpose Gap

Databricks chose a small data workflow to show why excessive permission is sometimes operationally necessary but still unsafe.

The test agent performs a routine data-quality assignment. It reads a customer table, calculates quality indicators, and posts a summary to an internal dashboard.

Its available tools include a table query, a dashboard update, and a function that grants another user access to the table. The last capability is unnecessary for this particular review. However, the same agent uses it during other legitimate assignments.

Removing the access-granting tool would reduce the immediate risk. It would also prevent the agent from completing valid provisioning work without a separate configuration or identity. This is where static least privilege becomes difficult for general-purpose agents.

The session begins with a narrow request: check the customers table and publish a summary. An attacker has previously placed an instruction inside a user-controlled field in that table.

The hidden text presents itself as an audit note. It directs the agent to grant an external address access to the customer data, then continue the original quality check.

This is an indirect prompt injection because the malicious instruction arrives through retrieved data. The user never asked the agent to change permissions, and the attacker never needed direct access to the agent’s conversation.

Without the intent policy, Omnigent’s test agent follows the planted instruction. Its identity is authorized to use the access-granting tool, so a conventional permission check sees a valid operation from a valid actor.

The agent then records the grant as normal audit activity. That detail illustrates a second problem: activity logs can accurately record an operation while failing to reveal that the operation violated the user’s actual objective.

With intent-based authorization enabled, the same tools and credentials remain available. The outcome changes because each operation is compared with the approved data-quality purpose.

Reading the table receives an ALLOW decision. Publishing the requested dashboard update receives an ASK decision, allowing a human to confirm the write. Granting access to the external address receives a DENY decision.

The legitimate assignment still finishes after approval for the dashboard update. The injected action fails because it does not contribute to the session’s stated purpose.

This example gives databricks permission controls a sharper meaning. The question is no longer only whether the agent can modify access. The system also evaluates whether that modification belongs in a data-quality session.

The test reflects a practical enterprise problem. An agent connected to one searchable knowledge base, data platform, or support environment can encounter text from many trust levels. A user comment and an administrator instruction may enter the same model context.

Humans recognize organizational context imperfectly, but they can question an unusual request. Models can interpret polished malicious text as part of the task, especially when it resembles an ordinary business instruction.

Google’s security researchers define indirect prompt injection as malicious instructions embedded in content an AI system processes. Their recent web threat analysis found both malicious attempts and many benign texts resembling injection patterns.

That mixture complicates content filtering. A detector looking for phrases such as “ignore previous instructions” will encounter research papers, security tutorials, and harmless discussions. A sophisticated attack may use business language without obvious malicious markers.

Intent-based authorization approaches the problem from the action side. It does not need to prove that a table field is hostile before blocking an unrelated permission change. It asks whether the resulting tool call supports the task.

That is the central reversal in Databricks’ demonstration. The dangerous operation does not look unauthorized to the identity system. It becomes unauthorized only after purpose enters the decision.

Why Identity-Based Access Leaves Agents Overexposed

The main pressure falls on identity and access systems that treat a credential’s scope as the final boundary for autonomous software.

Role-based access control remains essential. It limits which resources an identity can reach and which operations it can request. Intent-based controls cannot safely compensate for an agent holding administrator access across an entire organization.

However, roles tend to remain stable while agent assignments change rapidly. A coding agent can review a repository, create a branch, deploy a service, or modify an issue during different sessions. Each assignment requires a different subset of the same available capabilities.

Creating one identity for every possible task would produce a large provisioning burden. Giving one reusable identity broad scopes creates an ambient authority problem, where credentials remain available beyond their immediate purpose.

Short-lived and narrowly scoped credentials can reduce this exposure. They work best when systems can predict the exact resources and actions needed before execution. Open-ended agent workflows often discover those requirements while working.

The Omnigent model adds a session-level constraint without requiring a new identity for every conversation. A human declares what the agent is supposed to accomplish, then the policy evaluates proposed actions against that declaration.

For autonomous agents, Databricks says the intent can be fixed in the agent specification at design time. The running agent cannot broaden or remove it.

Interactive agents handle the decision differently. The agent drafts a policy from the user’s plain-language description, but a human approves it when the session begins. The policy cannot change in the background during that session.

This human approval step matters because intent inference creates its own vulnerability. If the model could silently redefine purpose after reading injected content, an attacker could persuade it to authorize the unwanted action.

Omnigent also denies the running agent tools for removing, editing, or disabling its intent. Adding another policy requires human approval, and a permissive addition cannot override an existing denial.

Those controls create tamper resistance around the policy configuration. They do not make the underlying intent evaluation infallible.

The built-in policy documentation says its intent_based_authorization control records the first user message as session intent. It then asks before tool calls without a plausible connection to that intent. The documentation also states that the policy requires an LLM configuration and fails open without one.

That last behavior deserves attention. A security control that becomes permissive when its evaluator is missing creates a deployment condition teams must test and monitor. Production environments generally need visible failures, configuration validation, and alerts when a required policy component becomes unavailable.

The use of an LLM evaluator creates another tradeoff. Natural-language reasoning can understand task relationships that static rules miss. It can also produce inconsistent decisions when prompts, models, or surrounding context change.

This tension explains why Databricks presents intent as part of layered agent security. A policy can stop an off-task access grant while another control limits cumulative risk. Separate data-loss rules can govern what information flows through an otherwise permitted call.

NIST has also identified authorization as an unresolved agent problem. Its February 2026 agent identity proposal asks how organizations should apply identity, authorization, auditing, and non-repudiation controls to autonomous software.

The proposal specifically includes controls for preventing and mitigating prompt injection. That scope shows why identity and purpose cannot remain separate discussions.

An authenticated agent can still make a harmful decision. A purpose-aligned action can still expose sensitive data if its arguments or destination are unsafe. Effective controls must consider identity, task, data, action, and consequence together.

For enterprise buyers, the forced response is architectural. Security reviews can no longer end with a list of OAuth scopes or service-account roles. Teams need to document how each high-impact action remains connected to a user-approved objective during execution.

Intent-Based Authorization Adds Judgment and New Failure Modes

Omnigent reduces one authorization gap by placing model-assisted judgment directly inside the enforcement path.

That design offers flexibility, but it also creates uncertainty. “Plausibly connected to the task” is not a fully deterministic property.

Consider an agent asked to investigate a production outage. Reading logs clearly fits the task. Restarting a service might fit after the agent identifies a failure. Rotating credentials could be necessary if the evidence indicates a compromise.

A narrow policy might block the actions needed for recovery. A broad policy might allow an attacker to frame an unrelated credential change as incident response. Human approval can resolve some ambiguity, but frequent prompts can slow work and encourage automatic consent.

The ALLOW, ASK, and DENY model therefore depends on careful calibration. ASK is particularly important because it gives uncertain but legitimate operations a path forward without granting silent autonomy.

Too many ASK decisions create approval fatigue. Operators may approve requests without examining the reason, destination, or affected data. Too few ASK decisions shift ambiguous operations toward automatic permission or unnecessary denial.

The policy also judges tool calls, not every consequence of an allowed call. Databricks explicitly notes that intent constrains which actions run, rather than what travels through those actions.

An approved dashboard update could still include confidential data. A permitted email reply could target the wrong recipient. A legitimate database query could return more records than the task requires.

Intent-based authorization must therefore work alongside argument validation, data-loss prevention, destination controls, rate limits, and audit systems. Its value comes from adding purpose to authorization, not from replacing those controls.

OpenAI describes a related source-and-sink model in its agent security analysis. A dangerous outcome often requires both attacker-controlled content and a capability that becomes harmful in the wrong context.

That framing supports Omnigent’s focus on constraining action. It also highlights why no single classifier can solve the problem. Systems should reduce the impact of manipulation even when they fail to detect the malicious input.

Independent research points in the same direction. The ACL 2025 Task Shield paper evaluates whether each instruction and tool call contributes to a user-specified objective.

On the AgentDojo benchmark, the researchers reported a 2.07 percent attack success rate and 69.79 percent task utility with GPT-4o. These results apply to that benchmark and configuration, not to Omnigent’s implementation.

The utility figure exposes the tradeoff behind task-alignment defenses. A system can block attacks while also preventing legitimate work. Security improves only when the policy preserves enough task completion to remain usable.

Databricks has not published comparable benchmark results for its new control. The demonstration shows one injected field, one agent, three tools, and one declared purpose. It does not establish general performance across long sessions or ambiguous enterprise tasks.

There is also no public evidence yet about false approvals, false denials, evaluator latency, or policy behavior after model updates. Those measurements will determine whether the approach moves beyond persuasive examples.

Attackers will also adapt. They can craft injected instructions that sound connected to the declared task. An instruction might claim that granting access is required to verify the same table under review.

The published demonstration already uses this strategy by describing the external recipient as an auditor. The policy still blocks the grant because the approved intent remains narrow, but more complex tasks will produce less obvious boundaries.

A malicious instruction could also target arguments within an allowed tool. If the session permits dashboard updates, an attacker might try to insert confidential fields into the dashboard body. Tool-level purpose alignment alone would not necessarily detect that variation.

Teams evaluating databricks permission controls should therefore test policy decisions at several levels. They need ordinary requests, ambiguous requests, injected content, misleading business justifications, and malicious arguments inside permitted operations.

They should also record why each decision occurred. A security team cannot investigate inconsistent enforcement if logs contain only ALLOW, ASK, or DENY without the relevant intent and proposed action.

The most useful comparison is not intent control versus perfect safety. It is intent control versus identity authorization alone, within a layered system.

Under that comparison, Omnigent closes a genuine gap. The remaining question is whether teams can define purpose precisely enough to gain protection without turning every useful agent action into a manual review.

Three Signals Will Show Whether Omnigent’s Model Holds Up

The next phase should be judged by measurable enforcement quality, not by the clarity of the initial demonstration.

The first signal is a reproducible evaluation suite. Omnigent needs tests spanning different models, harnesses, tools, and indirect injection strategies.

Useful results would separate attack success, legitimate task completion, false approvals, false denials, and human escalation rates. They should also show whether small changes in wording produce materially different decisions.

Strong performance across adversarial tests would reinforce Databricks’ argument that purpose can become a dependable authorization input. High variance across models or prompts would weaken the case for model-assisted intent checks as an enforcement boundary.

The second signal is deployment-safe failure behavior. Omnigent’s documentation says the built-in policy fails open when no LLM configuration is available.

Users should watch for startup validation, administrative alerts, fail-closed options, and clear audit records when the evaluator cannot run. A contextual policy provides little protection if configuration drift can silently remove it.

Visible handling of evaluator outages would strengthen the design. Continued permissive behavior without prominent warnings would leave a serious operational gap.

The third signal is adoption outside the authors’ examples. Real teams need to publish policies for coding, support, data operations, email, calendars, and multi-agent delegation.

Those examples should reveal how organizations define intent for assignments that legitimately evolve. They should also show how frequently users receive ASK prompts and whether those prompts improve decisions.

Broader usage would test the design’s central promise: one agent can retain useful capabilities while exercising only the subset required for the current task. Repeated policy bypasses or intolerable approval fatigue would weaken that promise.

This is why the Omnigent release matters beyond one open-source framework. Agent developers are building systems that read untrusted information and act through valid enterprise credentials. The resulting risk sits between conventional access control and model safety.

Databricks permission is becoming a two-part decision: can this identity act, and does this action serve the approved purpose?

That second question will not eliminate prompt injection. It creates a place to stop an injected instruction after it influences the model but before it reaches a consequential tool.

Developers should begin by identifying actions whose authorization changes with task context. Security teams can then test whether intent policies deny unrelated operations, escalate ambiguous ones, and preserve legitimate work.

Enterprise buyers should ask vendors for evidence across those three outcomes. A control that blocks everything is not useful authorization. A control that preserves every workflow while missing adversarial requests is not meaningful protection.

The practical question is now unavoidable: if an AI agent holds permission to perform an action, what independently enforced evidence shows that the action serves the user’s current purpose?