PATTERN Cited by 1 source

Intent-based authorization¶

Problem: An AI agent has multiple tools for multiple job types. Removing tools isn't an option — they're legitimately needed for some tasks. But during a specific session, only a subset is relevant. An indirect prompt injection in processed data can steer the agent toward using tools that are permitted but inappropriate for the current task (confused deputy).

Pattern: Bind each agent session to a declared intent and evaluate every tool call against it at runtime. The intent is a short policy that maps each available tool to a verdict:

ALLOW — the tool is within the declared purpose.
ASK — the tool is sensitive for this purpose; pause for human approval.
DENY — the tool is outside the declared purpose; block unconditionally.

Shape¶

# Agent spec: guardrails.policies
- name: quality-check-intent
  type: intent
  description: "Run data quality check and post summary"
  verdicts:
    query_table: ALLOW
    update_dashboard: ASK
    grant_table_access: DENY

The agent cannot modify, remove, or override this policy at runtime.

Key design properties¶

Intent is human-declared. Autonomous agents get intent pinned at design time; interactive agents have the human approve it at session start. The model never silently sets its own scope.
Complementary to identity. An action must satisfy both identity checks (RBAC/ABAC) AND intent checks. Intent can only narrow, never widen.
Composable with other policies via deny-wins semantics — intent is one of several contextual policies running in a single engine.

When to use¶

Agent handles multiple job types with overlapping but non-identical tool needs.
Static tool removal (patterns/minimally-scoped-llm-tools) is too coarse (same agent needs different tool subsets for different sessions).
Data the agent processes comes from untrusted sources (user-generated content, third-party feeds, shared tables).

Trade-offs¶

✓ Advantages	✗ Costs
Blocks confused-deputy attacks without removing capabilities	Requires per-use-case intent authoring
ASK verdict preserves human oversight without hard-blocking	Policy evaluation on every tool call adds latency
Composable with other policies	Intent must be maintained as tool surface evolves

Seen in¶

sources/2026-07-23-databricks-intent-based-authorization-omnigent — Omnigent's contextual policy engine demonstrates blocking a grant_table_access call injected via table data during a read-only quality-check session.

concepts/intent-based-authorization — the underlying principle
concepts/confused-deputy-problem — the attack class this pattern prevents
patterns/deny-wins-policy-composition — how intent policies compose
patterns/session-scoped-intent-binding — the binding mechanism
patterns/human-gated-tool-invocation — the ASK verdict sub-pattern
patterns/minimally-scoped-llm-tools — static alternative (remove tools entirely rather than gating per session)
systems/omnigent — reference implementation