Skip to main content

What are contextual policies for AI agents?

Summary

  • Contextual policies are runtime governance rules that evaluate AI agent requests and responses based on business context, not just static permissions.
  • They operate with four possible verdicts: ALLOW (proceed), DENY (block), ASK (request human approval), and TRANSFORM (modify the action).
  • Contextual policies track cumulative session state, remembering what an agent has done and adjusting governance decisions accordingly, going beyond traditional allow-lists.
  • They are defined in Unity Catalog and enforced by Unity Gateway, evaluating requests before they're sent and responses after they're returned.
  • Built-in policies cover PII blocking and redaction, unsafe content detection, jailbreak/prompt injection detection, and hallucination detection; custom policies enable SQL, CEL expressions, or LLM-as-a-judge classifiers.

What are contextual policies for AI agents?
Contextual policies are runtime governance rules that adapt agent access decisions based on what the agent is actually doing and the data involved. They evaluate every agent action in real-time context and render verdicts that change based on business factors: the data being accessed, the action being performed, and the state of the session so far. This fine-grained approach is both more permissive (allowing useful actions) and more secure (blocking risky ones) than static allow-lists alone.

How Contextual Policies Differ from Static Permissions

Traditional role-based access control grants broad permissions upfront. A data analyst might have read access to all customer data, period. Contextual policies make governance decisions dynamically in real time, evaluating context. The same agent, performing the same action, receives different verdicts depending on the data and business context:

  • Publishing public information to the company website: ALLOW
  • Publishing the same information if it contains customer PII: DENY or ASK for human approval
  • Emailing internal data to a coworker: ALLOW
  • Updating the same data in a public customer system: DENY or ASK

Governance adapts to the business context rather than treating all actions identically.

Four Verdicts

Contextual policies operate with four possible outcomes, not three:

Verdict Behavior Use Case
ALLOW Proceed as requested Action is safe or compliant in context
DENY Block the action outright Action violates policy or exposes risk
ASK Pause and request human approval Action is risky but potentially legitimate
TRANSFORM Modify the action before proceeding Action is valid but can be made safer or more efficient

TRANSFORM is particularly useful for cost governance: a soft cost threshold triggers ASK for confirmation, but a hard cap triggers TRANSFORM to swap to a cheaper model rather than blocking the agent entirely.

Stateful Session Tracking

A key differentiator of contextual policies is that they track cumulative session state. Every tool call, model response, and previous decision is remembered. This enables sophisticated governance patterns:

  • Cost budgets: First requests stay within budget (ALLOW). As costs approach a soft threshold, future requests trigger ASK. When the hard cap is reached, subsequent requests TRANSFORM to use a cheaper model.
  • Intent-based scoping: An agent declares its goal at the start of a session (e.g., "debug this issue"). Policies can restrict the agent's tools to only what it declared it would use, growing permissions as it works.
  • Risk accumulation: Policies can block actions only when the agent has already taken multiple risky steps, making the agent more usable while preventing cumulative harm.

Session state tracking enables governance that is context-aware and proportional to actual risk.

Unity Gateway Implementation

Contextual policies are defined in Unity Catalog and enforced by Unity Gateway at runtime. They intercept every agent request before it's sent and every response after it's returned, evaluating policies against:

  • The agent or user making the request
  • The model or tool being invoked
  • The contents of the request and response
  • Data context (whether response contains PII, customer names, secrets, etc.)
  • Session state (what the agent has done so far in the current session)

Unity Gateway blocks or modifies requests and responses according to policy verdicts, ensuring no agent action bypasses governance.

Built-In and Custom Policies

Built-in policies handle common governance needs without requiring custom code:

  • PII blocking and redaction (detect and mask sensitive data)
  • Unsafe content detection (flag or block harmful outputs)
  • Jailbreak and prompt injection detection (block manipulation attempts)
  • Hallucination detection (flag model-generated false information)

Custom policies enable organization-specific governance:

  • SQL or CEL expressions that evaluate requests against business rules
  • LLM-as-a-judge classifiers that use a model to detect policy violations
  • Scope-based rules (e.g., deny contractor agents from pushing code to GitHub)

Practical Example: Publishing Agent

Consider an agent that publishes company information externally. Contextual policies ensure it adapts based on data sensitivity:

  • Public information (blog post, product overview): ALLOW publish to company website
  • Customer data with PII (contracts, account details): DENY publish externally or ASK for legal review
  • Internal updates (team meeting notes): ALLOW email to coworker
  • Sensitive business data (revenue, roadmap): DENY external publish; ASK if internal share needed

The same agent's behavior changes automatically based on the data involved and session state, not hardcoded rules.

FAQs

Can contextual policies be applied to non-agent tools?

Yes. Contextual policies work for any tool that connects to Unity Gateway. They're designed for agents but apply equally to AI applications, custom scripts, and user queries.

What happens if an agent request matches multiple policies?

All matching policies are evaluated. If any policy returns DENY, the request is blocked. If multiple policies return ALLOW, ASK, or TRANSFORM, the most restrictive verdict wins.

Can agents learn from DENY verdicts?

Contextual policies can log denied requests and make that information available to agents via APIs, enabling agents to adjust strategy. This requires application-level integration; policies themselves don't automatically retry.

How do TRANSFORM verdicts work for cost optimization?

A TRANSFORM verdict can replace a request to an expensive model with a cheaper one if the cheaper model is adequate for the task. This keeps agents functional while staying within budget.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.