MAPL: MACAW Agentic Policy Language · Open spec

Express and verify intent, formally.

A policy language and composition algebra for agentic actions. Every action is verified against policy before it runs, and provably scoped to what the policy allows.

Read the spec

163/164
τ²-bench tasks under written policy: 0/949
AgentDojo attacks that took effect: Lean
proofs of the language’s laws: 5 ms
per decision

You say

“Alice can read employee records¹, up to 100 at a time². Any update needs a manager’s approval³. Deletes aren’t allowed⁴.”

The MAPL skill writes

{
  "policy_id": "user:alice",
  "resources": [
    "tool:emp_records/read",1
    "tool:emp_records/update"
  ],
  "denied_resources": ["tool:emp_records/delete"],4
  "constraints": {
    "parameters": {
      "tool:emp_records/read": { "limit": { "max": 100 } }2
    },
    "tool:emp_records/update": {
      "attestations": ["manager_approval"]3
    },
    "attestations": {
      "manager_approval": { "approval_criteria": "role:manager" }3
    }
  }
}

Why MAPL.

Policy languages were built for a pre-agentic era: known callers making known requests. Agents act on behalf of people, delegate to other agents, chain calls across services owned by different teams, decide what to do at runtime, and occasionally lie.

Declarative and verifiable
Four parts, no code. Policies are validated before they deploy, and every decision is deterministic and reproducible.
Bound at call time
Policies name scopes, not people. Your IdP binds the caller when the call arrives, so a role change needs no policy change.
Many authors, one algebra
Caller, service and data owners each write their own policy. They combine by intersection: authority only narrows, and a denial is final.
Dynamic state
Decisions can depend on approvals, passkey logins and completed steps. A call can wait for an approver, and the agent can’t approve itself.

Learn more

MAPL spec 3.7.1 Authenticated Workflows paper Why MAPL solution brief

Every action is provably scoped to what its policies allow. The proofs are mechanized in Lean. The formal foundations, in the guide

A policy has four parts.

Every MAPL policy, at every level, has the same structure.

Resources

The allow list: tools, models and data, named scope:name, with wildcards.

"resources": [
  "tool:emp_records/read",
  "llm:openai/*"
]

Learn more

Denied resources

The deny list. A denial at any level is final.

"denied_resources": [
  "tool:emp_records/delete",
  "secrets:**"
]

Learn more

Parameter constraints

Limits on a call’s arguments, and patterns its arguments may not contain.

"tool:emp_records/read": {
  "limit": { "max": 100 }
}

Learn more

Approvals

Attestations a call needs: a manager’s approval, a passkey login, a completed step.

"attestations": [
  "manager_approval",
  "phishing_resistant"
]

Learn more

Minimal, and expressive. Allow and deny lists combine into any boolean rule over operations; constraints can test any decidable condition on arguments; approvals put steps in order. Your first policy

Common scenarios.

From the guide’s best practices.

Tiered approvalsThe amount decides who must approve.

"attestations": [
  "lead_ok::{params.amount > 1000}",
  "manager_ok::{params.amount > 10000}"
]

Injection defenseArguments that must never appear.

"denied_parameters": {
  "tool:shell/*": {
    "command": ["*sudo*", "*rm -*"]
  }
}

Data with its own policyA table binds whoever touches it.

"policy_id": "data:employee_comp",
"resources": ["tool:reporting/query"],
"denied_resources": ["tool:*/export"]

An app acting for a personThe person and the service must both allow.

maya → app:assistant
     → app:orchestrator
     → tool:banking/transfer

Emergency access, no overridesA time-bounded policy instead.

"policy_id": "team:incident-response",
"validity": {
  "not_after": "2025-01-17T17:00:00Z"
}

Only a person can approveApprovals that need a passkey login.

"attestations": [
  "manager_approval",
  "phishing_resistant"
]

The intersection algebra.

Every party in a call has a policy: the person, the agent acting for them, and the service it calls. MAPL intersects them into one effective policy.

Alicethe person

Claude Desktopthe agent, acting for her

Databasethe MCP server

Effective policyall five, intersected

model: claude-sonnet
tokens: ≤ 1,000
rows: ≤ 1,000

Click any policy to see it in MAPL. Each value in the effective policy is the tightest any party set.

model claude-opusrefused: Alice’s policy allows only Sonnet
max_tokens 4000refused: Claude Desktop allows at most 1,000
query(rows=4000)refused: the database allows at most 1,000
claude-sonnet, 1,000 tokens, 1,000 rowsallowed

Resources ∩Denied ∪Constraints tightest winsApprovals ∪The intersection rules

A child can only narrow.

company:macawthe rootmax_tokens ≤ 4,000
bu:financeextends company:macawmax_tokens ≤ 1,000
user:aliceextends bu:financemax_tokens ≤ 8,000

Alice’s policy asks for 8,000 tokens. Her effective limit is still 1,000. There are no overrides.

Inheritance in the guide

Human, agent and claims-based approvals.

Some decisions need more than the request: a person’s say-so, a step that already happened, a scope the caller holds right now. MAPL calls these attestations: facts a call can require, proved and signed by someone other than the agent.

One requirement, three kinds of proof

"tool:payments/send": { "attestations": [
    "payments_scope",from Alice’s token
    "kyc_checked",recorded by a tool
    "manager_approval::{params.amount > 25000}"a person, only over 25,000
] }

Human or agent approval

proved by a person or agent with authority

"approval_criteria": "role:manager"

The call waits. Only approvers who match the criteria can approve it; once approved it runs, and the approval is spent.

Short-lived scopes

proved by the requester’s token

"claim": { "scopes": "Banking.Write" }

Holds only while the token carries the scope. Nothing to approve or store: it ends when the token does.

System state

proved by a tool, after it runs

"internal": true

A tool records a fact: identity verified, data anonymized, a classifier’s verdict. Later calls can require it.

A person is present

proved by the login

"phishing_resistant"

Minted only from a passkey or hardware-key login. An agent holding a password can’t have it.

How an approval is routed

Alice’s agentpayments.send(amount = 30,000)
MAPL holds the callpending · for alice · approval_criteria: role:manager
Who can see it
BobIdP token roles: managersees it, approvesCarolIdP token roles: analystdoesn’t see itThe agentthe requestercan never approve
The call runsapproval signed by Bob · spent

A requirement can depend on the call, like the amount above, and a condition that can’t be evaluated requires the proof. Approvals can be single-use or expire; a denial or a timeout fails the call; and when two policies name approvers, the approver must satisfy both. Attestations in the guide

Programmable verification pipeline, with hooks.

Every call passes eight stages. Three are hooks for your own verification logic, in Python.

Extractoryour code

Your extractor reads a value in the call, such as a SQL string or a JSON body, and returns facts policy can test. It decides nothing on its own.

extract(value, **config) -> dictLibrary: secrets. Or write your own.

Hooks in practice.

Hooks make domain-specific verification easy to add.

llm:openai/chat.completions“Summarize this config: AWS_KEY=AKIAIOSFODNN7EXAMPLE …”

Resolve
Extractoryour code
Check
Input verifieryour code
Approve
Execute
Result processoryour code
Sign

Resolve
Alice’s policies, the agent’s and the model service’s combine
Input verifier
secret_scanner reads the prompt and finds an AWS key
Outcome
RefusedThe prompt never reached the model.

Hooks in the guide →

How MAPL compares.

Keep OPA, Cedar and IAM for the access they already control. MAPL adds what agents need on top: authority that follows the person through every agent and service, approvals, and checks on what each call actually does.

Capability	Detail	MAPL	Cedar	OPA/Rego	AWS IAM	OpenFGA	NeMo Guardrails
Composition	Authority only narrows as policies compose, proved	●	◐	◐	◐	○	○
	Explicit deny cannot be overridden	●	●	◐	●	◐	◐
	Caller and service policies both constrain access	●	◐	◐	◐	◐	○
	Policies attached to data and objects	●	●	◐	●	●	○
	Restrictions follow derived data through references	●	○	◐	○	◐	○
Identity and delegation	Identity bound from IdP claims at call time	●	◐	◐	◐	◐	○
Identity and delegation	Authority narrows at every agent hop	●	○	◐	◐	◐	○
Agent actions	Native model, tool and MCP resources	●	◐	◐	○	○	◐
Agent actions	Model, parameter and token constraints	●	◐	◐	○	○	◐
Approvals and evidence	Named approvers, conditions, pending decisions, expiry	●	○	◐	○	○	◐
Approvals and evidence	Signed, single-use evidence the agent can’t forge	●	○	○	○	○	○
Extensibility and assurance	Custom logic that can only tighten a decision	●	○	◐	○	◐	◐
	Rich logic over structured request data	●	◐	●	○	◐	◐
	Mechanized proofs (Lean)	●	●	○	◐	○	○
	Validated before deployment; effective policy explained	●	●	◐	●	◐	○

● built in · ◐ partial, or with custom code · ○ not supported. Hover or tap a mark for the reason and the source. From each project’s public documentation, November 2026.

Already on Cedar or OPA? Your policies port to MAPL.

Why MAPL solution brief Policies in the docs

The MAPL skill.

Install the MACAW plugin for Claude Code or Codex and use the /mapl skill. Say what your agents may do; it writes the policy.

You say

“Alice can read employee records, up to 100 at a time. Any update needs a manager’s approval. Deletes aren’t allowed.”

Install

/plugin marketplace add macawsecurity/macaw-plugin
/plugin install macaw-cc@macaw

Tested with Claude (Sonnet, Haiku, Opus), Codex (Terra, Luna, Sol) and Qwen3 8B.

Install for Claude Code or Codex Read the SKILL.md

Policy Assistant · in the console

Any policy, explained back.

Open a policy and ask. You get what it allows, what it blocks and its limits, in plain English.

The console

Written policy, stated in MAPL.

τ²-bench gives an airline agent and a retail agent their business rules in plain prose. We wrote them in MAPL and ran the benchmark’s calls through MACAW.

52 of 56
written rules about calls stated in MAPL. The other four are checks the benchmark’s own tools make.: 163 of 164
correct calls allowed. The one refused breaks the airline’s own written rule.: 36 of 36
rule-breaking calls refused. The benchmark’s own tools accept 19 of them.

The benchmarks

Read the spec. It’s open.

The full language: policies, inheritance, approvals, functions, and the formal foundations.

The MAPL guide The solution brief

Express and verify intent, formally.

Why MAPL.

Declarative and verifiable

Bound at call time

Many authors, one algebra

Dynamic state

A policy has four parts.

Resources

Denied resources

Parameter constraints

Approvals

Common scenarios.

The intersection algebra.

A child can only narrow.

Human, agent and claims-based approvals.

Human or agent approval

Short-lived scopes

System state

A person is present

Programmable verification pipeline, with hooks.

Hooks in practice.

How MAPL compares.

The MAPL skill.

Any policy, explained back.

Written policy, stated in MAPL.

Read the spec. It’s open.