Skip to content

Govern every AI action. Prove every outcome.

Stop AI chaos—control spend, enforce policy, and get financial‑grade audit with a neutral Layer‑2 fabric.

  • Budget control
  • Security enforcement
  • Immutable audit

The governance gap

  • Budgetary chaos — unpredictable, runaway spend
  • Unauthorized actions — agents doing things they shouldn’t
  • Security breaches — tool/agent injection and new attack surface
  • Missing authorization — what is an agent actually allowed to do?
  • No audit trail — no financial‑grade proof of decisions and spend

How delegation works

ARIA: AI Agent Governance Identities, delegations, policy bindings, lifecycle, and runtime enforcement. ARIA Agent Risk & Identity Authorization ARIA: AI Agent Governance ARIA: AI Agent Governance Agent Risk & Identity Authorization First-class identities with ownership, delegation, and policy enforcement 🎯 ARIA INNOVATION Agents ARE first-class Identity objects Risk + Identity unified governance 1. IDENTITY MODEL: First-Class Graph Objects All identities (Person, AIAgent, Service) live in Neo4j with consistent governance :Person (Alice) :AIAgent (Travel Bot) :Service (AITravel SvcP) :Policy (YAML Doctrine) ✅ Benefits • Unified identity model • Consistent governance • Graph traversal = context • Discoverable ownership • Auditable lineage 2. RELATIONSHIPS: Ownership + Delegation Explicit graph edges capture control, delegation, and policy bindings A. CONTROLLED_BY (Ownership) Agent CONTROLLED_BY Owner • Discoverable: Who owns this agent? • Auditable: All controllers queryable • PUT/GET/DELETE via API B. DELEGATES_TO (Consent + Scope) Alice DELEGATES_TO status: active capabilities: [...] Travel Bot Properties: status, capabilities[], constraints, trust_level, service_id, jkt, expires_at Source of truth: "who can do what on behalf of whom" C. POLICY_REF (Static Rules) Agent POLICY_REF budget .yaml • Versioned YAML policies (static doctrine) • PDP evaluates policy + delegation constraints • Emits decisions + obligations → PEP enforces 3. LIFECYCLE: Registration → Delegation → Verification → Revocation 1 Register Create Service + Agent instance 2 Link Owner CONTROLLED_BY relationship 3 Delegate DELEGATES_TO + constraints 4 Verify Active delegation + optional jkt 5 Revoke Immediate or scheduled expiry 📡 API Surface (Already Available) POST /api/v1/agents/service-principals POST /api/v1/agents/user-bound-agents PUT /api/v1/agents/{id}/control POST /api/v1/delegations (create/verify) POST /api/v1/delegations/{id}/revoke 4. RUNTIME: ARIA Authorization Flow (OBO Token Exchange + Policy Enforcement) AGENT REQUEST Subject: AI Agent Resource: Alice Action: book_flight (OBO token) PDP EVALUATION 1. Verify DELEGATES_TO 2. Check constraints 3. Evaluate policy YAML 4. Merge + resolve conflicts DECISION ✅ PERMIT Obligations: [log_access, notify_user] PEP ENFORCEMENT Execute action Apply obligations Emit to Kafka → Flight booked! 📊 Observability • Metrics: verification latency, orphan checks • Logs: correlation IDs, decision reasons • Events: Kafka for cache invalidation • Audit: All delegations fully traceable ARIA: Agent Risk & Identity Authorization - First-class identities with explicit ownership, delegation, and unified policy enforcement Enables: Discoverable ownership • Auditable consent • Runtime verification • Immediate revocation • Full observability
Where agents, PDP, and Membership meet — identities, delegations, policy, and enforcement.

What we control

AreaExamples
Access scopeWhich tools and operations
Time windowWorking hours or limited duration
LocationGeo/IP allow‑lists
BudgetSpend caps with safe stop

Our solution

Create once. Enforce everywhere. Prove every action.

  • Create tools once — No‑code Orchestration Service turns any API/DB/workflow into a governed MCP tool
  • Enforce policy everywhere — ARIA Shield + MCP Gateway apply budgets, constraints, and allow‑lists across agents
  • Prove every action — Receipt Vault issues cryptographic receipts (decision context, policy hash, schema hash, spend)

Decisions with constraints & obligations

The PDP returns constraints (egress_allow, models_allow, data_scope, spend_budget) that PEPs enforce synchronously, and obligations (audit_log, run_workflow, consent) performed after.

PDP deep‑dive →

Threats → Controls

ThreatControlEnforced by
Schema driftSchema pins (version/hash, grace window)MCP Gateway
OverspendPre‑gate budgets + stream‑time settlePDP + Shield
Prompt leakageEgress allow‑lists, classification policiesShield
Replay/token theftPairwise sub, act.sub, optional DPoPIdP + PEPs
Missing auditSigned, hash‑chained receiptsPEPs + Receipt Vault

How it works (end‑to‑end)

  1. Ingress with ARIA Passport (user ↔ agent binding)
  2. Schema pin & optional plan validation
  3. PDP decision → constraints & obligations
  4. PEP enforcement (budgets, egress, params)
  5. Tool call → Receipt emitted → Analytics updates budgets

Proven DNA you can bank on

Connector DNA Authorization DNA Enforcement DNA Audit DNA

Two decades of identity governance experience applied to the agent era. Neutral, OEM‑ready, and standards‑aligned (MCP • OAuth TE/RAR/DPoP • AuthZEN‑style).

Universal middleware

EmpowerNow is independent of your identity stack and your agent platform. Create governed tools once; run across agents and platforms without lock‑in.

Read the Strategy Memo →