Skip to content

DATABRICKS 2026-07-23

Read original ↗

Permission isn't purpose: Intent-based authorization in Omnigent

Summary

Databricks describes intent-based authorization, a security architecture for AI agents implemented in their Omnigent platform. The core insight: traditional identity-based authorization (RBAC) answers who may access a resource but never asks why — making agents vulnerable to indirect prompt injection attacks that steer them toward actions they're permitted to take but were never asked to perform (the confused deputy problem). Intent-based authorization binds each agent session to a declared purpose and evaluates every tool call against it, producing one of three verdicts: ALLOW, ASK (human approval), or DENY. This narrows the agent's effective permission set per-session without removing capabilities it legitimately needs for other tasks.

Key takeaways

  1. Identity ≠ purpose. RBAC tells you whether an agent can act; it cannot tell you whether the action fits the current task. An agent with grant_table_access permission needs it for provisioning jobs but not during a read-only quality check — yet RBAC allows both equally. (Source: "identity-based authorization is purpose-blind" section)

  2. Indirect prompt injection exploits the permission–purpose gap. An attacker plants instructions in data the agent reads (table rows, ticket fields, email bodies). Because the agent's identity allows the injected action, no access-control check fires. The two gaps — injection + purpose-blindness — compose into a clean attack. (Source: "The two gaps that the attack exploits" section)

  3. Three-verdict policy engine. Omnigent's contextual policy evaluates each tool call against the declared intent and returns ALLOW (within purpose), ASK (sensitive — needs human approval), or DENY (outside purpose). This is strictly narrower than identity; you must satisfy both identity AND intent. (Source: "What intent-based authorization adds" section)

  4. Intent is human-declared, not model-inferred. For autonomous agents the intent is pinned at design time in the agent spec (immutable at runtime). For interactive agents, the human describes the intent at session start, the agent drafts a policy, and the human approves it. The model cannot silently set or widen its own intent. (Source: "Where does the intent come from?" section)

  5. Deny-wins composition. When multiple contextual policies (intent, risk scoring, PII blocking, custom rules) run in the same engine, a single denial from any policy wins. This means adding a permissive policy cannot override an existing restriction — policies are monotonically restrictive. (Source: "A new policy cannot overrule the old one" — deny-wins semantics)

  6. Agent cannot self-modify intent. Three architectural properties make intent tamper-resistant: (a) there is no "remove/edit policy" tool exposed to the agent, (b) adding a policy requires human approval, (c) deny-wins means a new permissive policy can't lift existing blocks. (Source: "Can the agent change its own intent?" section)

  7. Layered defense with session-risk scoring. Intent-based authorization combines with the session-risk scoring policy (from a companion blog post) in a single policy engine. They reinforce each other — risk scoring detects behavioral anomalies while intent prevents out-of-scope actions even when behavior looks normal. (Source: introduction paragraph on layered defense)

Architecture

User request
    │
    ▼
┌─────────────────────────────────┐
│ Agent session (valid identity)  │
│ • Declared intent (immutable)   │
│ • Tool set: query_table,        │
│   update_dashboard,             │
│   grant_table_access            │
└────────────┬────────────────────┘
             │ tool call
             ▼
┌─────────────────────────────────┐
│ Contextual Policy Engine        │
│ ┌─────────┐ ┌──────────────┐   │
│ │ Intent  │ │ Risk scoring │   │
│ │ policy  │ │ PII blocking │   │
│ │         │ │ Custom rules │   │
│ └────┬────┘ └──────┬───────┘   │
│      │    deny wins │           │
│      ▼              ▼           │
│ ┌──────────────────────────┐    │
│ │ Verdict: ALLOW|ASK|DENY  │    │
│ └──────────────────────────┘    │
└─────────────────────────────────┘

Operational numbers

  • Demo uses three tools; grant_table_access is blocked during quality-check sessions even though identity allows it.
  • No quantitative throughput/latency numbers disclosed (alpha-stage system).

Caveats

  • Omnigent is described as "open source in alpha" — not yet battle-tested at scale.
  • The article demonstrates the pattern with a simple 3-tool setup; real-world agents with hundreds of tools would need tooling to maintain intent policies.
  • Intent policies are per-use-case, not generic — someone must author them.
  • The article does not discuss performance overhead of per-tool-call policy evaluation.

Source

Last updated · 593 distilled / 1,805 read