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

Enterprise AI agents create a governance gap because existing mechanisms address authorization, safety, identity, or collaboration separately rather than as one continuously enforced system. UPA introduces a declarative Policy Kernel that mediates governance throughout execution, with evaluation showing 100% policy-test correctness and sub-3.2 ms median latency through 1,000 policies.

  • Problem

    Existing enterprise AI governance mechanisms lack a unified abstraction for continuously enforcing policies across heterogeneous autonomous systems.

    Source: §3 · p. 6

  • Method

    UPA externalizes governance into a declarative Policy Kernel that continuously mediates agents, resources, tools, memory, workflows, and policies before, during, and after execution.

    Source: §4.4 · p. 8, §4.3 · p. 8

  • Results

    The Policy Engine achieved a 100% pass rate (9/9 test cases), with sub-3.2 ms median latency through 1,000 policies before reaching 17.2 ms at 5,000 policies.

    Source: • Correctness · p. 38

  • Takeaways & Limitations

    UPA provides a policy-centric governance architecture for enforcing enterprise AI policies across autonomous execution and related enterprise interactions.

    Source: §1 · p. 2, §4.4 · p. 8

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

    Source: §10.4 · p. 39

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 … 4 Unified Policy Architecture (UPA)

This section introduces UPA as a platform-independent Policy Kernel for lifecycle-wide governance of autonomous AI in Enterprise AI Operating Systems. It presents declarative policy evaluation, Runtime Governance, ordered obligations, human approvals, and extensible plugins as coordinated mechanisms for governing heterogeneous environments while separating governance logic from execution.

1 Introduction

  • UPA treats autonomous enterprise AI governance as a systems-architecture challenge requiring unified, lifecycle-wide control beyond authorization, model safety, and guardrails.Autonomous agents dynamically plan, select tools, access memory, execute workflows, and collaborate, so governance must cover authorization, compliance, approvals, auditability, business rules, and multi-agent interactions.Source: §1 · p. 2, §3 · p. 6
  • UPA introduces a declarative Policy Kernel that unifies authorization, runtime governance, compliance, auditability, approvals, business rules, and multi-agent governance across heterogeneous AI systems.Semantic Normalization maps heterogeneous runtime events to a canonical policy representation, while provider plugins separate evaluation functions from obligations without modifying the core kernel.Source: §1 · p. 2, §2.6 · p. 5

2.1 Policy-Based Access Control

  • Existing access-control, Cedar, and AI-safety mechanisms provide important foundations but generally govern deterministic permissions or model interactions rather than autonomous execution across memory, tools, workflows, and agents.UPA builds on Cedar’s declarative policy principles while extending governance with semantic normalization, obligations, compliance verification, approval workflows, evidence, audit, and industry policy packs.Source: §2.1 · p. 3, §2.2 · p. 3, §2.3 · p. 3

2.4 Enterprise Identity and Zero Trust

  • Zero Trust supplies an identity-centric foundation, whereas UPA adds policy-centric runtime governance for the complete lifecycle of autonomous AI execution.UPA governs not only authenticated access but also tools, policies, compliance obligations, approvals, evidence, audit logging, and multi-agent enforcement.Source: §2.4 · pp. 4–5

2.5 Governance-First AI Architectures

  • Governance-first architectures such as Arbiter-K demonstrate deterministic execution control, but UPA targets the broader enterprise requirements of authorization, compliance, approvals, auditability, industry policies, and heterogeneous integrations.The section also notes runtime-governance work emphasizing stateful governance, composite principals, capability attenuation, interruption, and structured audit evidence.Source: §2.5 · p. 5, §4.1 · p. 7

2.6 Multi-Agent Systems

  • Unlike multi-agent frameworks that prioritize intelligence and orchestration, UPA externalizes governance into a declarative layer independent of the underlying model provider, agent framework, or execution environment.This enables consistent regulation of authorization, tool use, memory, workflows, compliance, approvals, auditing, and inter-agent interactions across heterogeneous systems.Source: §2.6 · p. 5

2.7 Positioning of DGPL and UPA

  • UPA and DGPL combine previously separate access control, safety, identity, and agent capabilities through a common policy layer that treats authorization as one part of a larger governance lifecycle.Policy evaluation can yield both a decision and obligations such as plugin execution, human approval, audit generation, notification, and compliance validation, while preserving existing component implementations.Source: §2.7 · pp. 5–6

3 Problem Statement & Research Gap

  • The identified research gap is a portable policy kernel for Enterprise AI Operating Systems, where continuous governance coordinates heterogeneous agents, models, tools, memories, workflows, enterprise services, and regulated data.The section attributes the gap to fragmented controls, framework dependence, limited runtime coverage, code-embedded compliance, and lack of standardization.Source: §3 · p. 7

4.1 Relationship to Existing Governance Architectures

  • UPA unifies authorization, runtime governance, compliance, approvals, audit evidence, plugins, policy packs, and multi-agent governance within a platform-independent Policy Kernel.It targets heterogeneous LLMs, agent frameworks, applications, workflows, and organizational domains.Source: §4.1 · p. 7

4.2 Design Principles

  • UPA externalizes governance from applications into a unified Policy Kernel that continuously governs autonomous AI execution throughout its lifecycle.The design addresses fragmented enforcement across heterogeneous execution environments by separating governance from application logic.Source: §4.2 · pp. 7–8

4.3 Architectural Overview

  • UPA comprises the Policy Kernel, Governance Services, and AI Runtime Integration Layer, enforcing policies across agents, models, memory, tools, workflows, and enterprise applications.The layers support canonical event handling, compliance, approvals, evidence generation, and industry-specific policy packs.Source: §4.3 · p. 8

4.4 UPA Policy Kernel

  • The Policy Kernel mediates interactions through semantic normalization, policy evaluation, runtime governance, and plugin orchestration before, during, and after autonomous execution.It delegates computational work to execution systems while keeping governance decisions declarative, reusable, and independent of application implementations.Source: §4.4 · p. 8, §4.3 · p. 8

4.4.1 Semantic Normalization

  • Semantic Normalization transforms heterogeneous runtime events into canonical policy requests, providing framework-independent inputs for governance across AI runtimes.Events include requests, agent actions, workflow events, API invocations, memory operations, tool executions, and inter-agent communications.Source: §4.4.1 · p. 9

4.4.2 Policy Evaluation

  • Policy Evaluation returns Allow, Deny, or first-class Approve decisions alongside obligations such as plugins, compliance checks, audit logging, evidence generation, and notifications.Approve suspends execution for human authorization, while obligations define runtime actions separately from the decision.Source: §4.4.2 · p. 10

4.4.3 Governance Provider Framework

  • The Governance Provider Framework separates Evaluation Providers from Obligation Providers, enabling extensible threat detection, risk scoring, compliance, privacy, redaction, and evidence capabilities without changing the kernel.Providers can support deterministic signatures, semantic LLM-based detection, or hybrid evaluation while preserving a common declarative model.Source: §4.4.3 · pp. 10–11

4.4.4 Runtime Governance

  • Runtime Governance continuously coordinates decisions and obligations across the execution lifecycle, producing executed, blocked, or failed outcomes as enforcement succeeds or mandatory obligations fail.Obligations may trigger before execution, during workflow stages, or after completion.Source: §4.4.4 · p. 12
  • Runtime Governance coordinates plugin execution, audit logging, compliance verification, approvals, evidence generation, and enforcement after policy evaluation produces obligations.This separation keeps the Policy Kernel declarative while supporting complex governance workflows across autonomous agents, tools, memory, workflows, and enterprise resources.Source: §4.4.4 · p. 12

4.5 Plugin Framework; 4.5.2 Plugin Obligations

  • UPA resolves and executes governance plugins declaratively through policy-generated obligations, allowing new governance functions without modifying the Policy Kernel, DGPL model, or evaluation semantics.A single policy decision can produce multiple ordered plugin obligations while keeping governance behavior externalized from application implementations.Source: §4.5 · pp. 12–13, §4.5.2 · p. 13

4.5.1 Governance Plugin Contract; 4.5.5 Plugin Result

  • The standardized asynchronous plugin contract supplies the canonical request, runtime context, and policy configuration, establishing a stable boundary for local processing, external services, models, or enterprise-system access.Plugin results report execution success, whether the context was transformed, provider-specific findings or evidence, and optional diagnostics.Source: §4.5.1 · p. 13, §4.5.5 · p. 14

4.5.3 Plugin Registry; 4.5.4 Plugin Execution Model

  • The registry separates declarative provider identifiers from concrete implementations, so different implementations of the same governance capability can be introduced without changing policy representations.During execution, applicable providers process the runtime context sequentially; plugins may observe it for inspection and evidence generation or transform it before later stages.Source: §4.5.3 · p. 13, §4.5.4 · pp. 13–14

4.5.6 Reference Plugin: Privacy Protection; 4.5.7 Reference Plugin: Secret Scanner

  • Reference providers demonstrate privacy and secret governance through detection or redaction, while deterministic local scanning participates through the same standardized plugin contract without external services or machine learning models.Presidio identifies and anonymizes sensitive prompt entities; Secret Scanner detects credentials such as cloud keys, API keys, repository tokens, and JSON Web Tokens and can replace them with typed placeholders.Source: §4.5.6 · p. 14, §4.5.7 · pp. 14–15

4.5.8 Plugin Extensibility; 4.5.9 Plugin and Evaluation Provider Separation

  • The open-ended framework supports detection, validation, transformation, enforcement, evidence generation, verification, and organization-specific controls, while separating evaluation providers from enforcement plugins to prevent tight coupling in the Policy Kernel.Evaluation providers contribute evidence or attributes for policy evaluation; governance plugins execute obligations produced by that evaluation.Source: §4.5.8 · p. 15, §4.5.9 · p. 15

4.5.10 Declarative Plugin Execution Example

  • UPA declares governance requirements in policy, resolves implementations through the Plugin Registry, and enforces them through Runtime Governance rather than application code.The Runtime Governance subsystem executes the Presidio redaction and Secret Scanner plugins against the runtime context.Source: §4.5.10 · p. 16
  • The architecture lets governance capabilities evolve independently from the applications and AI models that consume them.Source: §4.5.10 · p. 16

5 Formal Mathematical Foundation

Section 5 formalizes UPA as a platform-independent sequence of deterministic transformations from heterogeneous runtime events to governed execution outcomes. Its foundation separates event normalization, policy evaluation, governance obligations, and runtime enforcement across heterogeneous Enterprise AI Operating Systems.

5 Formal Mathematical Foundation

  • The formal foundation establishes a common semantic basis for normalization, policy evaluation, governance obligations, runtime enforcement, and provider-based extensibility across heterogeneous Enterprise AI Operating Systems.It is designed as a platform-independent mathematical model for transforming heterogeneous runtime events into governed execution outcomes.Source: §5 · p. 16

5.1 Governance Execution Model

  • UPA models governance as a continuous runtime process that transforms heterogeneous events into governed outcomes through normalization, policy evaluation, obligations, and enforcement.This extends governance beyond one-time access authorization and remains independent of specific AI frameworks, orchestration platforms, and enterprise applications.Source: §5.1 · pp. 16–17
  • The governance pipeline normalizes each event, evaluates applicable policies with provider-enriched attributes, returns a decision and ordered obligations, then enforces them to produce the runtime outcome.The decision space includes Allow, Deny, and Approve, while outcomes include Executed, Blocked, PendingApproval, and Failed.Source: §5.1 · pp. 16–17

5.2 Runtime Event Model

  • UPA represents execution requests as runtime events spanning users, agents, workflows, memory, tools, APIs, and inter-agent communications, with source, operation, resource, context, and metadata.The context includes principal, environment, session, tenant, and timestamp; metadata supports observability, auditing, and governance evidence.Source: §5.2 · p. 17

5.3 Semantic Normalization Function

  • Semantic Normalization maps every heterogeneous runtime event to exactly one canonical policy request, enabling deterministic evaluation independent of the originating execution framework.The canonical request captures Principal, Action, Resource, and Context (PARC), while providers can add contextual attributes without changing the normalized representation.Source: §5.3 · pp. 17–18
  • Normalization separates runtime-event interpretation from policy evaluation, keeping governance policies independent of agent frameworks, orchestration platforms, programming languages, deployment models, and model providers.This abstraction allows one policy model to govern heterogeneous Enterprise AI Operating Systems without framework-specific policy definitions.Source: §5.3 · pp. 17–18

5.4 Policy Evaluation Function

  • Policy Evaluation processes canonical requests against a repository of declarative policies and Evaluation Providers, incorporating dynamic attributes, deterministic conflict resolution, and ordered governance obligations.Formally, Eval(p, Π, Φ) = (d, Γ) for p ∈P.Source: §5.4 · p. 18

1. Policy Matching … 4. Governance Decision Generation

UPA evaluates all policies applicable to a canonical request, enriches evaluation with pluggable runtime attributes, and resolves resulting governance decisions through a deterministic process. This architecture supports compositional governance while allowing new runtime evaluation capabilities without changing the Policy Kernel or existing policy semantics.

5.4.1 Policy Matching

  • UPA’s Policy Matching function maps a canonical policy request to the complete set of policy statements whose conditions are satisfied.The matched set is represented as M = {s_1, s_2, . . . , s_n}.Source: §5.4.1 · p. 18
  • Unlike first-match authorization, UPA evaluates all applicable statements to support policy composition, layered governance, compliance verification, and organizational policy inheritance.Source: §5.4.1 · p. 18

5.4.2 Evaluation Providers

  • UPA uses Evaluation Providers to compute runtime governance attributes such as threat assessments, semantic classifications, risk scores, and contextual attributes during policy evaluation.The providers form a collection Φ = {ϕ_1, ϕ_2, . . . , ϕ_n}, with each provider producing a set of governance attributes A_i.Source: §5.4.2 · p. 18
  • For a canonical request, collective provider output supplies the complete set of governance attributes available to policy evaluation.Source: §5.4.2 · p. 18
  • Separating runtime attribute generation from declarative policy evaluation lets organizations add evaluation capabilities without modifying the Policy Kernel or existing policy semantics.Source: §5.4.2 · p. 18

5.4.3 Conflict Resolution

  • When multiple matched policies express different governance decisions or runtime obligations, UPA applies a formally defined conflict-resolution process using deterministic precedence.The conflict-resolution input is the matched policy set M = {s_1, s_2, . . . , s_n}.Source: §5.4.3 · pp. 18–19

1. Policy Priority … 6 Declarative Governance Policy Language

This section defines UPA’s declarative governance model and policy language for expressing and evaluating authorization, safety, compliance, threat detection, runtime controls, and human approvals. It specifies deterministic decisions, obligations, conditions, plugins, approval workflows, policy composition and conflict resolution, and illustrates governance logic independently of application implementations.

5.4.4 Governance Decision

  • Policy evaluation returns Allow, Deny, or Approve, with Approve suspending execution until explicit organizational approval completes.Allow requires all applicable governance conditions; Deny applies when mandatory policies prohibit execution.Source: §5.4.4 · p. 19, §6.2 · p. 21

5.5 Runtime Governance Function

  • Runtime Governance enforces the decision and ordered obligations, executing only when Allow obligations succeed, terminating on Deny, suspending on Approve, and failing when mandatory obligations cannot complete.Obligations can include plugin execution, audit logging, compliance verification, evidence generation, notifications, and workflow metadata, and run after the decision is determined.Source: §5.5 · p. 19, §5.4.5 · p. 19

5.6 Properties of the Governance Model

  • The governance model guarantees deterministic normalization and evaluation, consistent conflict resolution, complete decisions, framework independence, and extensibility through providers and plugins.Equivalent requests and policy repositories produce the same decision and obligations, while extensions can change without modifying the Policy Kernel or existing semantics.Source: §5.6 · pp. 19–20

4. Policy Version

  • Policy conflicts resolve deterministically by Priority > Effect > Specificity > Version, with Deny > Approve > Allow and version considered last.Higher priority takes precedence; specificity is used when multiple policies remain applicable after earlier precedence rules.Source: §5.6 · p. 19, §4 · p. 19

6 Declarative Governance Policy Language

  • DGPL is a platform-independent declarative language that unifies authorization, AI safety, runtime governance, threat detection, obligations, human approvals, and enterprise-specific governance.Policies specify desired governance outcomes rather than procedural logic, can be serialized as JSON or YAML, and preserve shared underlying semantics across formats.Source: §6 · p. 20

6.1 Policy Document Model

  • DGPL organizes governance as composable statements using the Principal–Action–Resource–Context model, while extensions add threat detection, plugins, approval workflows, and organization-specific controls.Principals may be agents or infrastructure identities; actions cover operations such as LLM and memory access; resources identify enterprise assets; context supplies runtime predicates.Source: §6.1 · p. 20, §6.2 · p. 21, §6.3 · p. 21

6.4 Governance Extensions

  • DGPL Governance Extensions augment PARC without modifying its fundamental policy structure, expressing contextual constraints, runtime obligations, human approvals, and organization-specific capabilities.These extensions provide governance mechanisms beyond traditional access control.Source: §6.4 · p. 22

6.4.2 Threat Detection

  • Threat Detection contributes runtime security evidence to policy evaluation through deterministic static detectors and semantic LLM-based detectors for attacks such as prompt injection and jailbreaks.Static detectors match locally maintained signatures with low latency, while LLM-based detectors target threats not reliably captured by signatures.Source: §6.4.2 · p. 23

6.4.3 Governance Plugins

  • Governance Plugins execute policy-produced obligations through an open extension boundary, supporting reference capabilities such as Presidio and Secret Scanner without modifying the Policy Kernel or DGPL.Future plugins may support compliance, audit evidence, escalation, data residency, quotas, and organization-specific controls.Source: §6.4.3 · pp. 23–24

6.4.4 Approval Workflows

  • DGPL’s first-class Approve effect suspends autonomous execution and initiates human approval workflows for high-risk operations such as production changes and privileged administration.The mechanism is also applicable to financial transactions and other high-risk enterprise activities.Source: §6.4.4 · p. 24

6.5 Policy Composition and Conflict Resolution

  • Policy composition evaluates all matching statements collectively, allowing authorization, security, runtime governance, and compliance requirements to participate independently in one request.The Policy Kernel does not stop after the first match; resulting obligations are enforced by Runtime Governance.Source: §6.5 · p. 24, §6.5.3 · p. 25

6.5.2 Conflict Resolution

  • DGPL resolves conflicting effects deterministically as Deny > Approve > Allow, while more specific resource, action, or principal constraints outrank broader wildcard policies.Separating composition from conflict resolution preserves a single governance decision across independent policies.Source: §6.5.2 · p. 24

6.5.3 Default Deny

  • DGPL adopts default deny, permitting autonomous execution only when an applicable governance policy explicitly authorizes the canonical request.Only statements whose PARC attributes and conditions match participate in subsequent governance evaluation.Source: §6.5.3 · pp. 24–25, §6.5.1 · p. 24

6.6 Expression Semantics

  • DGPL expression semantics evaluate declarative predicates from facts drawn from requests, runtime or enterprise context, and Evaluation Providers using primitive fact-operator-value expressions.The framework defines facts and primitive boolean evaluation independently of concrete JSON or YAML representation, including a between operator.Source: §6.6 · p. 25, §6.6.1 · p. 25, §6.6.2 · p. 25

6.6.3 Between Operator

  • The between operator evaluates whether a runtime fact, such as system.hour, falls within a declared interval.The illustrated interval is [9, 17].Source: §6.6.3 · p. 25

6.6.4 Logical Expressions

  • DGPL supports logical composition through all and any expressions, allowing multiple runtime conditions to be declared without procedural control flow.These expressions provide declarative composition of runtime conditions.Source: §6.6.4 · p. 25

6.6.5 Condition Evaluation

  • A condition contributes to policy applicability when Eval(c, C) = true, while statements without conditions are satisfied by default.Applicability combines request matching with condition evaluation: Applicable(S, p) = PARCMatch(S, p)∧Eval(ConditionS, C).Source: §6.6.5 · p. 26, §6.7.2 · p. 26

6.7.2 Human Approval Policy

  • DGPL can require explicit approval for high-risk database operations through an Approve effect targeting actions such as db:delete.The example defines a ProductionDelete statement and evaluates its applicability using request matching and conditions.Source: §6.7.2 · p. 26

6.7 Reference Policy Examples

  • DGPL composes PARC semantics with Governance Extensions to express authorization, conditions, threat detection, runtime obligations, and human approval in one policy language.The reference examples include basic authorization, temporal conditions, static or LLM-based evaluation providers, privacy and secret-detection plugins, approval effects, and multi-statement policies.Source: §6.7 · p. 26

6.7.1 Business Hours Policy

  • Business-hours policies restrict production database access to a declared time window and associate the operation with an Admin approval role.The example uses system.hour between for database:production and specifies the Admin role.Source: §6.7.1 · p. 26

6.7.3 Runtime Protection Policy

  • Runtime protection policies invoke declarative plugins to redact sensitive information from LLM inputs using Presidio and a secret scanner.Both providers are configured with mode set to redact.Source: §6.7.3 · p. 26

6.7.4 Threat Detection Policy

  • Threat policies can deny LLM requests when an LLM evaluator detects prompt injection or jailbreaks above a 0.80 threshold, with Deny taking precedence over Allow.The example uses gemini/gemini-2.5-flash and applies the configured threat result during policy evaluation.Source: §6.7.4 · pp. 26–27

7 Industry Policy Packs

This section presents Industry Policy Packs as reusable, composable DGPL governance for domain-specific requirements, integrated with UPA’s common policy kernel, runtime mechanisms, evaluation semantics, approval mechanisms, and provider framework. It shows how these packs support contextual authorization, runtime obligations, autonomous action, human control over high-impact decisions, and shared threat evidence across industries.

7.1 Industry Policy Pack Model

  • Industry Policy Packs address fragmented, duplicated, and inconsistently enforced controls by supplying reusable, versioned DGPL statements for particular governance domains.Packs can include authorization rules, contextual conditions, governance obligations, approval requirements, and provider bindings.Source: §7.1 · p. 27

7.2 Formal Definition

  • Packs are incorporated into the existing policy repository and evaluated by the same Policy Kernel, enabling multiple domains to coexist without an industry-specific evaluation path.The Kernel does not distinguish internally authored policies from pack-originated statements, and packs can evolve independently through versioning.Source: §7.1 · p. 27, §7.2 · pp. 27–28

7.3 Anatomy of an Industry Policy Pack

  • A pack combines PARC authorization statements, runtime conditions, governance obligations, provider bindings, and Approve effects, while accompanying regulatory documentation remains outside core DGPL evaluation semantics.This separation keeps evaluation implementation-independent while supporting enterprise governance and audit documentation.Source: §7.3 · p. 28

7.4 Policy Packs for Key Industries

  • Across industries, policy packs differ mainly in their domain-specific principals, actions, resources, conditions, effects, and obligations rather than in their evaluation mechanism, and importing one alone does not constitute compliance certification.The same underlying DGPL mechanisms remain applicable across domains.Source: §7.4 · p. 28

7.5.1 Healthcare — Patient Record Access

  • Healthcare packs can authorize care-team patient-record access only when authentication and treatment-relationship conditions hold, with auditing obligations and default denial otherwise.If either contextual condition is false and no other policy authorizes the request, the default-deny rule applies.Source: §7.5.1 · p. 29

7.5.2 Cross-Industry — LLM Input Protection

  • Cross-industry protections can redact sensitive information before LLM input through runtime obligations, while banking and industrial packs preserve lower-risk autonomy but require designated human approval at irreversible decision boundaries.Banking suspends execution for permanent rejection or account blocking, while oil-and-gas workflows allow validated emergency stopping but require approval before restart.Source: §7.5.2 · pp. 29–30, §7.5.3 · p. 30

7.6 Human Approval Within Industry Policy Packs

  • Human approval separates agent initiation from organizational authorization, allowing low-risk reversible operations while retaining human control over high-impact decisions.Approval leads to continued execution, rejection to termination, and timeout to termination or hold according to governance configuration.Source: §7.6 · p. 31

7.7 Composition of Industry Policy Packs

  • Multiple Industry Policy Packs and organization-specific policies are evaluated through one canonical request against all applicable statements before evaluation providers and conflict resolution.A healthcare payment may simultaneously invoke healthcare, finance, organizational approval, and cross-industry protection policies.Source: §7.7 · p. 31

7.8 Threat-Aware Governance Within Industry Policy Packs

  • Threat-aware packs invoke shared Evaluation Providers for threat evidence, separating threat-detection implementation from domain-specific governance policy.The same prompt-injection detector can support multiple industries while each pack determines the resulting governance action.Source: §7.8 · pp. 31–32

7.10 Summary

  • Industry Policy Packs provide policy reuse, consistent enforcement, composability, versionability, extensibility, and operational separation across applications and agents.They let domains such as Healthcare, Banking, and Oil and Gas define different requirements while sharing the underlying governance model and frameworks.Source: §7.9 · p. 32, §7.10 · p. 32

7.9 Benefits of Industry Policy Packs

  • Industry Policy Packs extend the policy repository rather than the evaluation architecture, enabling reusable domain-specific governance without specialized enforcement logic.They use ordinary DGPL statements evaluated by the same Policy Kernel.Source: §7.9 · p. 32, §7.10 · p. 32

8 SID Registry, Indexing, and Resolution

UPA uses stable Statement Identifiers (SIDs) to identify DGPL policy statements and connect evaluated decisions to their policy origins. Indexing narrows candidate statements for efficient retrieval, while registry-based resolution preserves semantic identity and supports traceability without affecting policy matching.

8.1 DGPL Policy Statements

  • Stable SIDs identify DGPL policy statements and let evaluations, obligations, audit records, and administrative operations reference their originating statements.A SID identifies a statement but does not determine whether it matches a request; matching uses applicable policy attributes.Source: §8.1 · p. 32

8.1.1 SID Registry

  • The SID Registry maps each identifier to its DGPL statement, enabling origin resolution without coupling policy evaluation to physical policy storage.The registry provides the Policy Kernel and governance components with a stable reference to the evaluated statement.Source: §8.1.1 · pp. 32–33

Policy Indexing

  • Indexing reduces policy-matching work by selecting a candidate subset Pq of the complete policy set P for each normalized PARC request.Candidate retrieval may use policy attributes, but final applicability remains the responsibility of policy matching and evaluation.Source: Policy Indexing · p. 33

SID Resolution

  • After evaluation, the Policy Kernel resolves the SIDs of statements matching the normalized request and associates them with the resulting decision.This creates a direct relationship between runtime decisions and contributing policy statements while keeping SIDs separate from policy requests and evaluation objects.Source: SID Resolution · p. 33

Resolution Flow

  • Resolution lets governance decisions reference statement SIDs for auditability, explanation, approval workflows, and evidence, while indexing and registry lookup remain complementary responsibilities.Indexing optimizes candidate retrieval; the registry preserves stable statement identity without changing DGPL policy semantics.Source: Resolution Flow · pp. 33–34

9 Experimental Evaluation

The UPA prototype establishes preliminary baselines across correctness, latency, scalability, concurrency, plugin overhead, and semantic normalization. Results show reliable policy decisions and concurrent execution, while sequential traversal and deep NLP plugins create performance costs.

9.1 Correctness

  • All nine structured correctness cases returned the expected decisions, with precedence resolved as Deny > Approve > Allow > Default Deny.The engine also verified mismatches, default denial, human approval, and conflict resolution.Source: §9.1 · p. 34, Evaluation Result · pp. 34–35

9.2 Latency / 9.3 Policy Repository Scalability

9.4 Concurrent Request Scalability

  • Across concurrency levels, 1,860 authorization requests completed successfully without failures; throughput peaked at 237.96 requests per second at concurrency 50 and stayed near that level at 100.The test fixed the repository at 1,000 policies and used in-process asyncio execution.Source: §9.4 · p. 35

9.5 Plugin Execution Overhead

  • The secret scanner added only 0.0092 ms mean overhead, whereas Presidio added approximately 2,398.54 ms and dominated runtime.Plugin measurements are preliminary because warm-up, caching, dependency initialization, and test order may influence results.Source: Representative Plugin Policy · p. 36, • Correctness · p. 38

9.6 Interoperability and Semantic Normalization

  • Semantic Normalization converted a natural-language request into the expected canonical principal-action-resource representation while preserving the authenticated principal.The LLM receives only the user query, while trusted identity and execution metadata are bound independently by the application runtime; broader labelled testing remains necessary.Source: Generated Canonical Authorization… · p. 37, §9.6 · p. 37

9.7 Summary of Findings

  • The engine achieved 100% correctness (9/9 test cases), processed 1,860 concurrent requests with zero failures at a peak ≈238 req/s, and translated natural-language queries into canonical tuples.Source: • Correctness · p. 38

10 Discussion

UPA frames Enterprise AI governance as a coordinated runtime control plane spanning policy evaluation, enforcement, human intervention, and extensible governance capabilities. It supports consistent control across heterogeneous autonomous systems while remaining complementary to existing policy engines and guardrails, with important operational and formal-verification limitations.

10 Discussion

  • UPA models Enterprise AI governance as a coordinated control plane for policy evaluation, runtime governance, human intervention, and governance extensions.The architecture targets autonomous agents and LLM applications rather than treating governance solely as model-level safety.Source: §10 · p. 38

10.1 Strengths

  • UPA separates policy definition, evaluation, and execution through DGPL and the Policy Kernel, enabling implementation-independent rules and common PARC-based matching.Governance outcomes include Allow, Deny, Approve, and obligations such as approval, auditing, notification, inspection, and transformation.Source: §10.1 · pp. 38–39

10.2 Architectural Implications

  • UPA centralizes governance semantics across heterogeneous workloads while preserving enterprise authority over autonomous agent reasoning and tool execution.Controls can be expressed through a common policy model and enforced through a shared Policy Kernel rather than embedded separately in applications.Source: §10.2 · p. 39

10.3 Relationship to Existing Approaches

  • UPA extends existing policy engines and AI guardrails with runtime obligations, human approval, AI-specific controls, and plugins rather than replacing them.Traditional safety mechanisms can be invoked as governance obligations associated with enterprise policies.Source: §10.3 · p. 39

10.4 Limitations

  • UPA may increase runtime latency, depends on complete policies and available mandatory plugins, and lacks a complete formal-verification framework for policy correctness and conflicts.Production deployments therefore require optimization, distributed evaluation where needed, explicit failure semantics, availability mechanisms, and governance observability.Source: §10.4 · p. 39

10.5 Overall Discussion

  • UPA provides a foundation for systematic, extensible governance spanning normalization, policy matching, decision evaluation, obligations, enforcement, and human intervention across heterogeneous Enterprise AI environments.This governance layer avoids coupling control logic directly to individual models or applications.Source: §10.5 · p. 39

11 Future Work · 12 Conclusion

UPA provides lifecycle-wide, control-plane governance for autonomous AI by unifying policy definition, evaluation, enforcement, and runtime obligations across heterogeneous enterprise environments. Future work extends this foundation toward distributed, formally verified, adaptive, scalable, and self-governing-agent governance.

11.1 Distributed Policy Kernels

  • Distributed Policy Kernels will support policy evaluation across regions, clouds, edge environments, and enterprise boundaries while preserving consistent policy semantics.Research must address synchronization, version consistency, distributed caching, failure handling, and decision consistency across geographically distributed runtimes.Source: §11.1 · p. 40

11.2 Formal Policy Verification

  • Formal verification of DGPL policies and compositions could detect contradictions, unreachable rules, unintended privileges, incomplete coverage, and unsafe combinations before deployment.Formal reasoning over PARC requests and evaluation semantics may provide stronger guarantees of governance correctness.Source: §11.2 · p. 40

11.3 Adaptive Governance Policies

  • Adaptive governance policies will respond to runtime, organizational, workload, and regulatory changes while preserving explicit control, predictability, auditability, and deterministic semantics.The central challenge is balancing adaptability with predictable and auditable governance.Source: §11.3 · p. 40

11.4 Governance for Self-Governing Agents

  • Governance for self-governing agents must cover planning cycles, delegation, dynamic tool selection, agent communication, and long-running workflows without bypassing enterprise controls.The need arises as agents increasingly perform planning, reasoning, tool selection, and multi-step execution.Source: §11.4 · p. 40

11.5 Large-Scale Empirical Evaluation

  • Large-scale evaluation will test UPA across larger policy sets, enterprise domains, heterogeneous workloads, and distributed execution environments.Measures include policy-matching accuracy, latency, governance overhead, plugin execution cost, scalability, and human-approval effectiveness.Source: §11.5 · p. 40

12 Conclusion

  • UPA governs autonomous agents and LLM applications throughout the runtime lifecycle while separating governance from individual applications and models.This separation lets organizations evolve governance requirements without changing every agent or application.Source: §12 · p. 40
  • DGPL, PARC, and the Policy Kernel provide structured policy expression, normalized evaluation requests, governance decisions, obligations, and extensible runtime enforcement.Decisions and obligations can be enforced through runtime components, human approvals, and plugins.Source: §12 · p. 40
  • UPA enables autonomy and organizational control to coexist, providing a foundation for Enterprise AI systems and motivating extensions toward increasingly autonomous agents.The conclusion identifies distributed evaluation, formal verification, adaptive governance, and self-governing-agent mechanisms as future extensions.Source: §12 · p. 40

A Reference DGPL Policies … B.8 Benchmark Interpretation

The appendix illustrates DGPL’s unified governance capabilities through JSON policy examples, then evaluates the Policy Kernel on a 1,400-scenario enterprise benchmark. The benchmark reports 94.1% overall accuracy while emphasizing that results are conditional on defined benchmark and deployment conditions.

A Reference DGPL Policies; A.6 Multi-Statement Policy

  • DGPL examples use JSON serialization to demonstrate PARC authorization, conditions, approvals, governance obligations, threat detection, and multiple independent policy statements.The examples cover representative enterprise governance mechanisms rather than authorization alone.Source: A Reference DGPL Policies · p. 42, §A.6 · p. 43

A.1 Basic PARC Authorization Policy; A.2 Conditional Policy

  • Basic PARC policies authorize employees to query the HR knowledge base, while conditional policies restrict execution to business hours.The examples show authorization by principal, action, and resource alongside a system-hour condition of 9–17.Source: §A.1 · p. 42, §A.2 · p. 42

A.3 Approval Workflow Policy; A.4 Governance Obligation Policy

  • Approval policies require administrator approval before deleting a production database, and obligation policies redact personally identifiable information and secrets before request processing.The obligation example uses Presidio and a secret scanner in redaction mode.Source: §A.3 · p. 42, §A.4 · p. 42

A.5 Threat Detection Policy

  • A threat-detection policy invokes an LLM provider to detect prompt injection and jailbreak attacks before policy evaluation is completed.The example denies reviewed inputs when the configured detector identifies the listed threat categories at the specified threshold.Source: §A.5 · pp. 42–43

B EAGBench Benchmark; B.1 Benchmark Overview; B.3 Enterprise Domain Distribution

  • EAGBench evaluates the Policy Kernel on 1,400 policy-governance scenarios spanning 70 business cases across seven enterprise domains using the paper’s PARC request and evaluation model.The benchmark is designed to exercise different policy families and governance outcomes across heterogeneous enterprise environments.Source: B EAGBench Benchmark · p. 44, §B.1 · p. 44, §B.3 · p. 44

B.2 Benchmark Dimensions; B.5 Business Case Complexity; B.6 Ground-Truth Decision Outcomes; B.7 Policy Evaluation Latency

  • The benchmark measures policy matching, governance decisions, taxonomy coverage, business-case complexity, human-approval escalation, and evaluation latency.These dimensions assess both decision correctness and the breadth, complexity, intervention requirements, and runtime characteristics of governance.Source: §B.2 · p. 44, §4 · p. 44

B.4 Cross-Domain Accuracy and Human Approval; B.5 Business Case Complexity; B.6 Ground-Truth Decision Outcomes; B.7 Policy Evaluation Latency

  • Across 1,400 scenarios, the Policy Kernel reports 94.1% overall accuracy, while human approval remains an explicit governance mechanism for cases requiring organizational intervention.Source: §B.4 · p. 44

B.8 Benchmark Interpretation

  • The results characterize the proposed architecture under defined benchmark conditions rather than universal enterprise performance, while providing a reproducible basis for larger policies, additional domains, distributed kernels, and autonomous-agent workloads.Production performance may vary with policy size and complexity, request characteristics, infrastructure, plugins, caching, and deployment architecture.Source: §B.8 · p. 46

B.8.1 Example: ERP High-Value Purchase Approval … C.21 Statement Identifier and Operation Identifier

The examples show how UPA governs high-value ERP purchases through conditional Finance Director approval, while standardized operation identifiers structure PARC actions and remain distinct from statement identifiers. The identifier vocabulary is extensible for domain-specific enterprise operations and supports traceable policy evaluation.

B.8.1 Example: ERP High-Value Purchase Approval

  • High-value purchase orders require Finance Director approval when the purchase amount exceeds 1,000,000, suspending the autonomous workflow until approval completes.The policy matches purchase:approve on purchase-order:* and evaluates 1,500,000 > 1,000,000 as True.Source: §B.8.1 · p. 46, Policy Matching · p. 46, Governance Decision · p. 46

B.9 ERP Purchase Approval Benchmark Implementation

  • The ERP benchmark implementation evaluates five boundary scenarios, expecting approval above the 10-lakh threshold and denial below or at it.The listed cases are Rs. 15, Rs. 25, and Rs. 50 lakhs with expected Approve, and Rs. 5 and Rs. 10 lakhs with expected Deny.Source: §B.9 · p. 46

C Standardized Operation Identifier Reference

  • Standardized operation identifiers provide a consistent, representative, and extensible vocabulary for actions performed across users, agents, models, tools, applications, and enterprise systems.Examples include llm:input and db:delete; the reference is explicitly non-exhaustive.Source: C Standardized Operation Identifier… · p. 47

C.18 Business Operations

  • Organizations can add domain-specific operation identifiers without modifying the PARC model or DGPL evaluation semantics.Enterprise applications may define their own operation identifiers for business operations.Source: §C.18 · p. 50

C.19 Identifier Naming Convention

  • Operation identifiers use a namespace:operation format in which the namespace denotes the domain and the operation denotes the requested activity.Additional namespaces and operations are permitted when they remain unambiguous and consistent with the governance model.Source: §C.19 · p. 50

C.20 Relationship to PARC

  • Within PARC, operation identifiers form the Action component and standardize that dimension independently of policy statement identity.The operation identifier provides the action vocabulary while remaining separate from the policy statement’s Statement Identifier.Source: §C.20 · p. 50

C.21 Statement Identifier and Operation Identifier

  • A Statement Identifier names the policy statement, whereas an Operation Identifier names the governed action, allowing multiple statements to govern one operation with independent traceability.The example distinguishes WiFiAccessForITAdmin as the Statement Identifier from rag:query as the Operation Identifier.Source: §C.21 · p. 50

D DGPL Grammar Reference … E.4 Persistence and Escalation Governance

The appendices extend UPA with formal grammar foundations and optional governance models for multi-agent coordination, provenance, stateful evaluation, and persistence-aware escalation. These extensions broaden governance beyond isolated authorization decisions while remaining partly proposed rather than benchmark-evaluated capabilities.

D DGPL Grammar Reference

  • UPA’s DGPL appendix defines the complete statement schema around PARC and introduces governance extensions for the broader policy model.PARC is represented as ⟨Principal, Action, Resource, Condition⟩; the appendix summarizes the complete DGPL statement schema.Source: D DGPL Grammar Reference · pp. 50–51

E Extended Governance Models and Case Studies

  • The extended governance appendix covers multi-agent coordination, provenance, stateful governance, pre-flight evaluation, offline assurance, and domain-specific requirements without making them core UPA requirements.Some constructs are proposed extensions or future implementation directions rather than capabilities evaluated in the current benchmark.Source: E Extended Governance Models and Case… · p. 51

E.1 Extended Agent-to-Agent Governance Model

  • Multi-agent governance treats agent-to-agent interactions as requiring communication channels as first-class governed resources, because isolated action checks may miss coordination behavior.This extends the governed-entity model beyond agents, tools, workflows, and enterprise resources.Source: §E.1 · p. 51

E.1.1 Communication Channels as Resources

  • A communication channel is any writable resource whose information can later be read by another principal, including repositories, caches, directories, datasets, and workflow artifacts.The resource-centric definition avoids relying on whether developers intended a resource to function as a communication mechanism.Source: §E.1.1 · p. 51

E.1.2 A2A Action Namespace

  • The A2A action namespace creates explicit governance points for communication, delegation, discovery, and control transfer, including topology constraints beyond individual-operation authorization.The example distinguishes authorization of one operation from governance of the communication topology connecting agents.Source: §E.1.2 · p. 51

E.2 Provenance-Extended Request Model

  • Provenance extends PARC requests with information about the origin and lineage of credentials, artifacts, instructions, retrieved information, and other security-relevant inputs.The Policy Kernel can distinguish enterprise-issued credentials from credentials discovered through shared workspaces or other agents.Source: §E.2 · pp. 51–52

E.2.1 Provenance-Aware Policy

  • Provenance-aware policies can deny otherwise possessed credentials when their origins or discovery paths are untrusted, but this extension is optional rather than required for every deployment.The illustrative policy uses fail_closed behavior and rejects credentials associated with shared workspaces, public datasets, peer agents, or paste services.Source: §E.2.1 · p. 52

E.3 Governance State and Stateful Evaluation; E.3.1 Aggregate-Behavior Policy; E.4 Persistence and Escalation Governance

  • The extended evaluation model introduces bounded governance state Σ, so aggregate behavior can become a governance condition; retaining that state as an auditable input supports replay determinism and additional approval after more than 12 consecutive failures.Source: §E.3 · p. 52, §E.3.1 · p. 53, §E.4 · p. 53

E.5 Mediation Completeness … E.8.4 Blind-Window Isolation

The sections define the conditions, trust boundaries, enforcement modalities, and domain controls required for UPA governance to remain complete, authoritative, auditable, and operationally enforceable. They apply these principles to financial-crime and dispute-management workflows through selective-label handling, role separation, and blind-window isolation.

E.5 Mediation Completeness

  • UPA guarantees apply only to operations mediated by a Governance Enforcement Point, so deployments should audit every unmediated path affecting state outside its declared boundary.This mediation audit provides a deployment-level coverage criterion because policy engines cannot govern operations that never reach the enforcement surface.Source: §E.5 · p. 53

E.6 Kernel Integrity and Trust Boundary

  • The Policy Kernel must remain a trusted governance component: governed workloads should not access governance resources, evidence should be append-only and tamper-evident, and security-critical obligation failures should fail closed.Any fail-closed opt-out should be explicit, auditable, and policy-specific.Source: §E.6 · pp. 53–54

E.7 UPA as a Governance Tool

  • UPA supports enforcement, pre-flight evaluation, and offline assurance, but only the Governance Enforcement Point provides the authoritative governance decision for execution.Pre-flight results can expose constraints and intended actions to planners but must not become authorization credentials; offline replay enables counterfactual analysis and red-team evaluation without modifying original execution.Source: §E.7 · p. 54, §E.7.1 · p. 54, §E.7.2 · p. 54

E.7.2 Agent-Callable Pre-Flight Evaluation

  • Pre-flight evaluation should be rate-limited and avoid unnecessary policy internals because exposing an agent-callable interface creates policy-probing risk.Authoritative enforcement remains at the Governance Enforcement Point.Source: §E.7.2 · p. 54

E.7.3 Offline Assurance and Red-Team Evaluation

  • Offline replay can identify denied operations, approval requirements, generated obligations, uncovered events, unmediated paths, and policy gaps, supporting continuous red-team searches for invariant violations.This enables counterfactual governance analysis without modifying the original execution.Source: §E.7.3 · p. 54

E.8 Financial Crime and Dispute Management Harness

  • Financial-crime and dispute-management workflows show why governance must address intervention, review, provisional credits, blocked transactions, and training-label formation beyond authorization.An unreviewed case is not automatically a negative outcome, because intervention can prevent the underlying outcome from becoming observable.Source: §E.8 · p. 54, §E.8.1 · pp. 54–55

E.8.1 Selective-Label Governance / E.8.2 Reference Harness

  • The reference harness converts governance requirements into enforceable runtime constraints through randomized non-intervention, inverse-propensity weighting, temporal separation, role separation, fairness and capacity constraints, drift scenarios, deterministic artifacts, and an append-only ledger.These controls support selective-label governance and structured dispute-management evaluation.Source: §E.8.2 · p. 55

E.8.3 Role Governance / E.8.4 Blind-Window Isolation

  • Blind evaluation is a first-class governed resource, with declarative role boundaries restricting agent access and a fail-closed isolation rule that turns procedural requirements into governance policy.The mapping separates proposer, implementer, executor, analyst, and human validator permissions, including promotion approval and restricted-artifact access.Source: §E.8.4 · p. 55, Table 10 · p. 55

E.9 Extended Financial Crime Policy Pack … E.15 Scope of the Extended Model

The extended UPA model demonstrates domain-specific governance beyond authorization, spanning financial-crime controls, privacy, fairness, approvals, benchmarking, incident replay, and extensible namespaces. These capabilities are presented as proposed or illustrative extensions rather than universally implemented or empirically validated replacements for host security.

E.9 Extended Financial Crime Policy Pack

  • Financial-crime policy packs encode evidence generation, label provenance, randomized exploration reserves, and maturity gates as governance obligations beyond access authorization.They can govern actions such as dispute:credit_provisional and population:audit_sample.Source: §E.9 · pp. 55–56

E.10.1 Denying Leakage-Prone Features; E.10.2 Privacy Protection Obligation; E.10.3 Fairness and Capacity Constraints

  • Extended policies deny leakage-prone features, attach redaction, tokenisation, and audit obligations to LLM inputs, and constrain artifact promotion using fairness, performance, and alert-rate conditions.The fairness thresholds are illustrative and are not universal regulatory or operational requirements.Source: §E.10.1 · p. 56, §E.10.2 · p. 56, §E.10.3 · p. 56

E.11 Human Approval Boundaries

  • Human approval boundaries distinguish an Approve effect from ordinary Allow decisions, requiring designated authorization and supporting evidence and integrity artifacts for selected operations.The example applies this boundary to detection-artifact promotion and assigns approval to a ModelRiskValidator.Source: §E.11 · p. 57

E.12 Benchmark Extensions

  • Benchmark extensions propose governance-specific metrics for A2A coordination, including channel-formation latency, credential-reuse denial, and provenance-policy interception, pending implementation and validation.These are proposed extensions, not empirical benchmark results.Source: §E.12 · p. 57, Table 11 · p. 57

E.13 Incident-Replay Evaluation as Future Work

  • Counterfactual incident replay evaluates historical event sequences against candidate policies to identify denials, approvals, obligations, provenance gaps, unenforced operations, and escalation points.This analysis does not establish that UPA would have prevented an incident, especially when attacks bypass the governance enforcement surface; independent security layers remain necessary.Source: §E.13 · p. 57

E.14 Extended SID Namespace

  • Candidate extended SID namespaces require established semantics and interoperability requirements before incorporation into the normative registry.The namespace extensions are therefore prospective rather than normative.Source: §E.14 · p. 58, Table 12 · p. 58

E.15 Scope of the Extended Model

  • The extended model applies UPA’s policy-centric layer to multi-agent communication, provenance, aggregate runtime behavior, governance state, pre-flight evaluation, offline assurance, domain governance, selective labels, approvals, and benchmarking.These capabilities demonstrate extensibility rather than complete implementation or empirical validation, and UPA is not a substitute for host security or identity infrastructure.Source: §E.15 · p. 58

Related papers

Loading 2609.06543v1…