Policy Enforcement

Policy enforcement turns rules about allowed behavior into runtime controls. In AI systems, policies can be checked before input, during retrieval, before tool execution, after generation, and during human oversight. A prompt instruction is not an enforcement boundary; high-risk decisions should be mediated by code, permissions, or a policy engine.

A layered enforcement path

A layered enforcement path for an email-sending agent:

flowchart TD
  Request[Request] --> Auth[Authentication]
  Auth --> Authorization[User and data authorization]
  Authorization --> Planning[Model and tool planning]
  Planning --> Policy{Policy decision}
  Policy -->|approved low risk| Send[Send action]
  Policy -->|high impact| Approval[Human approval]
  Approval --> Send
  Policy -->|deny| Block[Block]
  Send --> Audit[Audit log]
  Block --> Audit

The policy must be versioned and testable. For example, a Rego-style rule can deny customer-email actions that lack approval for sensitive content:

package ai.email
 
default allow := false
 
allow if {
  input.action == "send_customer_email"
  input.user_role in {"support_agent", "manager"}
  input.customer_id in input.authorized_customers
  not input.contains_sensitive_claim
}
 
allow if {
  input.action == "send_customer_email"
  input.user_role == "manager"
  input.customer_id in input.authorized_customers
  input.contains_sensitive_claim
  input.human_approval == true
}

OPA’s documentation describes Rego as a declarative policy language for structured inputs such as API requests and configuration data. The important AI design point is that the model proposes an action; enforcement code decides whether that action is allowed.

Sourced artifact

policy_test:
  id: email_sensitive_claim_requires_approval
  inputs:
    action: send_customer_email
    user_role: support_agent
    contains_sensitive_claim: true
    human_approval: false
  expected: deny
linked_risks:
  - prompt_injection
  - pii_leakage
  - excessive_agency

That test belongs in adversarial evaluation and release governance. If a tool path bypasses it, security owns the failure even if the model followed its prompt.

References