Enterprise AI brings new complexity. Security architects ask critical questions: What agents may run? Under what limits? What must be logged? Binary allow/deny answers one question. But the world of AI execution needs answers to many more.
The Problem with Binary Authorization
Allow/deny decisions were designed for a human-centric world. A user either could access a resource or could not. Simple. But AI agents operate differently. They don't need blanket access—they need guardrails.
An AI agent might be allowed to approve requests, but only during business hours, only up to a spend cap, and never if the request involves PII. Binary yes/no forces these conditions into application code. They should be policy, enforceable at runtime.
Constraints: The How of Approval
Constraints live in context.constraints. They shape what an agent can do in the moment a decision is enforced. The PDP decides and specifies them. The PEP (Policy Enforcement Point) applies them in real time.
Scope
Restrict actions to specific resources, departments, or entity types
Time Window
Allow execution only within defined hours or date ranges
Rate Limit
Cap requests per minute, hour, or day
Spend Cap
Limit transaction or cost exposure per agent or user
Egress Control
Restrict where data or actions can flow
Redaction
Mask sensitive fields before agent access
Obligations: The What You Must Do After
Obligations live in context.obligations. They enforce accountability after an action completes. Unlike constraints (which prevent or shape action), obligations ensure proof and compliance trails.
An obligation might require that every sensitive approval be logged to a tamper-proof audit trail, or that a security team receive notification within 5 minutes, or that MFA step-up occur before credential access is granted to an agent.
How They Fit AuthZEN
Constraints and obligations are not a fork or alternative to AuthZEN. They are a natural extension within the standard's design. Any AuthZEN-compatible PDP can ignore them and remain compliant. New deployments that need them add support incrementally. This is backward compatible.
PEP Enforcement: Decide, Specify, Enforce, Evidence
The pattern is clear: PDP decides and specifies constraints and obligations. PEPs enforce and evidence them.
1. Synchronous Constraint Enforcement
PEP applies time, rate, and scope constraints before action executes
2. Concurrent Monitoring
Watch spend and egress in real time; block if limits approached
3. Post-Execution Obligations
After action completes, emit audit logs, trigger notifications, evidence consent
AI-Specific Examples
Spend Budgets
BudgetStatePIP tracks user, tenant, and agent spend caps. Agent requests blocked if cap reached.
Egress Allowlists
Restrict API calls or data export to whitelisted endpoints. Prevent data exfiltration.
PII Redaction
Redact SSN, credit card, email before agent sees payload. Masking applied at PEP.
Velocity Limits
Cap approvals per agent per minute. Detect and block anomalies in real time.
Phased Rollout: Feature Flags
Not all PEPs are ready for constraints and obligations at day one. That is why we support a feature flag: PDP_CONSTRAINTS_MODE.
disabled
PDP does not emit constraints or obligations. Existing clients see no change.
shadow
PDP emits constraints and obligations, but PEP logs them without enforcing. Validate before go-live.
full
PEP enforces constraints and obligations in production. Full runtime execution control.
This phased approach keeps existing PEPs stable while new ones adopt constraints and obligations incrementally.
Constraints and obligations are part of EmpowerNow's AuthZEN-compliant PDP. See the standards compliance →