ARIA Framework
Master AI Agent authorization with the ARIA framework: delegations, user-bound agents, trust levels, chain eligibility, and PDP integration.
πLearning Objectives
- Understand the ARIA framework and why AI agents need special authorization
- Learn the delegation model with
DELEGATES_TOrelationships - Configure capabilities, trust levels, and constraints
- Validate delegation chains for multi-hop agent operations
- Integrate ARIA with PDP policies
- Create and verify delegations via the API
π€Why AI Agents Need Special Authorization
Traditional OAuth scopes work for human users interacting directly with applications. But AI agents operate differently:
π Acting On-Behalf-Of
Agent performs actions as if it were the user, not as itself
β±οΈ Time-Bounded
Delegations should expireβagents shouldn't have permanent access
π― Capability-Scoped
Agent can only do specific things, not everything the user can do
π° Constraint-Limited
Spending caps, IP restrictions, and other guardrails
π Chain-Validated
When Agent A delegates to Agent B, the full chain must be authorized
π Trust-Scored
Different trust levels unlock different capabilities
πThe Delegation Model
ARIA stores delegations as DELEGATES_TO edges in the Neo4j identity graph.
(alice@acme.com)"] A1["π€ Invoice Agent
(agent-123)"] A2["π€ Payment Agent
(agent-456)"] U -->|"DELEGATES_TO
caps: [invoice:read, invoice:pay]
spend_cap: $5000
expires: 24h"| A1 A1 -->|"DELEGATES_TO
caps: [payment:initiate]
spend_cap: $1000
chain_ok: true"| A2 style U fill:#10b98122,stroke:#10b981 style A1 fill:#00d9ff22,stroke:#00d9ff style A2 fill:#a855f722,stroke:#a855f7
DELEGATES_TO Edge Properties
| Property | Type | Description |
|---|---|---|
id |
UUID | Unique delegation identifier |
status |
Enum | active, suspended, expired, revoked |
capabilities |
Array | Allowed actions: ['invoice:read', 'invoice:pay'] |
constraints |
Object | Limits: { spend_cap: 5000, ip_range: ['10.0.0.0/8'] } |
trust_level |
Enum | low, medium, high |
created_at |
DateTime | When delegation was created |
expires_at |
DateTime | When delegation expires (null = permanent) |
Creating a Delegation (Cypher)
-- Create delegation from user to agent
MATCH (u:Identity {id: "alice@acme.com"})
MATCH (a:Agent {id: "agent-123"})
CREATE (u)-[:DELEGATES_TO {
id: randomUUID(),
status: 'active',
capabilities: ['invoice:read', 'invoice:pay'],
constraints: { spend_cap: 5000 },
trust_level: 'medium',
created_at: datetime(),
expires_at: datetime() + duration('P1D')
}]->(a);
π‘οΈTrust Levels & Capabilities
Trust levels control what capabilities an agent can be granted and what actions it can perform.
| Trust Level | Allowed Capabilities | Constraints |
|---|---|---|
| low | Read-only operations | Strict IP ranges, short expiry (1 hour) |
| medium | Read + limited write | Spend caps, moderate expiry (24 hours) |
| high | Full delegated authority | Higher limits, longer expiry (7 days) |
Capability Examples
// Common capability patterns
capabilities: [
'invoice:read', // View invoices
'invoice:pay', // Pay invoices (requires spend_cap)
'user:read', // Read user profiles
'mcp.tools.invoke', // Call MCP tools
'llm:use', // Make LLM requests (requires budget)
'doc:sign' // E-sign documents
]
πChain Eligibility Validation
When agents delegate to other agents, the full delegation chain must be validated. This prevents privilege escalation.
1. All edges active?
2. Capabilities inherited?
3. Constraints satisfied? Membership-->>PDP: chain_valid: true, effective_caps: [payment:initiate] PDP-->>Agent2: Permit (with spend_cap: $1000)
Chain Validation Rules
- All hops must be active: Every
DELEGATES_TOedge in the chain must havestatus: 'active' - No expired delegations: All
expires_attimestamps must be in the future - Capability intersection: Agent can only use capabilities present in ALL hops
- Constraint inheritance: Most restrictive constraint from any hop applies
- Trust level floor: Effective trust level is the minimum in the chain
PIP Endpoint for Chain Eligibility
# Check if agent can perform action via delegation chain
curl https://membership.self.empowernow.ai/api/v1/pip/chain-eligibility \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"subject_id": "agent-456",
"required_capability": "payment:initiate",
"context": {
"amount": 720
}
}'
# Response
{
"chain_valid": true,
"chain_length": 2,
"effective_capabilities": ["payment:initiate"],
"effective_constraints": {
"spend_cap": 1000
},
"effective_trust_level": "medium",
"delegation_ids": ["del-abc", "del-xyz"]
}
πPDP Integration
PDP policies can reference delegation context to make authorization decisions.
Policy Example: Allow Delegated Invoice Payment
# PDP policy for delegated agent actions
id: allow-delegated-invoice-payment
subjects:
- type: delegated_identity # Magic type - resolved by PIP
capability: invoice:pay
rules:
- resource: payment
action: initiate
effect: permit
allowIf: >
context.delegation.trust_level in ['medium', 'high'] and
context.delegation.chain_valid == true and
context.amount <= context.delegation.constraints.spend_cap
PDP Request with Delegation Context
# Agent requests authorization
curl -X POST https://pdp.self.empowernow.ai/access/v1/evaluation \
-H "Authorization: Bearer $AGENT_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"subject": {
"type": "ai_agent",
"id": "agent-123"
},
"action": { "name": "initiate" },
"resource": {
"type": "payment",
"id": "pay-777"
},
"context": {
"delegation": {
"from": "alice@acme.com",
"caps": ["invoice:pay"],
"edge_id": "del-abc123"
},
"amount": 720
}
}'
# Response
{
"decision": true,
"context": {
"constraints": [
{ "id": "spend_cap", "value": 5000 }
],
"obligations": [
{ "id": "audit", "type": "log_delegation_use" }
],
"delegation": {
"from": "alice@acme.com",
"edge_id": "del-abc123"
}
}
}
π§Delegation API Operations
Create Delegation
# User delegates to agent
curl -X POST https://membership.self.empowernow.ai/api/v1/delegations \
-H "Authorization: Bearer $USER_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"delegator_id": "alice@acme.com",
"delegate_id": "agent-123",
"capabilities": ["invoice:read", "invoice:pay"],
"constraints": {
"spend_cap": 5000,
"ip_range": ["10.0.0.0/8"]
},
"trust_level": "medium",
"expires_in": "24h"
}'
# Response
{
"delegation_id": "del-abc123",
"status": "active",
"expires_at": "2026-01-22T15:30:00Z"
}
Verify Delegation
# Verify delegation is valid before using
curl https://membership.self.empowernow.ai/api/v1/delegations/verify \
-H "Authorization: Bearer $AGENT_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"delegator_id": "alice@acme.com",
"delegate_id": "agent-123",
"required_capabilities": ["invoice:pay"]
}'
# Response
{
"valid": true,
"delegation_id": "del-abc123",
"capabilities": ["invoice:read", "invoice:pay"],
"constraints": { "spend_cap": 5000 },
"trust_level": "medium",
"expires_at": "2026-01-22T15:30:00Z"
}
Revoke Delegation
# Revoke a delegation immediately
curl -X DELETE https://membership.self.empowernow.ai/api/v1/delegations/del-abc123 \
-H "Authorization: Bearer $USER_TOKEN"
# Response
{
"delegation_id": "del-abc123",
"status": "revoked",
"revoked_at": "2026-01-21T10:30:00Z"
}
πPlan Contracts
Plan Contracts pre-approve the steps, inputs, and budgets an agent can execute. Before any tool call, the agent's actions are validated against the contract.
Plan Contract Structure
{
"version": "plan/v1",
"meta": {
"prompt_id": "identity.onboard@1.0.0",
"tenant": "cont-av",
"max_budget_usd": 5.00
},
"steps": [
{
"kind": "approve",
"id": "gate",
"params": { "message": "Create account for {{ name }}?" }
},
{
"kind": "workflow",
"ref": "av_ad_create_user",
"version": "1.0.0",
"params": {
"FirstName": "{{ first_name }}",
"LastName": "{{ last_name }}",
"Email": "{{ email }}"
},
"allow_tags": ["account", "create", "ad"],
"dry_run": true
}
]
}
Step Kinds
| Kind | Description |
|---|---|
approve |
Pause for human approval before continuing |
workflow |
Execute a CRUDService workflow |
tool |
Call a single MCP tool |
simulate |
Dry-run to show what would happen |
wait |
Pause for a specified duration |
Contract Enforcement Flow
contract?} C1 -- No --> D1[Deny + explain mismatch] C1 -- Yes --> C2{Cost within
step cap?} C2 -- No --> D2[Deny + show limits] C2 -- Yes --> C3{Total budget
OK?} C3 -- No --> D3[Deny + show budget] C3 -- Yes --> E[Execute step] E --> N{More steps?} N -- Yes --> C1 N -- No --> K[Plan complete] style D1 fill:#f43f5e22,stroke:#f43f5e style D2 fill:#f43f5e22,stroke:#f43f5e style D3 fill:#f43f5e22,stroke:#f43f5e style K fill:#10b98122,stroke:#10b981
If an agent tries to execute a step not in the contract, or with parameters that don't match, the call is denied before it reaches the tool. This prevents prompt injection from causing unplanned actions.
π‘οΈHow ARIA's 7 Controls Reinforce Delegation
ARIA's seven controls work together to secure delegated agent actions:
| Control | Role in Delegation |
|---|---|
| 1. User-Bound Identity | Agent is tied to exactly one user; delegation can't leak to others |
| 2. Capability Proofs | Agent proves it holds specific capability without revealing all permissions |
| 3. Plan Contracts | Pre-approved steps and budgets; off-script actions denied |
| 4. Context Binding | Decision tied to exact trusted context (prevents prompt injection) |
| 5. Tool Attestation | Tool schema version verified; drift blocked until approved |
| 6. Behavioral DNA | Agent behavior baseline tracked; drift triggers alerts |
| 7. Receipt Chains | Every decision generates tamper-evident receipt for audit |
End-to-End Example
When Alice delegates invoice approval to her AI assistant:
- User-Bound: Agent instance is tied to Alice
- Capability: Agent proves it has
invoice:approve - Plan: Contract allows only approve/reject on invoices β€$1000
- Context: Decision bound to the specific invoice data
- Attestation: SAP BAPI tool version verified
- BDNA: Agent's approval pattern within normal range
- Receipt: Signed record: Alice β agent β approve β $750 invoice
πTroubleshooting
Delegation Not Found
Symptom: {"error": "No active delegation from alice@acme.com to agent-123"}
Debug:
# Check delegation in Neo4j
MATCH (u:Identity)-[d:DELEGATES_TO]->(a:Agent)
WHERE u.id = 'alice@acme.com' AND a.id = 'agent-123'
RETURN d.status, d.expires_at, d.capabilities;
Causes: Delegation never created, expired, revoked, or wrong IDs.
Capability Not Granted
Symptom: {"error": "Capability 'invoice:delete' not in delegation"}
Fix: The delegation only grants specific capabilities. Create a new delegation with the required capability, or use an existing capability that's already granted.
Chain Validation Failed
Symptom: {"chain_valid": false, "reason": "hop 2 expired"}
Fix: One of the delegations in the chain has expired. Each delegation must be renewed independently.
Constraint Violation
Symptom: {"error": "Amount 6000 exceeds spend_cap 5000"}
Fix: The action violates a constraint. Either reduce the amount or request a new delegation with higher limits.
βKnowledge Check
A DELEGATES_TO relationship is a graph edge from a delegator (user or agent) to a delegate (agent). It grants the delegate permission to act on behalf of the delegator, subject to capabilities, constraints, trust level, and expiration.
Capabilities are intersected across the chain. If User delegates [read, write] to Agent A, and Agent A delegates [write, delete] to Agent B, then Agent B's effective capabilities are only [write] (the intersection). An agent can never gain capabilities not present in every hop.
The delegation's status is set to expired (either by a TTL job or on access). Any chain validation that includes this delegation will fail. The agent can no longer act on behalf of the delegator until a new delegation is created.
The PEP (Policy Enforcement Point) calls the /delegations/verify endpoint before calling the PDP. The verified delegation info (capabilities, constraints, trust level) is passed in the context.delegation field of the PDP request. The PDP policy then references these values in its rules.
Chain validation enforces that: (1) capabilities are intersected (can only shrink, never grow), (2) constraints use the most restrictive value from any hop, (3) trust level is the minimum in the chain. This ensures Agent B can never have more authority than Agent A, which can never have more than the original User.
πDay 23 Checkpoint
- Understand why AI agents need special authorization (ARIA)
- Know the DELEGATES_TO relationship and its properties
- Understand trust levels and capability scoping
- Know how chain validation works
- Can create, verify, and revoke delegations via API
- Understand PDP integration for delegated actions