Advanced Policy Patterns
Advanced MAPL patterns for complex access control scenarios: conditional attestations, time-based policies, service agent policies, and dual-perspective enforcement.
Conditional Attestations
Attestation requirements can be conditional on runtime parameters using the::{condition} syntax:
{
"attestations": [
"identity_verified",
"trade_approved::{params.amount > 5000}",
"manager_override::{params.priority == 'urgent' AND params.amount > 10000}"
]
}Condition Syntax Reference
| Reference | Description | Example |
|---|---|---|
| params.X | Invocation parameter | params.amount > 5000 |
| principal.X | Authenticated user attribute | principal.user_id == 'admin' |
| principal.has_role('X') | Role check | principal.has_role('manager') |
| principal.has_group('X') | Group check | principal.has_group('trading') |
| context.has_attestation('X') | Existing attestation check | context.has_attestation('mfa') |
Tiered Approval Example
{
"attestations": [
"identity_verified",
"team_lead_approval::{params.amount > 1000 AND params.amount <= 10000}",
"manager_approval::{params.amount > 10000 AND params.amount <= 50000}",
"director_approval::{params.amount > 50000}"
],
"constraints": {
"attestations": {
"team_lead_approval": {
"approval_criteria": "role:team_lead",
"timeout": 300
},
"manager_approval": {
"approval_criteria": "role:manager",
"timeout": 600
},
"director_approval": {
"approval_criteria": "role:director",
"timeout": 3600
}
}
}
}Time-Based Policies
Policies can include validity windows for temporary access grants:
{
"policy_id": "group:emergency-access",
"description": "Time-bounded emergency access",
"validity": {
"not_before": "2025-01-17T09:00:00Z",
"not_after": "2025-01-17T17:00:00Z"
},
"resources": ["admin:**"],
"constraints": {
"audit_level": "maximum",
"require_approval": true
}
}Use time-bounded groups instead of overrides for emergency access. When the validity period expires, access is automatically revoked.
Service Agent Policies (app: prefix)
Beyond organizational policies, MAPL supports service agent policies that define what services themselves allow:
{
"policy_id": "app:trading-service",
"description": "Trading service - what it offers",
"scope": "service",
"resources": [
"trade:execute",
"trade:cancel",
"quote:get"
],
"constraints": {
"parameters": {
"trade:execute": {
"amount": {"max": 100000},
"currency": {
"allowed_values": ["USD", "EUR", "GBP"]
}
}
}
}
}Dual Perspective Enforcement
MAPL enforces policies from two perspectives, intersected for final access:
┌────────────────────┐ ┌────────────────────┐
│ Caller Policy │ │ Service Policy │
│ (user:alice) │ │ (app:trading) │
│ │ │ │
│ What can Alice │ │ What does the │
│ request? │ │ service allow? │
└─────────┬──────────┘ └─────────┬──────────┘
│ │
└──────────┬───────────────┘
│
▼
┌──────────────────────┐
│ Effective Policy │
│ = Caller ∩ Service │
│ │
│ BOTH must allow │
│ for access │
└──────────────────────┘Even if the caller's policy allows an operation, the service policy must also allow it. This provides defense in depth—compromising one perspective doesn't grant full access.
Attestation Grants (Reusable Approvals)
Set one_time: false to create grants that can be reused multiple times within a validity window:
{
"constraints": {
"attestations": {
"trading_window": {
"approval_criteria": "role:manager",
"one_time": false, // Reusable grant
"time_to_live": 3600, // Valid for 1 hour
"max_uses": 100 // Optional: limit total uses
}
}
}
}How Grants Work
- • Manager approves once → Grant created
- • Agent can execute multiple operations
- • Each use emits audit event
- • Grant expires when time_to_live elapses
Use Cases
- • Batch operations (approve once, run many)
- • Time-boxed elevated access (trading window)
- • Delegated authority (manager grants for a period)