MAPL Policy Language
MAPL (MACAW Agentic Policy Language) defines what AI agents can do. Policies inherit hierarchically from organization to user level, using intersection semantics where the most restrictive constraint wins.
Why MAPL?
Existing policy languages (OPA Rego, XACML) weren't designed for agentic AI. They lack support for attestations, hierarchical inheritance, and AI-specific primitives like model selection and token limits.
Hierarchical
Policies inherit and compose. Set organization-wide rules, refine at team and user levels.
Intersection Semantics
When policies combine, the most restrictive constraint wins. No privilege escalation possible.
Attestation-Aware
Condition policies on third-party verifications (DLP scans, compliance systems, approvals).
Policy Structure
A MAPL policy defines what resources an identity can access, what operations are allowed, and constraints on parameters like models and token limits.
- •
policy_idbinds the policy to an identity - •
extendsinherits from a parent policy - •
resourcesare allowed access patterns - •
constraintslimit parameter values
{
"policy_id": "user:alice",
"extends": "team:engineering",
"scope": "user",
"resources": [
"llm:openai/chat.completions",
"tool:calculator/*"
],
"constraints": {
"llm:openai/chat.completions": {
"model": ["gpt-3.5-turbo", "gpt-4"],
"max_tokens": { "max": 2000 }
}
}
}Hierarchical Inheritance
Company Policy (FinTech Corp)
│ max_tokens: 4000, models: [gpt-3.5, gpt-4]
│
▼
Business Unit (Analytics)
│ max_tokens: 2000 (stricter)
│
▼
Team Policy (Reporting)
│ models: [gpt-3.5] (stricter)
│
▼
Caller Policy (user:alice or app:service)
│ max_tokens: 1000 (strictest)
│
▼
Effective Policy: gpt-3.5, max 1000 tokensAt each level, constraints can only become stricter. A child policy cannot grant more permissions than its parent. This is enforced mathematically through intersection semantics.