PaperlayerView exact revision on arXiv

Source-linked AI summary

A Unified Policy Architecture (UPA): The Governance Kernel for Enterprise AI Operating Systems

Prabhu Raghav, Balamurugan Pandi, Arul Vivek, Shek Mohammed, Sridhar S

arXiv:2609.06543v1cs.AIcs.CLcs.SE

TL;DR

Autonomous AI agents dynamically reason, plan, use tools, retrieve knowledge, maintain memory, collaborate, and adapt execution, while existing governance capabilities remain fragmented across separate mechanisms. The paper introduces UPA and its Policy Kernel as a declarative runtime layer that continuously mediates autonomous execution; evaluations report correct policy resolution, low latency at 1,000 policies, and scaling costs at 5,000 policies.

  • Problem

    Existing governance capabilities operate independently and lack a common abstraction for continuously enforcing enterprise policies across autonomous AI systems.

  • Method

    UPA separates governance from execution through a declarative Policy Kernel that evaluates enterprise policies before, during, and after autonomous execution.

  • Results

    UPA unified runtime governance across autonomous execution, achieving a 100% pass rate (9/9 test cases), sub-3.2 ms median latency up to 1,000 policies, and 17.2 ms median latency at 5,000 policies.

  • Takeaways & Limitations

    UPA provides a policy-centric foundation for governing autonomous AI execution across agents, resources, tools, memory systems, workflows, and organizational policies.

  • Takeaways & Limitations

    The architecture does not establish a complete formal verification framework for proving policy correctness or the absence of conflicting governance rules.

Abstract

from arXiv · show

Enterprise AI is evolving into an Enterprise Operating System where autonomous AI agents can plan, reason, use memory, invoke tools, execute workflows, and collaborate with other agents. This shift creates a new governance challenge: existing authorization, security, guardrails, and compliance mechanisms are fragmented and are not designed to govern autonomous AI as a unified system. This paper introduces the Unified Policy Architecture (UPA), a governance architecture for Enterprise AI Operating Systems. UPA provides a unified policy model for governing AI and agents, tools, workflows, memory, enterprise resources, and agent-to-agent interactions and enterprise business rules. It extends policy control beyond authorisation to include runtime obligations, human approvals, compliance, audit evidence, and governance evaluation. We present UPA's governance model, declarative policy language foundations, policy evaluation semantics, extensible plugins, industry policy packs, and an evaluation framework for enterprise governance. We also identify extensions for multi-agent coordination, provenance-aware policies, and stateful runtime governance. UPA provides a foundation for building secure, accountable, and governable Enterprise Operating Systems for autonomous AI.

1 Introduction

Autonomous AI agents create governance requirements that exceed isolated authorization, safety, and guardrail mechanisms. UPA addresses this gap with a declarative, policy-centric runtime layer spanning heterogeneous AI execution and enterprise governance.

  • Unified Policy Architecture: UPA introduces a declarative Policy Kernel that unifies authorization, runtime governance, compliance, auditability, approval workflows, business rules, and multi-agent governance.The architecture separates governance logic from application logic and is intended to support heterogeneous Enterprise AI Operating Systems.
  • Unified Policy Architecture: Semantic Normalization converts heterogeneous runtime events into a canonical policy representation across models, agents, workflows, tools, APIs, and enterprise applications.This framework-independent model supports consistent governance across different execution environments.
  • Unified Policy Architecture: A Governance Provider Framework separates evaluation providers from obligation providers, enabling extensible threat detection, risk scoring, privacy, compliance, and audit functions without modifying the core kernel.UPA also positions runtime obligations, governance evidence, approval workflows, and industry policy packs as first-class constructs beyond authorization.
  • Positioning and scope: UPA is presented as a complementary, platform-independent governance layer that governs existing authorization engines, guardrails, and agent frameworks consistently rather than replacing them.Its intended scope is lifecycle-wide governance across heterogeneous autonomous AI systems.
  • Problem and research gap: Autonomous AI agents dynamically reason, plan, use tools, retrieve knowledge, maintain memory, and collaborate, requiring governance throughout execution rather than at one checkpoint.Their runtime-generated execution paths differ from deterministic software and complicate conventional governance.
  • Problem and research gap: Existing authorization, guardrail, Zero Trust, and multi-agent approaches operate independently and lack a common abstraction for consistent enterprise policy enforcement.The gap includes memory access, tool invocation, workflow execution, inter-agent communication, and dynamic plans.

5 Formal Mathematical Foundation

UPA formalizes enterprise AI governance as deterministic transformations from heterogeneous runtime events to governed outcomes. The model normalizes events, evaluates policies and providers, returns decisions and obligations, and enforces them at runtime.

  • 5.1 Governance Execution Model: UPA models governance as four sequential stages: semantic normalization, policy evaluation, governance obligations, and runtime enforcement.The sequence transforms heterogeneous events into governed execution outcomes.
  • 5.2 Runtime Event Model: Runtime events arise from users, agents, workflows, memory, tools, APIs, and inter-agent communications, and are represented with source, operation, resource, context, and metadata.The execution context includes principal, environment, session, tenant, and timestamp, while metadata supports observability and audit evidence.
  • 5.1 Governance Execution Model: Policy evaluation produces a governance decision and an ordered set of obligations, while Evaluation Providers may add threat, risk, classification, or contextual attributes.The decision space includes Allow, Deny, and Approve; runtime outcomes include Executed, Blocked, PendingApproval, and Failed.
  • 5.1 Governance Execution Model: Runtime Governance enforces the decision and obligations: Allow proceeds after obligations succeed, Deny blocks execution, and Approve suspends execution for human approval.Mandatory obligation failure produces a Failed runtime outcome.
  • 5.1 Governance Execution Model: UPA treats enforcement as continuous runtime governance rather than one-time authorization, while remaining independent of AI frameworks, orchestration platforms, and applications.This design supports consistent governance across heterogeneous execution environments.
  • 5.3 Semantic Normalization Function: Semantic Normalization maps every heterogeneous runtime event to exactly one canonical policy request, making policy evaluation independent of the originating framework.The canonical request uses Principal, Action, Resource, and Context, with runtime metadata retained separately.

2. Evaluation Provider Execution

UPA evaluates all applicable policy statements and augments canonical requests with dynamically generated governance attributes. Pluggable Evaluation Providers add capabilities without changing the Policy Kernel or existing policy semantics.

  • Policy Matching: UPA evaluates all applicable policy statements to support composition, layered governance, compliance verification, and organizational policy inheritance.Unlike engines that stop at the first matching rule, UPA collects the full matched set.
  • Evaluation Providers: Evaluation Providers compute runtime governance attributes such as threat assessments, semantic classifications, risk scores, and contextual information during policy evaluation.These attributes can influence whether a request is allowed, denied, or requires explicit approval.
  • Evaluation Providers: Provider outputs are combined into the complete set of governance attributes available to policy evaluation.The provider framework separates attribute generation from declarative policy evaluation.
  • Evaluation Providers: New evaluation capabilities can be introduced without modifying the Policy Kernel or existing policy semantics.This separation provides extensibility while preserving the core evaluation model.

1. Policy Priority

UPA defines deterministic policy evaluation, conflict resolution, runtime enforcement, and declarative policy composition. DGPL expresses governance requirements across authorization, safety, compliance, approvals, and extensible controls without embedding procedural logic in applications.

  • Policy Priority: Policy conflicts are resolved by priority, then effect precedence, specificity, and version, with Deny > Approve > Allow when priorities tie.The final decision is Allow, Deny, or Approve.
  • Policy Priority: Approve is a first-class governance decision that suspends execution until an organizational approval workflow completes.This extends authorization beyond permit-or-deny access control.
  • Runtime Governance: Runtime Governance executes ordered obligations before continuation, blocks Deny decisions, suspends Approve decisions, and returns Failed when mandatory obligations cannot complete.The runtime outcome space is Executed, Blocked, PendingApproval, or Failed.
  • Formal Properties: UPA specifies deterministic normalization, evaluation, conflict resolution, governance completeness, framework independence, and extensibility properties.Equivalent requests, policies, and provider outputs produce the same governance outcomes.
  • Declarative Governance Policy Language: DGPL expresses authorization, AI safety, runtime governance, threat detection, obligations, human approvals, and enterprise governance declaratively and independently of implementation languages or frameworks.JSON and YAML represent the same underlying policy semantics.
  • Policy Composition: Policy composition lets independent statements express layered requirements, while conflict resolution preserves one deterministic governance decision.Default deny permits autonomous execution only when applicable policies explicitly authorize it.
  • Governance Extensions: Governance Extensions and the Plugin Framework add capabilities without modifying the core PARC structure, Policy Kernel, or fundamental DGPL model.The same language can express authorization, contextual governance, threat detection, runtime transformations, and human approval.

7 Industry Policy Packs

Industry Policy Packs distribute reusable, versioned DGPL statements for domain-specific governance while using the same Policy Kernel and evaluation mechanisms. They can combine domain controls with cross-industry protections and introduce human approval at defined decision boundaries.

  • Industry Policy Packs: Industry Policy Packs address fragmented, duplicated, and inconsistent controls by providing reusable DGPL statements for particular industries or governance domains.A pack can include authorization rules, contextual conditions, obligations, approvals, and provider bindings.
  • Industry Policy Packs: Packs are versioned collections of ordinary DGPL statements identified by domain, version, and statement set, and multiple packs can coexist in one repository.A healthcare organization with a financial-services division can activate both Healthcare and Finance packs.
  • Industry Policy Packs: Policy packs extend the policy repository rather than the policy evaluation architecture, so domain-specific governance requires no industry-specific evaluation path.The same kernel handles internally authored and pack-provided statements.
  • Industry Policy Pack Examples: Importing a policy pack alone does not constitute certification or regulatory compliance.Regulatory and standards references describe governance context rather than guaranteeing compliance.
  • Industry Policy Packs: Industry-specific differences are expressed through combinations of principals, actions, resources, conditions, effects, and obligations rather than different evaluation mechanisms.Healthcare, Banking, Oil and Gas, and other domains share the same PARC model and provider framework.
  • Cross-Industry Controls: Cross-industry policy components can be composed with industry packs, such as detecting and redacting sensitive information before an LLM receives input.The same protection policy can combine with Healthcare, Finance, Oil and Gas, or other packs.
  • Banking — Fraud Detection Agent: Industry Policy Packs can preserve autonomous execution for lower-risk reversible actions while requiring human control for high-impact decisions.A high-impact banking action suspends autonomous execution and initiates approval for the designated FraudOfficer.
  • Architectural Benefits: Policy packs separate threat-detection implementation from domain-specific governance policy and provide a reusable distribution mechanism for DGPL.They share the underlying policy semantics, obligations, approval mechanisms, and provider framework.

8 SID Registry, Indexing, and Resolution

UPA gives each DGPL policy statement a stable Statement Identifier (SID), while indexing narrows candidate retrieval without changing policy identity. Resolution then connects applicable statements to governance decisions, auditability, explanations, approvals, and evidence.

  • Each DGPL policy statement receives a unique SID that identifies its originating statement across evaluation results, obligations, audit records, and administrative operations.
  • A SID identifies a policy statement but does not determine whether it matches a request; matching uses applicable policy attributes.
  • The SID Registry maintains the mapping between statement identifiers and their corresponding DGPL statements, independent of physical policy storage.
  • Indexing reduces candidate statements considered during matching, but final applicability remains the responsibility of policy matching and evaluation.
  • Resolved SIDs connect runtime governance decisions to the policy statements that contributed to them and support auditability, explanation, approvals, and governance evidence.
  • Separating indexing from SID resolution lets the Policy Kernel optimize retrieval without changing the semantic identity of DGPL statements.

9 Experimental Evaluation

UPA’s preliminary evaluation covers correctness, latency, scalability, plugin overhead, and semantic normalization. The prototype achieved complete correctness on the verification suite and showed successful concurrency and normalization, while sequential traversal and heavyweight plugins created performance limits.

  • Correctness: All nine structured correctness cases returned the expected governance decisions, including precedence, mismatches, default deny, approvals, and conflict resolution.
  • Latency and repository scalability: Median authorization latency stayed below approximately 3.2 ms through 1,000 policies, then reached 17.2241 ms at 5,000 policies, with P95 at 108.248 ms.
  • Latency and repository scalability: Sequential throughput decreased as repositories grew because the evaluator traversed the complete policy set before finding the matching rule.
  • Concurrent request scalability: 1,860 concurrent authorization requests completed without failures, with throughput reaching 237.96 requests per second at concurrency 50 and remaining near that level at 100.
  • Plugin execution overhead: The secret scanner added 0.0092 ms of mean overhead, whereas Presidio added approximately 2,398.54 ms and dominated runtime.The combined plugin result is preliminary because warm-up, caching, dependency initialization, and test order may influence measurements.
  • Interoperability and semantic normalization: Semantic Normalization converted a natural-language request into the expected canonical action and resource while preserving the authenticated principal.The paper states that broader labelled testing is needed to quantify normalization accuracy across multiple actions, resources, and runtime formats.

10 Discussion

UPA treats Enterprise AI governance as a centralized runtime control plane that separates policy definition, evaluation, and execution while coordinating authorization, obligations, approvals, and extensions. Its scope complements existing authorization and safety mechanisms but introduces latency, policy-quality, provider-dependency, and verification limitations.

  • Architectural model: UPA models governance as a coordinated control plane spanning policy evaluation, runtime enforcement, human intervention, and extensible governance components.The architecture targets autonomous agents and LLM applications rather than treating governance solely as model-level safety.
  • Architectural model: Separating policy definition, evaluation, and execution keeps governance rules independent of individual agent implementations.DGPL represents governance requirements, while the Policy Kernel evaluates normalized requests against applicable policies.
  • Policy semantics: The PARC model provides a common representation for matching policies across heterogeneous agents, tools, resources, and runtime operations.PARC denotes Principal, Action, Resource, and Context.
  • Governance outcomes: UPA supports Allow, Deny, Approve, and governance obligations such as human approval, auditing, notification, inspection, and transformation.This expands policy evaluation beyond binary authorization decisions.
  • Architectural implications: A centralized Policy Kernel enables common semantics across heterogeneous workloads while preserving organizational control over autonomous execution.Controls can be expressed centrally instead of embedded separately in each agent.
  • Limitations: Policy evaluation may increase latency, depends on complete policy definitions, and can be affected by mandatory provider failures; UPA also lacks complete formal verification of policy correctness.Large deployments may require distributed evaluation, explicit failure semantics, availability mechanisms, and observability.

11 Future Work

Future work extends UPA toward distributed, formally verifiable, adaptive, and increasingly autonomous-agent governance. The paper also calls for broader empirical evaluation while preserving explicit enterprise control and predictable governance semantics.

  • Distributed governance: Distributed Policy Kernel architectures are proposed for cross-region, cross-cloud, edge, and enterprise-boundary deployments.Open issues include policy synchronization, version consistency, distributed caching, failure handling, and decision consistency.
  • Formal verification: Formal verification of DGPL policies and compositions could identify contradictions, unreachable rules, unintended privileges, incomplete coverage, and unsafe combinations.Formal reasoning over PARC requests and evaluation semantics may strengthen governance-correctness guarantees.
  • Adaptive governance: Adaptive policies must respond to changing context while balancing adaptability with predictability, auditability, and deterministic governance semantics.The paper identifies runtime conditions, organizational risk, workload characteristics, and regulatory requirements as changing inputs.
  • Autonomous agents: Future agent-specific governance will address planning cycles, delegation, dynamic tool selection, agent-to-agent communication, and long-running workflows.A central challenge is preventing increased autonomy from bypassing enterprise governance controls.
  • Empirical evaluation: Broader evaluation will cover larger policy sets, additional domains, heterogeneous workloads, distributed execution, latency, overhead, scalability, and approval effectiveness.These studies are intended to provide further evidence about UPA's applicability in large-scale deployments.
  • Current foundation: UPA separates policy definition, normalization, matching, evaluation, and runtime governance while maintaining a consistent model across heterogeneous environments.The Policy Kernel produces decisions and obligations enforced through runtime components, human approval, and plugins.

A Reference DGPL Policies

The appendix illustrates DGPL policies and benchmark procedures, showing how declarative statements encode access, conditions, approvals, governance obligations, and provider-based controls. It also reports benchmark scope, accuracy, latency evaluation, and deployment caveats.

  • DGPL policy examples: DGPL examples encode PARC authorization together with conditions, approval workflows, evaluation providers, and governance obligations.The examples use JSON serialization and include policies for knowledge-base access, business hours, production deletion, protection, and threat detection.
  • Governance providers: Provider-based obligations can redact PII and secrets before processing, while threat-detection providers can inspect inputs for prompt injection and jailbreaks.These examples invoke privacy, secret-scanning, and LLM-based detection providers through policy statements.
  • Benchmark design: The benchmark evaluates policy matching, decision accuracy, taxonomy coverage, business-case complexity, human-approval escalation, and evaluation latency across seven enterprise domains.It contains 1,400 scenarios covering 70 business cases.
  • Benchmark results: 94.1% overall Policy Kernel accuracy is reported for the 1,400-scenario benchmark, alongside measurement of human-approval escalation across enterprise domains.The results provide an aggregate view of governance decision accuracy and explicit organizational intervention.
  • Complexity and latency: Benchmark results indicate coverage around the target business-case complexity rather than only simple policy decisions, while latency distributions expose runtime overhead by policy family.The latency analysis can identify policy families requiring optimization in large-scale deployments.
  • Interpretation and scope: Reported accuracy and latency are benchmark-condition results, not universal deployment guarantees, because performance varies with policies, requests, infrastructure, plugins, caching, and architecture.The benchmark is positioned as a reproducible basis for larger-policy, multi-domain, distributed, and autonomous-agent experiments.

B.8.1 Example: ERP High-Value Purchase Approval

The ERP example shows how UPA converts a high-value purchase request into an approval decision when a threshold condition is met. The workflow is suspended until the designated human approval completes, and boundary cases exercise approval-versus-denial behavior.

  • Policy definition: A purchase order above the defined threshold requires Finance Director approval under the ERP policy.The policy applies the Approve effect to purchase approval on purchase-order resources when purchase_amount exceeds 1,000,000.
  • Policy evaluation: For a purchase amount of 1,500,000, policy matching succeeds and the condition 1500000 > 1000000 resolves to True.The normalized request uses the purchase:approve action and purchase-order:PO-1024 resource.
  • Governance outcome: The Policy Kernel produces an explicit approval state, with obligations requiring the autonomous workflow to suspend until human approval completes.This makes organizational intervention part of runtime governance rather than a separate application behavior.
  • Benchmark cases: Five boundary scenarios test approval for amounts above the threshold and denial for amounts below or equal to it.The listed cases include 1,500,000, 2,500,000, and 5,000,000 as Approve, and 500,000 and 1,000,000 as Deny.
  • Operation identifiers: Operation identifiers use a namespace:operation convention and form the Action component of the PARC request model.The namespace identifies the domain, while the operation identifies the requested activity; identifiers remain extensible for domain-specific applications.

D DGPL Grammar Reference

The extended DGPL grammar reference broadens UPA governance from isolated operations to communication topology, provenance, and stateful runtime behavior. It also distinguishes proposed extensions from the core model and uses governance state to evaluate aggregate behavior.

  • Scope of extensions: The appendix presents multi-agent, provenance, and stateful constructs as proposed extensions rather than requirements for every UPA deployment.The appendix states that some extensions are future implementation directions rather than capabilities evaluated in the current benchmark.
  • Multi-agent governance: UPA introduces communication channels as first-class governed resources for multi-agent coordination.Channels include resources that one principal writes and another subsequently reads, including shared repositories, caches, directories, datasets, and workflow artifacts.
  • Multi-agent governance: Communication operations provide governance points for agent communication, delegation, discovery, and control transfer.The model distinguishes authorization of an individual operation from governance of the communication topology through which agents interact.
  • Provenance governance: Provenance-aware evaluation distinguishes trusted enterprise-issued credentials from credentials discovered through shared workspaces or other agents.The extension treats credential possession as insufficient evidence of trust for subsequent use.
  • Stateful governance: The extended evaluation model introduces bounded governance state Σ, producing a policy decision and updated state from the request, policy, facts, and prior state.State should be bounded, auditable, versioned, and appropriately scoped; reproducibility is characterized as replay determinism when state is retained as an auditable input.
  • Stateful governance: State-aware policies can make aggregate behavior a governance condition even when each individual operation appears permissible.Examples include cross-principal resource access, repeated task failures, cumulative reasoning tokens, and out-of-scope probing.

E.5 Mediation Completeness

Mediation completeness defines the boundary of UPA guarantees: governed operations must reach a Governance Enforcement Point. The section also distinguishes authoritative runtime enforcement from pre-flight and offline analysis modalities.

  • Mediation Completeness: UPA governance guarantees apply only to operations mediated by a Governance Enforcement Point.The policy engine cannot govern an operation that never reaches the enforcement surface.
  • Mediation Completeness: Deployments should audit every path through which governed workloads can affect state outside their declared boundary.This unmediated-path audit provides a deployment-level coverage criterion for governance enforcement.
  • Trusted governance component: The Policy Kernel is treated as a trusted governance component whose semantics and evidence stores require isolation and tamper-evident controls.Recommended constraints include restricting workload access, append-only evidence, and fail-closed handling for security-critical obligation failures.
  • Enforcement modalities: The primary architecture places the Policy Kernel at Governance Enforcement Points, where it provides the authoritative governance decision for execution.Agents and applications invoke governed operations without requiring direct knowledge of internal policy implementation.
  • Enforcement modalities: Pre-flight evaluation exposes governance constraints to planners but is not an authorization credential or substitute for enforcement.Pre-flight requests should be rate-limited and should avoid exposing unnecessary policy internals because of policy-probing risk.
  • Offline assurance: Offline replay evaluates historical event streams to identify hypothetical denials, approvals, obligations, coverage gaps, and unmediated paths.It supports counterfactual analysis and continuous red-team evaluation without modifying the original execution.
  • Domain governance: Governance-aware dispute-management harnesses can encode procedural controls as runtime constraints.Examples include randomized non-intervention samples, role separation, fairness and capacity constraints, deterministic artifacts, and append-only execution ledgers.

E.9 Extended Financial Crime Policy Pack

The extended financial-crime and dispute-management policy pack applies UPA beyond authorization to evidence, label provenance, sampling, maturity gates, privacy, fairness, capacity, and human approval. The section also frames several benchmark and governance features as proposed extensions requiring validation.

  • Financial Crime / Dispute Management policy pack: The policy pack associates autonomous financial-crime decisions with evidence, label provenance, exploration reserves, and maturity gates.These obligations record evaluation context, distinguish intervention-related unobservability, preserve randomized non-intervention samples, and gate retraining or promotion until outcomes mature.
  • Policy obligations: UPA policy packs encode governance controls beyond conventional access authorization.The examples include feature-leakage prevention, privacy transformations for LLM inputs, and evidence-generation obligations.
  • Policy obligations: Permitted LLM input operations can carry mandatory redaction, tokenization, and audit-logging obligations.The illustrative privacy policy attaches Presidio redaction, pseudonymization, and audit recording to llm:input.
  • Policy obligations: Fairness, segment performance, and operational alert-rate conditions can constrain detection-artifact promotion and policy publication.The illustrative thresholds are not universal regulatory or operational thresholds.
  • Human approval: The Approve effect requires human authorization and is distinct from an ordinary Allow decision.The illustrative promotion policy assigns approval to a ModelRiskValidator and adds model-card and integrity-verification providers.
  • Benchmark extensions: Proposed benchmark extensions include channel-formation detection latency, credential-reuse denial, and provenance-policy interception metrics.These metrics require independent implementation and experimental validation before being treated as empirical benchmark results.
  • Incident replay: Counterfactual replay can evaluate incident events for hypothetical denials, approvals, obligations, provenance deficiencies, unmediated operations, and state-triggered escalation.The paper cautions that replay does not establish that UPA would have prevented the original incident.
  • Scope and limitations: The extensions should be viewed as an extensibility demonstration rather than proof that every capability is implemented or empirically validated.UPA is also not presented as a complete substitute for host security, identity infrastructure, network isolation, runtime sandboxing, or independent security controls.
Loading 2609.06543v1…