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

A Unified Policy Architecture (UPA): The Governance Kernel for Enterprise AI Operating Systems Prabhu Raghav1 Balamurugan Pandi1 Arul Vivek1 Shek Mohammed1 Sridhar S1 1

SuperAgentX AI

arXiv:2609.06543v1 [cs.AI] 6 Sep 2026

{prabhu, balamurugan, arul.vivek, shek.mohammed, sridhar.s}@superagentx.ai

Abstract Enterprise Artificial Intelligence is evolving from conversational assistants toward autonomous software agents capable of planning, reasoning, invoking external tools, accessing enterprise knowledge, collaborating with other agents, and executing complex business workflows with limited human intervention. As autonomy increases, governance requirements extend beyond conventional model safety, prompt filtering, and content moderation to include authorization, compliance, human oversight, data protection, auditability, and runtime control of agent actions. Current enterprise AI governance mechanisms are fragmented across multiple domains, including identity and access management, AI guardrails, workflow orchestration, compliance frameworks, security controls, audit systems, and business-specific authorization rules. These mechanisms are frequently implemented as independent controls, resulting in duplicated governance logic, inconsistent enforcement, limited interoperability, and increasing operational complexity as organizations deploy autonomous AI agents across heterogeneous enterprise environments. This paper proposes a Unified Policy Architecture (UPA), a governance architecture that treats policy enforcement as a first-class architectural capability of Enterprise AI Operating Systems. UPA introduces a deterministic Policy Kernel that separates policy specification, policy matching, policy evaluation, and runtime enforcement from autonomous agent reasoning and application logic. The architecture uses a standardized Principal–Action–Resource– Context (PARC) request model and enables policies to produce both governance decisions and executable governance obligations. Unlike conventional AI guardrails that primarily focus on model inputs and outputs, UPA provides a unified governance model spanning the lifecycle of autonomous execution, including authentication, authorization, planning, memory access, tool invocation, inter-agent collaboration, workflow execution, human approval, compliance validation, audit generation, and runtime governance. The architecture further introduces declarative policy composition, standardized policy namespaces, extensible governance plugins, and industry-specific policy packs for heterogeneous enterprise environments. The paper presents the architectural foundations of UPA and its associated Declarative Governance Policy Language (DGPL), together with a benchmark-oriented evaluation methodology for enterprise AI governance scenarios. The proposed architecture provides a reference model for integrating authorization, safety, compliance, and runtime governance mechanisms under a common policy-centric control plane, establishing a foundation for interoperable and governable Enterprise AI Operating Systems. Keywords: Enterprise AI, Operating System AI Governance, Policy Engine, Policy-as-Code, Autonomous AI Agents, Multi-Agent Systems, Runtime Governance, Compliance, GRC, Enterprise Architecture

1

Introduction

infrastructure management, and identity systems centralized authentication and authorization. Each architectural evolution emerged in response to increasing system complexity and the need for standardized control mechanisms. Artificial Intelligence is now driving a comparable

Enterprise software has historically evolved through successive architectural abstractions. Operating systems abstracted hardware resources, middleware abstracted distributed communication, cloud platforms abstracted 1

2

Prabhu et al.

architectural shift. Large Language Models (LLMs) have rapidly evolved into autonomous AI agents capable of reasoning over enterprise knowledge, generating execution plans, invoking external tools, maintaining persistent memory, collaborating with specialized agents, and executing complex workflows with minimal human supervision. Rather than acting solely as conversational interfaces, these systems increasingly perform operational tasks that directly influence enterprise processes and business outcomes. This transition fundamentally changes the governance requirements of enterprise AI systems. Traditional governance mechanisms were designed for deterministic software whose execution paths were explicitly defined by developers. Autonomous AI agents, however, dynamically determine execution strategies, select tools at runtime, adapt to changing contexts, and coordinate with other intelligent agents. As agent autonomy increases, governance can no longer be limited to controlling software access or filtering generated responses. Instead, governance must encompass the complete lifecycle of autonomous decision making. Current approaches to AI governance largely focus on model-level safety through techniques such as prompt guardrails, jailbreak detection, toxicity classification, output moderation, and responsible AI evaluation. These capabilities are essential to improve interaction safety and reduce harmful behavior of the model. However, enterprise deployments require governance over substantially broader concerns, including authorization, memory access, tool invocation, workflow orchestration, business rules, regulatory compliance, cost management, human approvals, auditability, risk management, and policy enforcement across multiple collaborating agents and humans. Consequently, enterprise AI governance should be viewed as a system architecture problem rather than as a model safety problem only. Organizations require a unified governance layer capable of consistently enforcing enterprise policies across heterogeneous AI runtimes, business domains, and operational environments while remaining independent of any specific model provider, agent framework, or execution platform. This paper proposes the Unified Policy Architecture (UPA), a policy-centric governance architecture that unifies enterprise governance, AI runtime governance, and domain-specific governance within a common architectural framework. UPA separates governance logic from application logic through declarative policies, enabling consistent enforcement across the complete lifecycle of autonomous AI execution while supporting extensibility, interoperability, and organizational scalability. The primary contributions of this paper are: 1. We identify Enterprise AI Governance as a systems architecture challenge that extends beyond tradi-

tional authorization, AI safety, and guardrail mechanisms, requiring a unified runtime governance layer for Enterprise AI Operating Systems. 2. We propose the Unified Policy Architecture (UPA), introducing the UPA Policy Kernel as the declarative runtime governance layer that unifies authorization, runtime governance, compliance, auditability, approval workflows, and multi-agent governance, business rules, within a single policy-centric architecture. 3. We introduce a framework-independent Semantic Normalization model that transforms heterogeneous runtime events into a canonical policy representation, enabling consistent governance across LLMs, ML models, AI agents, workflows, tools, APIs, and enterprise applications. 4. We introduce a Governance Provider Framework that separates Evaluation Providers (e.g., threat detection, risk scoring, contextual enrichment) from Obligation Providers (e.g., privacy protection, compliance verification, audit logging), enabling extensible governance without modifying the core Policy Kernel. 5. We define a declarative governance policy model supporting authorization, AI safety, threat detection, approval workflows, governance obligations, and industry-specific policy packs, providing a unified governance language for heterogeneous Enterprise AI Operating Systems. As enterprises increasingly rely on autonomous AI systems to perform operational tasks, governance must evolve from isolated runtime controls toward comprehensive architectural governance. We argue that governance should become a foundational layer of enterprise AI systems, providing organizations with the mechanisms necessary to balance autonomy, security, compliance, accountability, and operational trust.

2

Related Work

The rapid adoption of Large Language Models (LLMs) and autonomous AI agents has accelerated research across AI safety, governance, security, policy enforcement, and multi-agent systems. Existing work has introduced valuable mechanisms for securing AI interactions, enforcing organizational policies, managing enterprise identities, and orchestrating autonomous workflows. However, these efforts largely address individual aspects of AI governance rather than providing a unified governance architecture spanning the complete lifecycle of autonomous AI agents. This section reviews the major research areas related to enterprise AI governance and identifies the architectural gap addressed by the proposed Unified Policy Architecture (UPA).

3

Prabhu et al.

erational semantics. However, UPA extends authorization beyond permission evaluation by introducing pluginPolicy-Based Access Control (PBAC) has long been based runtime transformations, governance evidence genadopted within enterprise systems to externalize au- eration, compliance verification, risk assessment, policy thorization decisions from application logic. Standards obligations, approval workflows, audit generation, and such as eXtensible Access Control Markup Language industry-specific policy packs as first-class architectural (XACML) (OASIS, 2005) [1] introduced declarative pol- concepts. icy languages capable of expressing complex authorization rules, while Open Policy Agent (OPA) [2] [3] demonstrated policy-as-code for cloud-native infrastructure us- 2.3 AI Safety and Guardrails ing the Rego language. Recent advances in Generative AI have led to extensive Similarly, Role-Based Access Control (RBAC) [4], research on model safety, prompt injection defense, jailAttribute-Based Access Control (ABAC) [5], and break detection, toxicity filtering, hallucination mitigaRelationship-Based Access Control (ReBAC) [6] provide tion, and output moderation. Significant contributions mature mechanisms for authorization within enterprise include Constitutional AI Bai et al. (2022) [8] from Anapplications. thropic, OpenAI’s alignment and safety research, Google Although these approaches effectively govern identi- DeepMind’s Gemini safety framework, NVIDIA NeMo ties, resources, and permissions, they assume determin- Guardrails Kotha et al. (2023) [9]. istic software execution and were not designed to govThe AI security community has also developed stanern autonomous AI agents capable of dynamic planning, dardized threat models for LLM applications. The reasoning, memory access, tool selection, and inter-agent OWASP Top 10 for Large Language Model Applications collaboration. identifies the most critical security risks affecting production LLM systems, including prompt injection, in2.2 Cedar Policy Language and Fine- secure output handling, training data poisoning, sensitive information disclosure, insecure plugin design, excesGrained Authorization sive agency, overreliance, and model theft [10]. These Cedar, introduced by Cutler et al. [7], provides a declar- risks provide an industry-recognized baseline for securing ative, analyzable, and high-performance policy language LLM-enabled applications and emphasize that security for fine-grained authorization. Its formal policy seman- challenges extend beyond traditional software vulnerabiltics, validation mechanisms, and separation of authoriza- ities to encompass model-mediated and agentic behaviors. tion logic from application code provide an important Commercial guardrail frameworks provide mechanisms foundation for modern policy-based access control. for validating prompts, detecting harmful content, applyUPA is substantially influenced by the design prin- ing safety filters, and preventing unsafe model outputs. ciples demonstrated by Cedar, particularly the use of However, guardrails primarily focus on validating model declarative policies, explicit principal–action–resource re- inputs and generated responses rather than governing enlationships, contextual evaluation, and a policy evalua- terprise concerns such as authorization, workflow execution model that separates governance decisions from ap- tion, memory access, business approvals, regulatory complication logic. UPA does not attempt to replace or gener- pliance, auditability, policy inheritance, or multi-agent alize Cedar’s authorization semantics. Instead, it builds coordination. upon the broader policy-centric abstraction to address governance requirements that extend beyond authoriza2.4 Enterprise Identity and Zero Trust tion. In particular, UPA introduces governance constructs Enterprise security architectures have progressively for autonomous AI execution, including semantic normal- evolved from perimeter-based security models toward ization, runtime policy obligations, plugin-based enforce- identity-centric security paradigms. Zero Trust Archiment, compliance verification, human approval work- tecture (ZTA), formalized by Rose et al. (2020) [11] in flows, governance evidence, industry-specific policy packs, NIST Special Publication 800-207, establishes the princiand multi-agent governance. These mechanisms are in- ple that no user, device, application, or workload should tended to govern not only whether an action is autho- be implicitly trusted based solely on its network locarized, but also how an authorized AI operation may be tion or ownership. Instead, authentication and authoexecuted within an enterprise governance environment. rization decisions are continuously evaluated using conAccordingly, Cedar represents an important authoriza- textual information such as user identity, device posture, tion foundation, while UPA investigates a broader archi- workload characteristics, resource sensitivity, and envitectural layer for lifecycle-wide governance of Enterprise ronmental conditions before granting access to enterprise AI Operating Systems. resources [11]. Zero Trust therefore shifts enterprise secuThe Unified Policy Architecture (UPA) draws inspi- rity from protecting network boundaries toward protectration from Cedar’s declarative policy model and op- ing enterprise resources through continuous verification

2.1

Policy-Based Access Control

4

Prabhu et al.

RBAC

Roles

(1996)

ReBAC

Relationships

(2011)

XACML

Declarative Policies

(2013)

ABAC

Attributes

(2015)

OPA

Policy-as-Code

(2020)

Formal Authorization Semantics

Cedar (2024)

• Runtime AI Governance

UPA

• Plugin Architecture

(2026)

• Industry Policy Packs • Compliance • LLM Governance • Multi-Agent Governance

Enterprise Autonomous AI

Figure 1. Evolution of Enterprise Policy Architectures.

Figure 1: Evolution of enterprise policy architectures from RBAC to UPA, illustrating the progression from authorization-centric models toward policy-centric runtime governance for Enterprise AI Operating Systems. and least-privilege access. Modern enterprise security platforms implement Zero Trust through identity providers, multi-factor authentication, privileged access management, policy decision points, policy enforcement points, continuous risk assessment, and adaptive authorization. These mechanisms significantly improve enterprise security by reducing lateral movement, minimizing implicit trust, and enforcing identity-aware access control across distributed cloud environments.

However, autonomous AI systems introduce execution contexts that extend beyond traditional human identities. Enterprise AI agents autonomously retrieve enterprise knowledge, invoke external tools, execute workflows, coordinate with other agents, maintain persistent memory, and dynamically generate execution plans without continuous human supervision. Consequently, identity verification alone cannot govern autonomous AI execution because governance decisions increasingly depend not only on who performs an action, but also on which

5

Prabhu et al.

agent is executing, which tools are invoked, which enterprise policies apply, which compliance obligations must be satisfied, and whether runtime behavior remains consistent with organizational governance policies. The Unified Policy Architecture (UPA) complements Zero Trust by extending identity-centric security into policy-centric runtime governance. While Zero Trust determines whether an authenticated principal should access an enterprise resource, UPA continuously governs the complete lifecycle of autonomous AI execution through declarative policy evaluation, authorization, plugin-based runtime transformations, compliance verification, approval workflows, governance evidence generation, audit logging, and multi-agent policy enforcement. In this sense, Zero Trust establishes the identity foundation, whereas UPA provides the runtime governance layer required for enterprise autonomous AI systems.

2.5

Governance-First AI Architectures

cation, memory management, task decomposition, reflection, and collaborative problem solving. These frameworks primarily focus on improving agent capabilities, including reasoning strategies, planning algorithms, memory architectures, tool integration, and multi-agent collaboration. While several frameworks provide callback mechanisms, execution hooks, orchestration logic, or framework-specific control mechanisms, governance policies are generally embedded within application code or tightly coupled to the execution framework. Consequently, policy enforcement is often implementationspecific and difficult to standardize across heterogeneous agent runtimes, enterprise applications, and organizational domains. As enterprise deployments increasingly integrate multiple autonomous agents operating across diverse business systems, organizations require governance mechanisms that are independent of any individual agent framework or model provider. Such governance must consistently regulate authorization, tool usage, memory access, workflow execution, compliance obligations, approval workflows, audit generation, and inter-agent interactions throughout the execution lifecycle. The Unified Policy Architecture (UPA) addresses this requirement by externalizing governance into a declarative policy layer that operates independently of the underlying LLM, agent framework, orchestration engine, or execution environment. "Unlike existing multi-agent frameworks that primarily focus on agent intelligence and orchestration, UPA focuses on governance as a first-class architectural layer, enabling consistent policy enforcement across heterogeneous autonomous AI systems regardless of the underlying agent implementation."

Recent work has begun to recognize governance as a firstclass architectural concern for agentic AI systems. Wen et al. (2026) proposed Arbiter-K, a governance-first execution architecture that introduces a deterministic neurosymbolic kernel positioned between probabilistic language models and environment-impacting operations. ArbiterK employs a Semantic Instruction Set Architecture (ISA), an instruction dependency graph, and a taint-aware execution model to enforce security policies during agent execution, demonstrating that governance can be integrated into the execution substrate rather than implemented solely through application-level guardrails [12]. Arbiter-K primarily focuses on execution security and deterministic control of agent behaviors. Enterprise deployments, however, require a broader governance architecture encompassing authorization, compliance, policy management, approval workflows, auditability, industry- 2.7 Positioning of DGPL and UPA specific policies, and heterogeneous enterprise integraThe reviewed approaches establish strong foundations for tions. UPA addresses these broader requirements through access control, policy evaluation, zero-trust security, AI a declarative Policy Kernel designed to serve as a goversafety, and autonomous-agent execution. However, these nance control layer for Enterprise AI Operating Systems. capabilities are commonly addressed as separate architectural concerns. 2.6 Multi-Agent Systems DGPL and UPA combine these concerns into a unified policy-centric governance model for Enterprise AI Research in multi-agent systems (MAS) has estabsystems. The objective is not to replace existing autholished the theoretical foundations for autonomous rearization engines, guardrails, or agent frameworks, but to soning, distributed decision making, cooperation, coorprovide a common declarative policy layer through which dination, negotiation, and communication among intelthey can be governed consistently. ligent agents. Foundational work by Wooldridge (2009) The architectural distinction can be summarized as foland Russell and Norvig (2021) formalized many of the lows: principles underlying autonomous agents and distributed The key distinction is that UPA treats authorization as artificial intelligence. More recently, the emergence of one component of a larger governance lifecycle. A policy Large Language Models has accelerated the development evaluation may therefore produce not only an authorizaof LLM-based autonomous agent frameworks, including tion decision but also a set of governance obligations: ReAct [13], Toolformer [14], AutoGen [15], CAMEL [16], and Voyager [17]. These systems demonstrate significant advances in autonomous planning, reasoning, tool invo-

Eval(q, Π) = (d, Γ)

6

Prabhu et al.

Table 1: Positioning of DGPL and UPA Relative to Existing Approaches Approach

Primary Focus

RBAC

Role-based authorization

ABAC

Attribute-based tion

ReBAC

Relationship-based authorization Declarative access-control policy

XACML

authoriza-

OPA / Rego

General-purpose Code

Cedar

Formal authorization

Zero Trust

Continuous security

AI Guardrails

AI interaction safety

Agent Frameworks

Agent reasoning and orchestration Governance-first agent execution

Arbiter-K

DGPL / UPA

Policy-as-

Declarative enterprise AI governance

Primary Governance Scope Permissions associated with roles Principal, resource, action, and environmental attributes Relationships among principals and resources Policy evaluation, combining algorithms, obligations, and advice Structured policy evaluation across systems Principal-action-resourcecontext authorization Identity, resource, device, and contextual access Input/output validation, filtering, and safety controls Planning, memory, tools, and multi-agent execution Deterministic execution security and instruction-level enforcement Authorization, approval, transformation, compliance, audit, and runtime governance

where d represents the governance decision and Γ represents the obligations generated by the applicable policies.

3

Relationship to UPA Authorization foundation Context-aware policy foundation Relationship-aware authorization mechanism Important foundation for declarative governance External policy decision mechanism that can serve governance use cases Authorization foundation and PARC model Security foundation complemented by runtime governance Governance providers/plugins within UPA Execution clients governed by external policies Complementary execution substrate Unified policy-centric governance layer

Problem Statement & Research Gap

These obligations may include plugin execution, human approval, audit generation, notification, compliance vali- Enterprise autonomous AI systems fundamentally differ dation, or other policy-defined governance actions. from traditional enterprise software. Unlike deterministic applications, autonomous AI agents dynamically reaConsequently, UPA separates three concerns that are son, plan, invoke external tools, retrieve enterprise knowlfrequently coupled in existing systems: edge, maintain persistent memory, collaborate with other agents, and adapt their execution strategies at runtime. Consequently, governance decisions must be continuously enforced throughout the execution lifecycle rather than Policy Semantics evaluated at a single authorization or safety checkpoint. ↓ Existing research addresses individual aspects of enGovernance Decision terprise AI governance but lacks a unified architectural approach. Authorization frameworks determine access ↓ permissions, guardrails improve interaction safety, Zero Runtime Enforcement Trust continuously verifies identities, and multi-agent frameworks enhance autonomous reasoning and collaboration. However, these capabilities operate independently This separation enables existing authorization tech- and do not provide a common governance abstraction canologies, AI-safety mechanisms, and agent execution pable of consistently enforcing enterprise policies across frameworks to participate in a common enterprise gov- heterogeneous AI systems. ernance architecture without requiring their internal imThis fragmentation creates several challenges for enterplementations to become part of the Policy Kernel. prise deployments:

7

Prabhu et al.

• Fragmented Governance: Authorization, AI safety, compliance, approvals, and audit mechanisms are implemented independently, resulting in duplicated logic and inconsistent policy enforcement.

4

Unified (UPA)

Policy

Architecture

4.1

Relationship to Existing Governance Architectures

• Framework Dependency: Governance mechanisms are tightly coupled to individual LLM Recent research has increasingly recognized that auproviders, agent frameworks, or orchestration plat- tonomous AI systems require governance mechanisms beyond traditional authorization and model safety. Arbiterforms, limiting interoperability and portability. K introduces a governance-first execution architecture that places a deterministic symbolic kernel between • Limited Runtime Governance: Existing ap- probabilistic reasoning and environment-impacting operproaches primarily evaluate access permissions or ations. Its primary contribution is a Semantic Instruction model interactions but do not continuously govern Set Architecture (ISA), instruction dependency graph, memory access, tool invocation, workflow execution, and taint-aware execution model that enables determininter-agent communication, and dynamic execution istic enforcement of security policies during agent execuplans. tion. Similarly, A Five-Plane Reference Architecture for Runtime Governance of Production AI Agents argues • Compliance Integration: Regulatory requirethat production AI agents require stateful runtime govments and industry-specific governance policies are ernance beyond traditional request-time authorization. typically embedded within application code rather The proposed architecture introduces composable govthan expressed as reusable declarative policies. ernance planes, composite principals, capability attenuation, interruption primitives, and structured audit evi• Lack of Standardization: Organizations lack a dence for governing delegated agent actions. The Unified Policy Architecture (UPA) shares the obcommon policy architecture capable of governing heterogeneous autonomous AI systems using a con- jective of treating governance as a first-class architectural concern. However, UPA addresses a complementary sistent governance model. problem by positioning governance as the Policy Kernel of an Enterprise AI Operating System. Rather than foAs enterprises increasingly deploy autonomous AI cusing primarily on execution security or runtime mediagents that interact with critical business systems, sen- ation, UPA introduces a declarative policy architecture sitive enterprise knowledge, regulated data, and opera- that unifies authorization, semantic normalization, runtional workflows, these limitations become significantly time governance, plugin orchestration, compliance vermore pronounced. The absence of a unified governance ification, approval workflows, governance evidence genlayer increases implementation complexity, reduces policy eration, industry-specific policy packs, and multi-agent consistency, complicates auditing, and limits the portabil- governance within a common policy framework. The arity of governance policies across heterogeneous enterprise chitecture is intentionally platform-independent, enabling environments. More fundamentally, the emergence of au- consistent governance across heterogeneous LLMs, agent tonomous AI systems suggests that enterprises are tran- frameworks, enterprise applications, workflow engines, sitioning toward Enterprise AI Operating Systems, where and organizational domains. multiple agents, models, tools, memories, workflows, and enterprise applications execute within a common runtime environment. Similar to traditional operating systems, 4.2 Design Principles which rely on a kernel to manage processes, memory, re- The Unified Policy Architecture (UPA) is a reference arsources, security, and system calls, an Enterprise AI Op- chitecture for policy-centric runtime governance within erating System requires a policy kernel that continuously Enterprise AI Operating Systems. Unlike existing apgoverns autonomous execution. Rather than treating gov- proaches that treat authorization, AI safety, compliance, ernance as an application-specific concern, the policy ker- workflow governance, and auditability as independent canel becomes the central runtime component responsible pabilities, UPA externalizes governance into a unified for authorization, policy enforcement, plugin execution, Policy Kernel responsible for continuously governing compliance verification, approval workflows, audit gener- autonomous AI execution throughout its lifecycle. ation, and coordination across heterogeneous AI agents The design of UPA is motivated by the observation and enterprise services. that enterprise autonomous AI systems execute across We argue that this architectural abstraction is essen- heterogeneous environments comprising multiple Large tial for building scalable, trustworthy, and interoperable Language Models (LLMs), agent frameworks, workflow enterprise autonomous AI systems. engines, enterprise applications, external tools, and or-

8

Prabhu et al.

ganizational policies. Embedding governance logic directly within these execution environments results in fragmented implementations, inconsistent policy enforcement, limited portability, and increased operational complexity. UPA therefore adopts a policy-centric architecture in which governance is separated from application logic and implemented as an independent runtime layer.

4.3

Architectural Overview

Figure 2 presents the overall architecture of the Unified Policy Architecture (UPA). UPA is designed as a Policy Kernel within an Enterprise AI Operating System, providing a unified governance layer that continuously regulates autonomous AI execution independently of the underlying Large Language Models (LLMs), agent frameworks, workflow engines, enterprise applications, and cloud platforms. By externalizing governance from application logic, UPA enables organizations to consistently enforce enterprise policies across heterogeneous execution environments while maintaining portability, extensibility, and interoperability. The architecture is organized into three logical layers: the Policy Kernel, Governance Services, and the AI Runtime Integration Layer. The Policy Kernel forms the core of the architecture and is responsible for transforming heterogeneous runtime events into canonical policy representations, evaluating declarative policies, coordinating runtime governance decisions, and orchestrating extensible governance plugins. Surrounding the kernel, Governance Services provide enterprise capabilities including compliance verification, approval workflows, audit and governance evidence generation, and industry-specific policy packs. Finally, the AI Runtime Integration Layer connects the Policy Kernel with autonomous agents, foundation models, enterprise memory systems, external tools, workflows, and enterprise applications, enabling governance policies to be enforced consistently throughout the execution lifecycle. Unlike traditional authorization architectures that evaluate permissions only before resource access, UPA performs continuous runtime governance. Every significant execution event—including natural language requests, agent planning decisions, tool invocations, workflow transitions, memory operations, and inter-agent communications—is intercepted by the Policy Kernel before execution proceeds. The kernel evaluates applicable governance policies, invokes policy plugins where required, verifies compliance obligations, determines approval requirements, and records governance evidence before permitting, denying, modifying, or deferring execution. A key architectural principle of UPA is the separation of governance from execution. AI agents, orchestration engines, workflow platforms, and enterprise applications remain responsible for performing computational tasks,

while governance decisions are delegated to the Policy Kernel through declarative policies. This separation enables organizations to evolve governance independently of application implementations, promotes policy reuse across heterogeneous systems, and provides a common governance abstraction spanning multiple AI frameworks and enterprise domains. The modular design of UPA further enables organizations to extend governance through a plugin-based architecture. Specialized governance capabilities—including personally identifiable information (PII) redaction, secret detection, content filtering, regulatory compliance verification, threat detection, and industry-specific validation—can be integrated as reusable plugins without modifying the core Policy Kernel. This extensibility allows enterprises to tailor governance behavior to organizational policies, regulatory requirements, and domain-specific operational constraints while preserving a consistent policy evaluation model. Collectively, these architectural layers establish UPA as the governance foundation of an Enterprise AI Operating System. Rather than functioning as a standalone authorization engine or application-level middleware, the Policy Kernel provides a unified execution abstraction that governs autonomous AI behavior across heterogeneous enterprise environments.

4.4

UPA Policy Kernel

The UPA Policy Kernel is the core governance component of the Unified Policy Architecture. It provides a unified runtime abstraction for governing autonomous AI execution within an Enterprise AI Operating System. Inspired by the role of kernels in traditional operating systems, the Policy Kernel continuously mediates interactions between AI agents, enterprise resources, external tools, memory systems, workflow engines, and organizational policies. Rather than embedding governance logic within applications or agent frameworks, the Policy Kernel externalizes governance into a declarative runtime layer that evaluates enterprise policies before, during, and after autonomous execution. The Policy Kernel is organized into four primary subsystems: Semantic Normalization, Policy Evaluation, Runtime Governance, and the Plugin Framework. Together, these subsystems transform heterogeneous runtime events into canonical policy requests, evaluate applicable governance policies, coordinate enforcement decisions, and extend governance through modular plugins. Figure 2 illustrates the interaction between these subsystems within the overall UPA architecture. 4.4.1

Semantic Normalization

Let E

9

Prabhu et al.

Figure 2: Overall architecture of the Unified Policy Architecture (UPA). The UPA Policy Kernel serves as the declarative runtime governance layer of an Enterprise AI Operating System, providing semantic normalization, policy evaluation, runtime governance, plugin orchestration, compliance verification, auditability, approval workflows, and industry-specific governance across heterogeneous AI runtimes. denote the set of heterogeneous runtime events generated by an Enterprise AI Operating System, including natural language requests, agent actions, workflow events, API invocations, memory operations, tool executions, and inter-agent communications. Let

p = ⟨pr, ac, re, ct, md⟩ where

P denote the set of canonical policy requests. The Semantic Normalization subsystem is defined as the transformation

e∈E is transformed into a canonical policy request

The canonical policy request is represented as

Action,

re : ct :

Resource, Execution Context,

md :

Runtime Metadata.

N (e) = ⟨pr, ac, re, ct, md⟩. The output of Semantic Normalization serves as the canonical input to the Policy Evaluation subsystem, enabling framework-independent governance across heterogeneous AI runtimes. 4.4.2

p = N (e).

ac :

Therefore,

N :E→P where each runtime event

Principal,

pr :

Policy Evaluation

Following semantic normalization, the canonical policy request is submitted to the Policy Evaluation subsystem.

10

Prabhu et al.

The Policy Evaluation subsystem determines whether the request satisfies the applicable declarative governance policies defined by the organization. Unlike conventional authorization engines that evaluate only access permissions, UPA evaluates governance policies over the complete execution context of autonomous AI systems, including identities, resources, execution context, organizational policies, regulatory constraints, and runtime state. Let P denote the set of canonical policy requests,

Unlike traditional policy engines that primarily return binary authorization decisions, UPA introduces Approve as a first-class declarative policy outcome. The Approve decision temporarily suspends autonomous execution and transfers control to an organizational approval workflow before execution may continue. This capability enables Human-in-the-Loop (HITL) governance for highrisk autonomous operations, including financial transactions, production system modifications, regulated data access, infrastructure changes, and other business-critical activities. Formally, Approve =⇒ AwaitApproval(principal)

Π the policy repository, and D = {Allow, Deny, Approve} the set of governance decisions. Policy evaluation is formally defined as

where execution remains suspended until the required approval workflow has been successfully completed. The governance obligations generated during policy evaluation are accumulated as Γ=

Eval : P × Π → D × Γ

Obligations(s)

s∈Π

where

where

Obligations(s) = {γ1 , γ2 , . . . , γk }

Eval(p, Π) = (d, Γ) for a canonical policy request p ∈ P, where d∈D represents the governance decision and Γ = {γ1 , γ2 , . . . , γn } denotes the ordered set of governance obligations generated during policy evaluation. Each governance obligation

represents the obligations associated with the matched policy statement. The Policy Evaluation subsystem therefore returns both the governance decision and the associated governance obligations. While the decision determines whether execution is permitted, denied, or requires approval, the obligations define additional governance actions that must be enforced during runtime. This separation between policy decisions and governance obligations enables UPA to support extensible runtime governance while maintaining a declarative policy model independent of specific execution platforms or enterprise applications. Plugin(s) = {plugin1 , plugin2 , . . . , pluginm }

γi ∈ Γ represents a runtime action that must subsequently be enforced by the Runtime Governance subsystem. Governance obligations may include plugin execution, audit logging, compliance verification, governance evidence generation, notification, policy obligations, and approval metadata. The resulting decision is defined as if all applicable policy conditions are satisfied, if one or more mandatory policy d= conditions are violated,     Approve, if execution requires explicit     human authorization prior to  continuation.  Allow,         Deny,

[

⊆ Obligations(s) 4.4.3

Governance Provider Framework

Enterprise governance requirements evolve continuously across organizations, industries, regulatory frameworks, and deployment environments. Embedding every governance capability within the core Policy Kernel would significantly increase implementation complexity and reduce architectural extensibility. UPA therefore introduces a Governance Provider Framework, a provider-based execution model that enables governance capabilities to be integrated independently of the Policy Kernel while preserving a uniform declarative policy model. The Governance Provider Framework separates governance providers into two categories: Evaluation Providers

11

Prabhu et al.

and Obligation Providers. Evaluation Providers particFor example, a signature repository may include patipate directly in policy evaluation by producing gover- terns such as nance attributes required to determine policy decisions. Obligation Providers, in contrast, are executed after pol- version: 1 icy evaluation as part of the governance obligations genpatterns: erated by matched policy statements. - "rm -rf /" Let - "rm -rf *" - "find / -delete" Φ = {ϕ1 , ϕ2 , . . . , ϕn } - "wipefs -a" denote the set of Evaluation Providers, and Γ = {γ1 , γ2 , . . . , γm } denote the ordered set of governance obligations returned by the Policy Evaluation subsystem. The Policy Evaluation function is therefore defined as Eval : P × Π × Φ → D × Γ where Evaluation Providers contribute dynamic governance attributes prior to determining the final governance decision. Evaluation Providers may include threat detection, risk scoring, semantic classification, context enrichment, data sensitivity analysis, or organization-specific evaluation services. These providers execute during policy evaluation and may influence whether a request is allowed, denied, or requires explicit approval. Obligation Providers execute after policy evaluation under the coordination of the Runtime Governance subsystem. Typical obligations include privacy protection, secret redaction, compliance verification, governance evidence generation, audit logging, notification services, business rule enforcement, and other organization-specific governance capabilities. Since obligation providers are executed declaratively through governance obligations rather than application logic, governance functionality remains externalized from enterprise applications and AI agent implementations. One important class of Evaluation Providers is the Threat Detection Provider. Threat Detection evaluates runtime requests before policy decisions are produced and enables policies to declaratively enforce enterprise security requirements against prompt injection, jailbreak attempts, malicious commands, data exfiltration, and organization-specific threats. UPA supports multiple threat detection strategies through a common provider abstraction. Signature-Based Threat Detection The SignatureBased Threat Detector performs deterministic threat detection by matching runtime requests against locally maintained YAML signature repositories. Signature repositories contain known malicious patterns including prompt injection templates, jailbreak attempts, destructive operating system commands, dangerous SQL statements, sensitive regular expressions, and organizationspecific attack signatures.

The Signature-Based Threat Detector performs lowlatency pattern matching before policy evaluation and returns one or more threat classifications that may be referenced by declarative policies. Because signature matching is deterministic and locally executed, it provides predictable performance suitable for enterprise deployments requiring minimal runtime overhead. LLM-Based Threat Detection While signature matching effectively detects known attack patterns, previously unseen attacks frequently require semantic reasoning beyond deterministic pattern matching. UPA therefore supports an LLM-Based Threat Detector that evaluates the intent and semantic meaning of runtime requests using a foundation model. The LLM-Based Threat Detector produces a confidence score together with one or more threat categories, such as Prompt Injection, Jailbreak, Data Exfiltration, or Social Engineering. Declarative policies may reference these scores to determine whether execution should be denied or require additional governance actions. Unlike Signature-Based Threat Detection, semantic detection identifies attacks whose wording differs from previously known signatures while preserving a common provider interface within the Governance Provider Framework. Formally, the Threat Detection Provider is represented as ϕT hreat = {ϕSignature , ϕLLM } where ϕSignature performs deterministic signature matching and ϕLLM performs semantic threat analysis. The Policy Evaluation subsystem may invoke either provider independently or execute both providers as part of a hybrid evaluation strategy depending on organizational governance policies. By separating Evaluation Providers from Obligation Providers, the Governance Provider Framework enables enterprises to introduce new governance capabilities without modifying the core Policy Kernel or application logic.

12

Prabhu et al.

This provider-based architecture promotes extensibility, interoperability, and long-term maintainability while preserving deterministic governance semantics across heterogeneous Enterprise AI Operating Systems. 4.4.4

Runtime Governance

r=

Policy evaluation determines whether an autonomous operation satisfies the applicable governance policies. Runtime Governance extends this capability by continuously coordinating policy enforcement throughout the complete execution lifecycle of autonomous AI systems. Rather than treating governance as a single authorization decision, UPA views governance as a continuous process that supervises execution before, during, and after runtime operations. The Runtime Governance subsystem is responsible for orchestrating the governance decision produced by the Policy Evaluation subsystem together with the associated governance obligations. This includes executing policy plugins, initiating approval workflows, generating governance evidence, recording audit events, verifying compliance requirements, enforcing organizational constraints, and coordinating interactions with enterprise enforcement points. Let D denote the governance decision returned by the Policy Evaluation subsystem, Γ the set of governance obligations, and

the set of runtime outcomes. Runtime Governance is formally defined as Gov : D × Γ → R where Gov(d, Γ) = r for d ∈ D,

Γ = {γ1 , γ2 , . . . , γn },

r ∈ R.

The set of runtime outcomes is defined as R=

( Executed, Blocked, PendingApproval, Failed

The runtime outcome is determined as:

) .

if d = Allow and all governance obligations succeed, if d = Deny,

 PendingApproval, if d = Approve,          if mandatory governance  Failed, obligations cannot be completed.

Unlike conventional authorization systems, Runtime Governance executes governance obligations continuously throughout autonomous execution. Governance obligations may be triggered before execution, during intermediate workflow stages, or after execution completes depending on the applicable policies and runtime context. Runtime Governance is therefore responsible for coordinating the complete governance lifecycle, including plugin execution, audit logging, compliance verification, approval orchestration, governance evidence generation, and policy enforcement across heterogeneous enterprise execution environments. This separation between policy evaluation and runtime governance enables the Policy Kernel to remain declarative while allowing enterprises to implement complex governance workflows independently of application logic. Collectively, the Policy Evaluation and Runtime Governance subsystems transform static authorization decisions into continuous governance processes suitable for Enterprise AI Operating Systems, where autonomous agents dynamically interact with enterprise applications, external tools, memory systems, workflow engines, and organizational resources.

4.5

R

  Executed,        Blocked,  

Plugin Framework

Enterprise governance requirements continuously evolve across industries, regulatory frameworks, organizational policies, and deployment environments. Embedding every governance capability within the core Policy Kernel would increase implementation complexity and limit extensibility. UPA therefore adopts a modular Plugin Framework that enables governance capabilities to be integrated independently of the core runtime while preserving a consistent declarative policy model. Unlike conventional middleware extensions that are invoked directly by application logic, UPA plugins are resolved and executed declaratively through governance obligations generated during policy evaluation. A matched policy may specify one or more plugins that must be executed as part of Runtime Governance. Consequently, governance behavior remains externalized from application implementations and is controlled through declarative policies. The Plugin Framework is intentionally designed as an open-ended governance extension mechanism rather than

13

Prabhu et al.

a fixed collection of governance capabilities. New govThe subset of obligations corresponding to plugin exeernance functions can be introduced without modifying cution is defined as the core Policy Kernel, the DGPL policy model, or the fundamental policy evaluation semantics. ΓP ⊆ Γ. 4.5.1

Governance Plugin Contract

An individual plugin obligation can be represented conceptually as

Each governance plugin implements a common asynγiP = ⟨provideri , conf igi ⟩ chronous execution contract. The contract provides the plugin with the canonical policy request, the current runwhere provideri identifies the governance provider and time context, and the configuration associated with the conf igi contains the provider-specific configuration. applicable governance obligation. For an ordered plugin obligation sequence, The abstract plugin interface is represented as: P ΓP = γ1P , γ2P , . . . , γm , Listing 1: Standard UPA Governance Plugin Interface class Plugin(ABC): async def execute( self, request, context, config, ): ...

The corresponding execution function is defined conceptually as Executeπ : (Request, Context, Configuration) → PluginResult where: • Request represents the canonical normalized policy request.

the Runtime Governance subsystem resolves and executes each obligation according to the ordering established by the applicable governance policies. This design allows a single policy decision to produce multiple governance obligations without requiring the Policy Kernel to contain implementation-specific governance logic. 4.5.3

Plugin Registry

UPA uses a registry-based provider resolution mechanism to associate declarative provider identifiers with concrete plugin implementations. A plugin can be registered using a stable provider identifier: Listing 2: UPA Plugin Registry Registration

• Context represents the current runtime execution context associated with the request.

@PluginRegistry.decorator("presidio") class PresidioPlugin(Plugin): ...

• Configuration represents provider-specific parameters declared by the applicable policy.

The corresponding policy can reference the provider declaratively:

• PluginResult represents the result produced by the governance plugin. The asynchronous interface allows a plugin to perform local processing, invoke external services, access machine learning models, communicate with enterprise systems, or perform other potentially asynchronous governance operations without coupling those capabilities to the core Policy Kernel. The plugin interface therefore establishes a stable architectural boundary between the declarative governance layer and the concrete implementation of governance capabilities. 4.5.2 Let

Plugin Obligations

Listing 3: Declarative Plugin Provider Configuration "plugins": [ { "provider": "presidio", "mode": "redact" } ]

The registry establishes a separation between policy declaration and implementation. The policy specifies which governance capability is required, while the registry determines which implementation provides that capability. This separation enables different implementations of the same governance capability to be introduced without changing the policy representation. 4.5.4

Plugin Execution Model

When a policy containing plugin obligations becomes applicable, the Runtime Governance subsystem resolves the Γ = {γ1 , γ2 , . . . , γn } corresponding providers and invokes them using the standenote the ordered set of governance obligations gener- dardized plugin contract. ated by the Policy Evaluation subsystem. For an ordered sequence

14

Prabhu et al.

4.5.6

Reference Plugin: Privacy Protection

P ΓP = γ1P , γ2P , . . . , γm ,

The Presidio plugin demonstrates a governance pluthe execution of the plugin pipeline can be represented gin that can detect and transform sensitive information as within an AI request. The plugin uses a privacy analysis engine to identify γP γP γP sensitive entities in the runtime prompt. It supports at C0 −−1→ C1 −−2→ C2 → · · · −−m → Cm , least two governance modes: where C0 represents the runtime context before plugin execution and Cm represents the resulting context after • detect — identifies sensitive entities without modiall applicable plugin obligations have been processed. fying the runtime context. A plugin may operate in an observational mode, in which the context remains unchanged, • redact — identifies sensitive entities and transforms the runtime prompt by replacing or anonymizing the Ci+1 = Ci , detected values. or in a transformational mode, in which the plugin produces a modified context, Ci+1 = T ransf ormπi (Ci ). This distinction allows governance plugins to perform either inspection and evidence generation or active transformation of runtime data. The overall plugin execution can therefore be represented as P ◦ · · · ◦ Executeγ P ◦ Executeγ P (C0 ). Cm = Executeγm 2 1

The resulting context is then supplied to the subsequent governance or runtime execution stage according to the applicable policy. 4.5.5

Plugin Result

A policy may declare the provider as follows: Listing 4: Declarative Privacy Redaction Plugin "plugins": [ { "provider": "presidio", "mode": "redact" } ]

In detection mode, the resulting context remains unchanged: C′ = C while in redaction mode: C ′ = RedactPresidio (C). The transformed context is subsequently passed to the next governance stage.

A governance plugin returns a structured result describing the outcome of its execution. Conceptually, the result 4.5.7 Reference Plugin: Secret Scanner can be represented as The Secret Scanner plugin demonstrates a deterministic local governance provider for detecting sensitive credenPluginResult = Success, Transformed, tials and secrets. Data, Message The plugin uses locally defined signatures to identify The fields represent: patterns corresponding to credentials such as cloud access keys, API keys, repository tokens, and JSON Web • Success indicates whether the plugin executed sucTokens. cessfully. The provider supports both detection and redaction • Transformed indicates whether the plugin modified modes. A representative policy configuration is: the runtime context. • Data contains provider-specific findings, evidence, or other governance information. • Message provides optional diagnostic or execution information.

Listing 5: Declarative Secret Scanner Plugin "plugins": [ { "provider": "secret_scanner", "mode": "redact" } ]

The distinction between execution success and transforIn detection mode, the plugin returns the identified mation is important for governance operations. A plugin may successfully inspect a request without modifying it, findings while leaving the runtime context unchanged. In while another plugin may successfully transform the re- redaction mode, identified secrets are replaced with typed quest before it is forwarded to an AI model or enterprise placeholders before subsequent runtime execution. system. Thus,

15

Prabhu et al.

4.5.9

′

C =

   C,

Plugin and Evaluation Provider Separation

if mode = detect,

RedactSecretScanner (C),    if mode = redact.

UPA distinguishes Governance Plugins from Evaluation Providers.

The Secret Scanner illustrates that governance plugins An Evaluation Provider contributes evidence or comneed not depend on external services or machine learn- puted attributes that may influence policy evaluation. A ing models. Deterministic, locally executed governance Governance Plugin, in contrast, executes a governance mechanisms can participate through the same standard- obligation produced by the policy evaluation process. ized plugin contract. The distinction can be represented as: 4.5.8

Plugin Extensibility

The Plugin Framework is intentionally open-ended. The reference implementations described above represent examples of the framework rather than an exhaustive set of supported governance capabilities. A plugin may implement detection, validation, transformation, enforcement, evidence generation, external verification, or organization-specific governance behavior while preserving the same standardized execution contract. Consequently, organizations may introduce new governance capabilities without modifying the Policy Kernel or changing the fundamental DGPL policy model. Potential extensions include, but are not limited to:

Evaluation Provider → Evidence → Policy Evaluation

whereas:

• Data Loss Prevention (DLP) • Data classification and sensitivity labeling • Content safety and policy validation

Policy Evaluation → Governance Obligation → Governance Plugin.

• Regulatory compliance verification • Model-specific governance controls • Data residency enforcement • Cost and resource governance • Rate and quota enforcement • External trust and identity verification • Digital signature and integrity verification • Enterprise notification and escalation

For example, a threat detection provider may produce a prompt-injection score that is evaluated against a policy threshold. A privacy plugin such as Presidio may then redact sensitive information when the applicable governance policy requires such a transformation. This separation prevents threat analysis, policy evaluation, and governance enforcement from becoming tightly coupled within the Policy Kernel.

• Organization-specific governance controls These capabilities are not assumed to be implemented by the current reference runtime. Instead, the Plugin Framework provides the architectural extension boundary through which such capabilities can be incorporated as independent providers. 4.5.10 Declarative Plugin Execution Example This extensibility property is fundamental to UPA because enterprise governance requirements are expected to evolve as new AI models, runtime technologies, regulatory requirements, and organizational controls emerge. Consider the following runtime request:

16

Prabhu et al.

Example: Declarative Plugin Execution Runtime Request Summarize the uploaded employee contract. Semantic Normalization N (e) = User, llm:input, EmployeeContract, EnterpriseContext Policy Evaluation Eval(p, Π) = (Allow, Γ) where the plugin obligations are ΓP = Presidio(redact), SecretScanner(redact) . Runtime Governance The Runtime Governance subsystem resolves the configured providers through the Plugin Registry and executes them against the current runtime context. The Presidio plugin identifies and redacts sensitive entities, while the Secret Scanner identifies and redacts configured secret patterns. Execution Pipeline Request → Semantic Normalization → Policy Evaluation → Plugin Resolution → Plugin Execution

5.1

Governance Execution Model

The Unified Policy Architecture (UPA) models enterprise AI governance as a sequence of deterministic transformations that progressively convert heterogeneous runtime events into governed execution outcomes. Unlike traditional authorization systems that evaluate only access permissions, UPA formalizes governance as a continuous runtime process comprising semantic normalization, policy evaluation, governance obligations, and runtime enforcement. Let E denote the set of heterogeneous runtime events generated by an Enterprise AI Operating System. Runtime events may originate from user requests, autonomous AI agents, workflow engines, memory operations, tool invocations, external APIs, or inter-agent communications. The governance execution pipeline is formally defined as N Eval Gov E −→ P −−−→ (D, Γ) −−→ R where: • N : E → P denotes the Semantic Normalization function. • P denotes the canonical policy request.

→ Sanitized Context

• Eval : P ×Π×Φ → D×Γ denotes the Policy Evaluation function.

→ LLM Runtime.

• Π denotes the policy repository.

The example demonstrates that the application itself does not directly invoke the privacy or secret-scanning implementations. The governance requirements are declared by policy, resolved through the Plugin Registry, and enforced by the UPA Runtime Governance subsystem. This architecture allows governance capabilities to evolve independently from the applications and AI models that consume them.

5

scribing how heterogeneous runtime events are transformed into governed execution outcomes. The formal model establishes a common semantic foundation for semantic normalization, policy evaluation, governance obligations, runtime enforcement, and provider-based extensibility across heterogeneous Enterprise AI Operating Systems.

• Φ denotes the set of evaluation providers. • D denotes the governance decision. • Γ denotes the ordered set of governance obligations. • Gov : D × Γ → R denotes the Runtime Governance function. • R denotes the governed runtime outcome. The governance pipeline consists of four sequential stages:

Formal Mathematical Founda1. First, the Semantic Normalization function transforms tion

This section formalizes the execution semantics of the Unified Policy Architecture (UPA). The objective is to provide a platform-independent mathematical model de-

heterogeneous runtime events into a canonical policy request independent of the underlying AI framework, workflow engine, foundation model, or execution environment.

17

Prabhu et al.

2. Second, the Policy Evaluation function evaluates the denotes the execution context, and meta denotes addinormalized request against the applicable declarative tional runtime metadata. Therefore, e ∈ E. governance policies. During this stage, one or more Runtime event sources are defined as src ∈ S, where ( ) Evaluation Providers may compute additional goverUser, Agent, Workflow, Tool, nance attributes required for policy evaluation, includS= . Memory, API, System ing threat detection, risk scoring, semantic classification, or contextual enrichment. These sources collectively represent the heterogeneous ex3. Third, the Policy Evaluation function returns both a ecution environment of Enterprise AI Operating Systems. The requested operation is defined as op ∈ O, where governance decision d ∈ D and an ordered set of gov  ernance obligations Γ = {γ1 , γ2 , . . . , γn }.  Prompt, ToolInvocation, MemoryRead,  4. Finally, the Runtime Governance function coordinates . O = MemoryWrite, WorkflowTransition,     execution by enforcing the governance decision toAPIInvocation, AgentCommunication gether with the associated governance obligations, Resources represent enterprise assets that may be govthereby producing the governed runtime outcome r ∈ erned by declarative policies, res ∈ Rs , where typical reR. sources include: The governance decision space is defined as ( ) LLM, SLM, ML, Memory, Tool, Database, Rs = . D = {Allow, Deny, Approve}, API, Workflow, Document, KnowledgeBase where: • Allow permits autonomous execution.

The execution context contains attributes required during policy evaluation:

• Deny terminates execution.

ctx = ⟨principal, environment, session, tenant, timestamp⟩.

The execution context may be enriched dynamically by Evaluation Providers during policy evaluation. Runtime metadata contains implementation-specific The runtime outcome space is defined as information that does not directly influence governance semantics but may contribute to observability, auditing, R = {Executed, Blocked, PendingApproval, Failed}. or governance evidence generation. Typical metadata inUnlike traditional authorization architectures that cludes request identifiers, execution identifiers, framework evaluate access permissions only once before execution, identifiers, model versions, latency metrics, and trace the governance execution model treats policy enforcement identifiers. as a continuous runtime process. This enables UPA to govern autonomous AI systems consistently across het- 5.3 Semantic Normalization Function erogeneous execution environments while remaining indeEnterprise AI Operating Systems generate heterogependent of individual AI frameworks, orchestration platneous runtime events originating from users, autonomous forms, and enterprise applications. agents, workflow engines, memory systems, external tools, APIs, and foundation models. Since these events 5.2 Runtime Event Model differ significantly in structure and semantics, they canEnterprise AI Operating Systems continuously gen- not be evaluated directly by a declarative policy engine. The Semantic Normalization function transforms heterate heterogeneous runtime events originating from erogeneous runtime events into a canonical policy request users, LLMs & SLMs, agentic apps, autonomous representation that is independent of the underlying exeagents, workflow engines, ML Models, enterprise cution framework. This abstraction enables a single polapplications, memory systems, external tools, and icy model to govern heterogeneous Enterprise AI Operatfoundation models. These events differ significantly in ing Systems without requiring framework-specific policy structure, semantics, and execution context, making didefinitions. rect policy evaluation impractical. Formally, Semantic Normalization is defined as To provide a unified governance model, UPA represents • Approve suspends execution pending completion of a human approval workflow.

every execution request as a runtime event belonging to the set E. A runtime event is formally represented as e = ⟨src, op, res, ctx, meta⟩ where src denotes the source of the event, op denotes the requested operation, res denotes the target resource, ctx

N :E→P where e ∈ E is an arbitrary runtime event and p = N (e) is the corresponding canonical policy request. The canonical policy request is represented as p = ⟨pr, ac, rs, ctx, meta⟩

18

Prabhu et al.

where pr denotes the principal, ac denotes the requested 3. Conflict Resolution action, rs denotes the target resource, ctx denotes the execution context, and meta denotes runtime metadata. 4. Governance Decision Generation The Semantic Normalization function satisfies 5.4.1 Policy Matching ∀e ∈ E, ∃! p ∈ P such that N (e) = p. Given a canonical policy request p ∈ P , the Policy MatchFor every runtime event e in the set of runtime events E, ing function identifies all policy statements whose condithere exists exactly one canonical policy request p in the tions are satisfied: set of policy requests P . Applying N to event e produces Match : P × Π → M where M = {s1 , s2 , . . . , sn } p. This property guarantees that every runtime event is transformed into a unique canonical policy request suit- denotes the set of matched policy statements. Unlike traditional authorization systems that freable for policy evaluation. quently terminate after locating the first matching rule, The execution context ctx may contain attributes inUPA evaluates all applicable policy statements to supcluding identity, environment, workflow state, session inport policy composition, layered governance, compliance formation, organizational context, temporal constraints, verification, and organizational policy inheritance. and tenant information. Additional contextual attributes may be produced dynamically by Evaluation Providers during Policy Evaluation without altering the normalized 5.4.2 Evaluation Providers representation itself. Certain governance decisions cannot be determined solely By separating runtime event interpretation from policy from the canonical policy request. Enterprise AI systems evaluation, UPA enables governance policies to remain frequently require additional runtime information such as independent of specific agent frameworks, orchestration threat assessments, semantic classifications, risk scores, platforms, programming languages, deployment models, contextual attributes, or organization-specific intelligence or foundation model providers. before a governance decision can be produced. UPA introduces Evaluation Providers, a collection of Normalization Property. For every runtime event pluggable evaluation services that compute dynamic gove ∈ E, Semantic Normalization produces exactly one ernance attributes during policy evaluation. Let Φ = canonical policy request p ∈ P , thereby ensuring deter{ϕ1 , ϕ2 , . . . , ϕn } denote the set of Evaluation Providers. ministic policy evaluation independent of the originating Each provider is represented as execution framework. The output of Semantic Normalization is a canonical policy request consisting of the Prinϕi : P → A i cipal, Action, Resource, and Context (PARC). where Ai denotes the set of governance attributes produced by the provider. 5.4 Policy Evaluation Function For a canonical policy request p ∈ P , the collective The Policy Evaluation function determines whether a provider output is defined as canonical policy request satisfies the applicable gover[ nance policies defined by an organization. Unlike traA= ϕi (p) = {a1 , a2 , . . . , am }, ditional authorization engines that evaluate a single polϕi ∈Φ icy in isolation, UPA evaluates a collection of declarative policies, incorporates dynamic governance attributes pro- which represents the complete set of governance atduced by Evaluation Providers, resolves policy conflicts tributes available during policy evaluation. deterministically, and produces both a governance deciBy separating runtime attribute generation from sion and an ordered set of governance obligations. declarative policy evaluation, UPA enables organizations Formally, let P denote the set of canonical policy re- to introduce new evaluation capabilities without changing quests, Π the policy repository, and Φ the set of Evalua- the Policy Kernel or existing policy semantics. tion Providers. The Policy Evaluation function is defined as 5.4.3 Conflict Resolution Eval : P × Π × Φ → D × Γ Policy evaluation frequently produces multiple matchwhere Eval(p, Π, Φ) = (d, Γ) for p ∈ P . ing policy statements that may express different govThe evaluation process consists of four sequential ernance decisions or runtime obligations. Let M = stages: {s1 , s2 , . . . , sn } denote the set of matched policy statements. Conflict resolution is formally defined as 1. Policy Matching 2. Evaluation Provider Execution

Resolve : M → D × Γ where Resolve(M ) = (d, Γ).

19

The conflict resolution process evaluates matched policies using a deterministic precedence strategy consisting of: 1. Policy Priority 2. Policy Effect

Prabhu et al.

5.5

Runtime Governance Function

The Runtime Governance function is responsible for enforcing the governance decision together with the associated governance obligations. Formally, the Runtime Governance function is defined as Gov : D × Γ → R where Gov(d, Γ) = r,

with d ∈ D, Γ = {γ1 , γ2 , . . . , γn }, and r ∈ R. The runtime outcome space is defined as  4. Policy Version Executed, if d = Allow and all     governance obligations   Policy priority is evaluated first, with higher priority   succeed,   values taking precedence. When multiple policies have   if d = Deny,  Blocked, the same priority, governance effects are evaluated acr= cording to the precedence  PendingApproval, if d = Approve,       Deny > Approve > Allow.  Failed, if mandatory governance     obligations cannot be   If multiple policies remain applicable, the most specific completed. policy is selected. Policy version is considered only when all preceding precedence rules produce equivalent results. For d = Allow, Runtime Governance executes obligations in Γ before execution continues. For d = Deny, execution is terminated immediately. For d = Approve, 5.4.4 Governance Decision execution is suspended pending workflow completion. 3. Policy Specificity

The final governance decision returned by the Policy Evaluation function belongs to the decision space D = 5.6 Properties of the Governance Model {Allow, Deny, Approve}. The resulting decision is defined The formal execution model of UPA satisfies several key as: properties:  Allow, if all applicable governance    Property 1 (Deterministic Normalization). For  conditions are satisfied,    every runtime event e ∈ E, there exists exactly one canon if one or more mandatory  Deny, ical policy request p ∈ P such that N (e) = p. Identical governance policies prohibit d= runtime events always produce identical canonical repre execution,    sentations independent of the originating framework.  Approve, if execution requires explicit     organizational approval before  Property 2 (Deterministic Policy Evaluation). continuation. Given an identical request p, repository Π, and provider Unlike conventional authorization engines, UPA intro- outputs, Eval(p, Π, Φ) always produces the same goverduces Approve as a first-class declarative governance de- nance decision d and obligations Γ. cision, enabling Human-in-the-Loop governance by suspending execution until approval completes. Property 3 (Conflict Resolution Consistency). Whenever multiple policy statements match, UPA resolves conflicts using a deterministic precedence model 5.4.5 Governance Obligations (Priority > Effect > Specificity > Version). In addition to the governance decision, Policy Evaluation returns an ordered set of governance obligations Γ = {γ1 , γ2 , . . . , γn }. Governance obligations describe runtime actions that must be coordinated by the Runtime Governance subsystem following policy evaluation, such as plugin execution, audit logging, compliance verification, evidence generation, notification services, and workflow metadata. Unlike Evaluation Providers, governance obligations execute after the decision has been determined.

Property 4 (Governance Completeness). Every canonical policy request p ∈ P produces exactly one governance decision d ∈ D, ensuring policy evaluation always terminates cleanly. Property 5 (Framework Independence). Governance decisions depend exclusively on the canonical policy request rather than the originating framework or language.

20

Prabhu et al.

Property 6 (Extensibility). Evaluation Providers and Obligation Providers may be added or modified without changing the Policy Kernel or existing policy semantics.

6

The DGPL specification defines the logical policy model independently of its concrete serialization format. JSON and YAML are therefore representations of the same underlying declarative governance semantics.

Declarative Governance Policy 6.1 Policy Document Model Language A DGPL policy document represents a collection of

The Unified Policy Architecture introduces the Declarative Governance Policy Language (DGPL), a platformindependent policy language for expressing enterprise AI governance. DGPL enables governance requirements to be specified declaratively rather than embedded within application logic, AI agent implementations, or runtimespecific control mechanisms. Unlike traditional authorization languages that primarily express access control decisions, DGPL provides a unified policy model for authorization, AI safety, runtime governance, threat detection, governance obligations, human approval workflows, and extensible enterprise governance. The design of DGPL is guided by the following principles: 1. Declarative Governance. Policies specify governance requirements and desired governance outcomes rather than procedural execution logic. 2. Platform Independence. Policies operate on canonical policy requests and remain independent of specific AI frameworks, programming languages, orchestration platforms, and model providers. 3. Extensibility. Evaluation Providers and Governance Plugins can be introduced without modifying the core Policy Kernel or the fundamental DGPL model. 4. Deterministic Evaluation. Equivalent runtime requests evaluated against an equivalent policy repository produce deterministic governance outcomes.

declarative governance statements evaluated by the UPA Policy Kernel. A policy document consists of a language version and one or more policy statements: P olicy = ⟨V ersion, Statements⟩ where V ersion identifies the DGPL specification version and Statements denotes the collection of policy statements contained in the document. The statement collection is represented as Statements = {S1 , S2 , . . . , Sn } .

Each statement defines an independent declarative governance rule. A policy document may therefore contain multiple statements that collectively express authorization, contextual constraints, threat detection requirements, governance obligations, approval workflows, compliance requirements, and organization-specific controls. The policy document does not contain procedural execution logic. Instead, the UPA Policy Kernel interprets the statements according to the governance execution semantics defined in Section 5. A minimal DGPL policy document can be represented as: Listing 6: Generic DGPL Policy Document { "version": "2026-01-01", "statements": [ ... ] }

5. Human Readability. Policies use a concise and structured representation that can be understood by The version field identifies the language specification policy authors and processed by automated systems. version and enables the language to evolve while maintaining compatibility across policy implementations. 6. Machine Processability. DGPL can be seriThe statements array contains the independent govalized using structured formats such as JSON or ernance statements. During policy evaluation, the UPA YAML while preserving a common underlying sePolicy Kernel evaluates the applicable statements against mantic model. a single canonical policy request. The logical policy model is independent of JSON se7. Enterprise Composability. Multiple policy statements may be composed to express layered gov- rialization. Consequently, equivalent DGPL policies may ernance spanning authorization, AI safety, run- be represented using JSON, YAML, or another structured time controls, compliance, approval workflows, and serialization format without changing their underlying semantics. organization-specific requirements.

21

Prabhu et al.

6.2

Policy Statement Model

Principal

A Policy Statement represents the fundamental gover- The Principal identifies the subject initiating the runtime nance unit within DGPL. Each statement defines an in- request. A Principal may represent: dependent declarative rule that may authorize, deny, approve, or impose governance requirements on a runtime • a human user, operation. • an autonomous AI agent, A policy statement is formally represented as S = ⟨SID, Ef f ect, P ARC, Extensions⟩ where:

• an application, • an enterprise service, • an infrastructure component, or

• SID identifies the policy statement.

• another authorized execution identity.

• Ef f ect specifies the governance decision associated When the Principal element is omitted, the statement with the statement. may apply to all principals, subject to the remaining matching criteria. • P ARC represents the Principal–Action–Resource– Context authorization model. Action • Extensions represents optional governance capabil- The Action identifies the operation being performed. ities associated with the statement. DGPL actions may represent operations such as: The three governance effects defined by DGPL are:

• LLM input or output operations, • tool invocations,

Ef f ect ∈ {Allow, Deny, Approve}. The effect semantics are:

• API invocations, • workflow transitions,

• Allow permits execution subject to applicable governance obligations.

• memory reads and writes,

• Deny prohibits execution.

• organization-specific operations.

• Approve suspends autonomous execution and requires the specified approval workflow to complete before execution can continue.

• RAG queries, and Actions are represented using standardized identifiers such as llm:input, rag:query, and db:delete.

Resource A statement may contain only the fields required for its governance purpose. For example, a general authoriza- The Resource identifies the enterprise asset against which tion policy may specify Principal, Action, and Resource the action is performed. Resources may represent: without a Context condition, while a runtime governance policy may additionally specify Evaluation Providers or • foundation models, Governance Plugins. • AI agents,

6.3

PARC Model

DGPL adopts the Principal–Action–Resource– Context (PARC) model as its core authorization abstraction. Formally,

• enterprise knowledge bases, • APIs, • databases, • workflows, • tools,

P ARC = ⟨P rincipal, Action, Resource, Context⟩ . PARC provides a framework-independent representation of the authorization relationship between a runtime request and a governance policy.

• memory systems, or • other enterprise resources. Examples include database:production, and *.

knowledgebase:hr,

22

Prabhu et al.

Context

Example: PARC Authorization Policy

The Context represents runtime information used to determine whether additional governance predicates are satisfied. Context may include temporal attributes, environmental attributes, organizational attributes, user attributes, resource attributes, or facts generated by Evaluation Providers.

Consider the policy requirement: Allow employees to query the HR knowledge base. The corresponding PARC representation is: P rincipal = Employee Action = rag:query

For example, a policy may require:

Resource = knowledgebase:hr Context = None The corresponding DGPL statement is:

system.hour ∈ [9, 17].

{ "sid": "HRKnowledgeAccess", "effect": "Allow", "principal": { "Role": ["Employee"] }, "action": [ "rag:query" ], "resource": [ "knowledgebase:hr" ]

Context therefore enables governance policies to depend on runtime conditions without embedding procedural logic into the policy. }

Governance Extensions Beyond PARC, DGPL provides extensible Governance Extensions. These include:

• Evaluation Providers, such as Threat Detection,

• Governance Plugins, such as PII redaction and secret scanning,

The example demonstrates that the core authorization semantics are captured by PARC, while additional governance capabilities can be introduced through Governance Extensions.

6.4

Governance Extensions

While PARC captures the core authorization semantics of DGPL, Enterprise AI Operating Systems require governance capabilities beyond traditional access control. DGPL therefore introduces Governance Extensions that augment the core policy model without modifying its fundamental PARC structure. Governance Extensions provide declarative mechanisms for expressing: • contextual constraints, • threat detection,

• Human Approval Workflows,

• runtime governance obligations, • human approval workflows, and • future organization-specific governance capabilities.

• and future organization-specific governance exten- 6.4.1 Conditions sions. Conditions specify additional predicates that must evaluate to true before a policy statement becomes applicable. A condition consists conceptually of: This separation allows the PARC model to remain stable while enabling the governance language to evolve with enterprise AI requirements.

Condition = ⟨F act, Operator, V alue⟩ . For example:

23

Prabhu et al.

"condition": { "all": [ { "fact": "system.hour", "operator": "between", "value": [9, 17] } ] }

Multiple conditions may be combined using logical operators such as all and any. Conditions enable context-aware governance without introducing procedural execution logic into the policy. 6.4.2

Threat Detection

Threat Detection is an Evaluation Provider that enables DGPL policies to incorporate runtime security analysis into governance decisions. DGPL supports two principal classes of Threat Detectors: 1. Static Threat Detectors 2. LLM-Based Threat Detectors Static Threat Detectors detect known threats by matching runtime content against locally maintained signatures or pattern definitions. A representative static signature configuration may contain:

"categories": [ "PromptInjection", "Jailbreak" ] } }

The output of Threat Detection becomes a governance attribute that can participate in Policy Evaluation. Conceptually, T hreatDetect(e) → T hreatF acts → P olicyEvaluation. This distinguishes Threat Detection from Governance Plugins: the former contributes evidence to policy evaluation, while the latter executes governance obligations produced by the policy decision. 6.4.3

Governance Plugins represent extensible governance obligations that are executed by the Runtime Governance subsystem. A policy may declaratively specify one or more plugins: { "sid": "EnterpriseProtection", "effect": "Allow", "action": [ "llm:input" ], "resource": [ "*" ], "plugins": [ { "provider": "presidio", "mode": "redact" }, { "provider": "secret_scanner", "mode": "redact" } ]

version: 1 patterns: - "rm -rf /" - "rm -rf *" - "rm -rf .*" - "rm -rf ~" - "rm -fr /" - "find / -delete" - "shred -u" - "wipefs -a"

Governance Plugins

}

The plugin framework is intentionally open-ended. PreStatic detection provides deterministic and low-latency sidio and Secret Scanner are reference implementations detection for known patterns. rather than an exhaustive set of governance capabilities. LLM-Based Threat Detectors perform semantic analyPotential future governance plugins may provide capasis using a foundation model. They are intended to iden- bilities such as: tify threats that cannot be reliably detected using static • data loss prevention, signatures alone, including prompt injection, jailbreak attempts, indirect prompt attacks, and emerging semantic • data classification, attack patterns. A DGPL statement may declare an LLM-based threat • compliance verification, detector as: • content governance, { "sid": "PromptInjection", "effect": "Deny", "action": [ "llm:input_review" ], "resource": [ "*" ], "threat": { "provider": "llm", "model": "gemini/gemini-2.5-flash", "threshold": 0.80,

• audit and evidence generation, • notification and escalation, • data residency enforcement, • cost governance, • resource and quota controls,

24

Prabhu et al.

• organization-specific governance controls.

Policy composition therefore allows authorization, security, runtime governance, and compliance requirements to be expressed independently.

The Plugin Framework therefore provides a stable extension boundary through which new governance capabilities can be introduced without modifying the Policy 6.5.1 Policy Matching Kernel or the fundamental DGPL policy model. Each policy statement is evaluated independently against 6.4.4 Approval Workflows the same canonical policy request. A statement is applicable when its declared PARC atDGPL introduces Approve as a first-class governance eftributes and conditions match the request. fect for Human-in-the-Loop execution. The Policy Kernel therefore computes: A policy may require organizational approval for highrisk operations: M = {S1 , S2 , . . . , Sm } . {

Only the statements contained in M participate in subsequent governance evaluation.

"sid": "ProductionDelete", "effect": "Approve", "action": [ "db:delete" ], "resource": [ "database:production" ], "approval": { "role": "Admin" }

6.5.2

Conflict Resolution

When multiple applicable statements specify different governance effects, DGPL requires deterministic conflict resolution. The governance effects have the following precedence:

}

When the applicable governance decision is Approve, Deny > Approve > Allow. autonomous execution is suspended and the required approval workflow is initiated. Thus, when a request simultaneously matches an Allow Conceptually, and a Deny statement, the resulting governance decision is Deny. Similarly, an applicable Approve requirement takes Approve → ApprovalWorkflow ( precedence over an Allow requirement when no higherApproved → ContinueExecution precedence Deny applies. → Policy specificity is used to distinguish policies when Rejected → DenyExecution multiple statements with the same effect apply at difApproval workflows are particularly applicable to finan- ferent levels of scope. More specific resource, action, or cial transactions, production changes, privileged admin- principal constraints take precedence over broader wildistrative operations, and other high-risk enterprise activ- card policies. ities. The conflict resolution semantics are summarized as:

6.5

Policy Composition and Conflict Resolution

A DGPL policy repository may contain multiple independent policy statements. A single canonical policy request may therefore match multiple statements simultaneously. The Policy Kernel evaluates the statements collectively rather than terminating after the first matching policy. Given a canonical policy request p, the matched policy set is: M (p) = {Si | M atch(Si , p) = true} .

Decision = Resolve(M ). The resolution function is deterministic: Resolve(M ) = d where d ∈ {Allow, Deny, Approve}. The separation of Policy Composition from Conflict Resolution allows multiple independent policies to participate in governance while preserving a single deterministic governance decision.

The resulting matched policy set may contain statements contributing different governance requirements. 6.5.3 Default Deny For example, a single request may match: DGPL adopts a default-deny governance model. Policy Governance Role If no policy statement matches the canonical policy reAllowLLMRequests Authorization quest, the Policy Kernel returns: BusinessHours Contextual Constraint EnterpriseProtection PromptInjection

Governance Plugin Threat Detection

Decision = Deny.

25

Prabhu et al.

Default deny ensures that autonomous execution is permitted only when explicitly authorized by the applicable governance policies.

• v is the comparison value. The expression evaluator is defined as:

Example: Policy Composition

Eval(e, C) → {true, false}. Representative operators include:

Consider a request:

• equals

Summarize the uploaded employee contract.

• not_equals

The request may simultaneously match:

• in

Statement

Effect / Obligation

• contains

AllowLLMRequests EnterpriseProtection AuditPolicy

Allow Presidio + Secret Scanner Audit obligation

• between

The Policy Kernel does not select the first matching statement. Instead, all applicable statements participate in the governance evaluation. The resulting decision and governance obligations are then enforced by Runtime Governance.

6.6

• less_than 6.6.3

Between Operator

For a fact f , a between expression with bounds [l, u] evaluates to true when: Eval(⟨f, between, [l, u]⟩, C) = true

Expression Semantics

DGPL conditions provide a declarative mechanism for expressing context-dependent policy predicates. This section defines the basic semantics of DGPL expressions independently of their concrete JSON or YAML representation. 6.6.1

• greater_than

iff l ≤ f (C) ≤ u. For example: { "fact": "system.hour", "operator": "between", "value": [9, 17]

Facts }

A Fact identifies a runtime attribute used during condition evaluation. Formally, F act : Context → V alue.

is satisfied when the runtime hour is within the declared interval. 6.6.4

Logical Expressions

DGPL supports logical composition of expressions. For an all expression:

For example: F act(system.hour, C) = 14.

Eval(all(e1 , . . . , en ), C) = true

A fact may originate from the canonical policy request, runtime context, enterprise context, or an Evaluation Provider.

iff

6.6.2

For an any expression:

Primitive Expressions

∀i, Eval(ei , C) = true.

A primitive DGPL expression can be represented as: e = ⟨f, o, v⟩ where: • f is a fact, • o is an operator, and

Eval(any(e1 , . . . , en ), C) = true iff ∃i, Eval(ei , C) = true. This permits multiple runtime conditions to be expressed declaratively without introducing procedural control flow.

26

Prabhu et al.

6.6.5

Condition Evaluation

A policy condition c is satisfied when: Eval(c, C) = true.

6.7.2

Human Approval Policy

A high-risk database operation may require explicit approval: {

"version": "2026-01-01", "statements": [ { "sid": "ProductionDelete", "effect": "Approve", "action": [ "db:delete" Applicable(S, p) = P ARCM atch(S, p)∧Eval(ConditionS , C). ], "resource": [ "database:production" When a statement does not specify a condition, the ], "approval": { condition component is considered satisfied by default. "role": "Admin" } } ] }

The condition therefore contributes to policy applicability:

6.7

Reference Policy Examples

DGPL supports a broad range of enterprise governance scenarios through the composition of PARC semantics and Governance Extensions. 6.7.3 Runtime Protection Policy Representative policies include: Sensitive information may be protected through declara• Basic authorization policies using the PARC model. tive governance plugins: • Context-aware policies using temporal or environmental conditions.

{ "version": "2026-01-01", "statements": [ { "sid": "EnterpriseProtection", "effect": "Allow", "action": [ "llm:input" ], "resource": [ "*" ], "plugins": [ { "provider": "presidio", "mode": "redact" }, { "provider": "secret_scanner", "mode": "redact" } ] } ]

• Threat Detection policies using static or LLM-based Evaluation Providers. • Governance policies invoking runtime plugins for privacy protection and secret detection. • Human Approval policies using the Approve effect. • Multi-statement policies combining authorization, threat detection, conditions, and governance obligations. 6.7.1

Business Hours Policy

A policy may restrict execution to a defined time window:

}

{ "version": "2026-01-01", "statements": [ { "sid": "BusinessHours", "effect": "Allow", "action": [ "*" ], "resource": [ "*" ], "condition": { "all": [ { "fact": "system.hour", "operator": "between", "value": [9, 17] } ] } } ] }

6.7.4

Threat Detection Policy

A policy may deny an LLM request when an LLM-based threat detector identifies a prompt injection or jailbreak above a defined threshold: { "version": "2026-01-01", "statements": [ { "sid": "PromptInjection", "effect": "Deny", "action": [ "llm:input_review" ], "resource": [ "*" ], "threat": { "provider": "llm", "model": "gemini/gemini-2.5-flash", "threshold": 0.80, "categories": [

27

Prabhu et al.

"PromptInjection", "Jailbreak" ] } }, { "sid": "AllowLLMRequests", "effect": "Allow", "action": [ "llm:input_review" ], "resource": [ "*" ] } ] }

In this example, the two statements may match the same canonical request. The threat evaluation produces a threat result that participates in Policy Evaluation. If the configured threat condition is satisfied, the applicable Deny statement takes precedence over the general Allow statement. 6.7.5

Role-Based RAG Authorization

DGPL can also express role-based access to enterprise knowledge: { "version": "2026-01-01", "statements": [ { "sid": "WiFiAccessForITAdmin", "effect": "Allow", "principal": { "Role": [ "ITAdmin" ] }, "action": [ "rag:query" ], "resource": [ "knowledgebase:wifi" ] }, { "sid": "HRAccessForEmployeesAndAdmins", "effect": "Allow", "principal": { "Role": [ "Employee" ] }, "action": [ "rag:query" ], "resource": [ "knowledgebase:hr" ] } ] }

These examples demonstrate that the same declarative language can express authorization, contextual governance, threat detection, runtime transformations, and human approval without embedding governance logic within the application implementation. The reference policies in Appendix A provide additional examples of DGPL constructs and their corresponding governance behavior.

7

Industry Policy Packs

7.1

Industry Policy Pack Model

Enterprise AI governance requirements vary across industries because organizations operate under different business processes, risk models, regulatory requirements, and operational constraints. A policy that is appropriate for a general enterprise environment may be insufficient for healthcare, financial services, manufacturing, or critical infrastructure. Writing these controls independently for every application can result in fragmented authorization logic, duplicated governance mechanisms, and inconsistent enforcement. UPA addresses this problem through Industry Policy Packs. Industry Policy Pack is a pre-built, versioned collection of DGPL policy statements designed for a particular industry or governance domain. A pack provides reusable authorization rules, contextual conditions, governance obligations, approval requirements, and provider bindings that can be incorporated into an organization’s existing policy repository. Industry Policy Packs do not introduce a separate policy language or enforcement mechanism. Instead, they provide reusable DGPL statements that are evaluated by the same Policy Kernel used for organization- specific policies. Consequently, an organization can adopt domainspecific governance without modifying the Policy Kernel, Semantic Normalization, Policy Evaluation, Conflict Resolution, or Runtime Governance mechanisms.

7.2

Formal Definition

An Industry Policy Pack is formally represented as IndustryPack = ⟨Domain, Version, Statements⟩ where • Domain identifies the industry or governance domain for which the pack is intended, such as Healthcare, Banking, Manufacturing, or Oil and Gas. • Version identifies the version of the policy pack and allows the pack to evolve independently while maintaining reproducible governance configurations. • Statements is the collection of DGPL policy statements contained in the pack. The statements are ordinary DGPL statements and therefore follow the policy statement model defined in Section 6. A policy pack is incorporated into an organization’s policy repository by adding its statements to the existing policy set:

28

Prabhu et al.

Π = Πcore ∪

[

7.4

Policy Packs for Key Industries

Pack i .Statements

Industry Policy Packs can be defined for a wide range of enterprise domains. Table 2 presents representative where Πcore represents organization-specific policies examples. and Pack i .Statements represents the statements provided The regulatory and standards references in Table 2 deby the i-th policy pack. scribe the governance context in which a pack may be Once incorporated, the Policy Kernel does not distinused. They do not imply that importing a policy pack guish between a policy authored internally and one origalone constitutes certification or regulatory compliance. inating from an Industry Policy Pack. Across industries, the same underlying DGPL mechaThe resulting evaluation follows the same governance nisms remain applicable: pipeline: i

Allow, N (e) → Policy Matching → Φ

Deny,

Approve,

Conditions,

→ Evaluation Providers → Conflict Resolution

Governance Obligations,

→ (d, Γ) → Gov (d, Γ).

Evaluation Providers.

This design allows multiple policy packs to coexist The difference between policy packs is therefore primarwithin the same policy repository. For example, an or- ily the domain-specific combination of principals, actions, ganization operating a healthcare business with an in- resources, conditions, effects, and governance obligations ternal financial-services division may simultaneously ac- rather than a different policy evaluation mechanism. tivate Healthcare and Finance policy packs. No industry-specific evaluation path is required.

7.5

7.3

Industry Policy Pack Examples

Anatomy of an Industry Policy Pack The following examples demonstrate how Industry Policy

An Industry Policy Pack is constructed using the governance constructs already defined by DGPL. The principal components are: • Authorization Statements — PARC-based statements that define which principals may perform specific actions on specific resources. • Conditions — contextual predicates that restrict policy applicability based on runtime facts such as business state, environment, temporal constraints, or organizational context. • Governance Obligations — obligations generated by policy evaluation that invoke governance capabilities such as auditing, privacy protection, secret detection, or other runtime controls. • Plugins and Provider Bindings — references to governance providers that extend runtime enforcement without modifying the Policy Kernel. • Approval Requirements — policies using the Approve effect to require human authorization for high-impact or irreversible operations. Regulatory references, ownership information, documentation, and change-management information may accompany a policy pack as distribution or governance documentation. Such information is not part of the core DGPL evaluation semantics. This distinction keeps DGPL policy evaluation implementation-independent while allowing policy packs to provide the documentation necessary for enterprise governance and audit processes.

Packs express domain-specific governance using the same DGPL constructs. Each request follows the general UPA execution model: N

Eval

Gov

E −→ P −−−→ (D, Γ) −−→ R.

29

Prabhu et al.

Industry

Primary Governance Focus

Example Regulatory / Standards Context

Healthcare

Patient-record access, treatment relationship, sensitivedata disclosure Transaction authorization, fraud response, high-risk transaction approval Production-system access, machinery control, operational safety Citizen-data access, sensitive records, controlled administrative operations Employee records, payroll operations, sensitive workforce information Pipeline operations, equipment control, emergency response and safety-critical actions Audit evidence, policy exceptions, compliance and reporting controls

HIPAA Privacy and Security Rules [18] PCI DSS and applicable financialsector requirements [19] ISO 12100 and applicable safety requirements Applicable public-sector and dataprotection requirements Applicable employment and dataprotection requirements Applicable process-safety and HSE requirements SOX, ISO 27001, and applicable governance frameworks

Finance / Banking Manufacturing Government Human Resources Oil and Gas GRC

Table 2: Representative Industry Policy Packs and governance focus. 7.5.1

Healthcare — Patient Record Access Eval(p, Π) = (Allow, Γ)

A Healthcare Policy Pack may restrict patient-record access to authorized members of a patient’s care team [18]. Additional contextual conditions may require verified authentication and an established treatment relationship.

where Γ = {AuditLog}.

{ "version": "2026-06-05", "statements": [ { "sid": "AllowPatientRecordAccess", "effect": "Allow", "principal": { "Role": ["Doctor", "Nurse"] }, "action": ["patient-record:read"], "resource": ["healthcare-record:assigned-patient"], "condition": { "all": [ { "fact": "context.authentication_verified", "operator": "equal", "value": true }, { "fact": "context.treatment_relationship", "operator": "equal", "value": true } ] }, "plugins": [ { "provider": "audit_logger", "mode": "record" } ] } ]

Runtime Governance executes the resulting obligation and the request continues to the protected resource. If either contextual condition is false, the statement does not match. If no other policy authorizes the request, the default-deny rule applies. 7.5.2

Cross-Industry — LLM Input Protection

Some governance controls are not specific to an industry but protect the common AI runtime layer. Such controls can be distributed as cross-industry policy components and composed with Industry Policy Packs. For example, an organization may require sensitive in} formation to be detected and redacted before an LLM Consider a nurse attempting to access the record of an receives input. assigned patient. { "version": "2026-01-01", The normalized request is represented using PARC:

N (e) =

"statements": [ { "sid": "EnterpriseProtection", "effect": "Allow", "action": ["llm:input"], "resource": ["*"], "plugins": [ { "provider": "presidio", "mode": "redact" }, { "provider": "secret_scanner", "mode": "redact" } ] } ]

Nurse, + * patient-record:read, assigned-patient, ctx

where ctx = {authentication_verified = true, treatment_relationship = true} The statement matches the canonical request and produces:

}

30

Prabhu et al.

The policy itself does not contain implementation logic actions. for either provider. Instead, the matched statement proA request to permanently reject the transaction or duces governance obligations that are executed by the block the account matches the second statement and proRuntime Governance subsystem. duces: This allows the same protection policy to be combined with Healthcare, Finance, Oil and Gas, or other Industry Eval(p, Π) = (Approve, Γ). Policy Packs. Runtime Governance suspends autonomous execution and initiates the approval workflow for the designated 7.5.3 Banking — Fraud Detection Agent FraudOfficer. This illustrates how Industry Policy Packs can preserve A Banking Policy Pack may allow an autonomous frauddetection agent to perform investigative operations while autonomous execution for lower-risk actions while introducing human control at specific decision boundaries. requiring human approval for irreversible actions. { "version": "2026-06-06", "statements": [ { "sid": "FraudDetectionAgentInvestigate", "effect": "Allow", "principal": { "Type": ["AIAgent"], "Role": ["FraudDetectionAgent"] }, "action": [ "transaction:analyse", "fraud-risk:calculate", "transaction:temporary-hold", "fraud-team:notify", "incident:create" ], "resource": [ "bank-transaction:*" ], "condition": { "all": [ { "fact": "context.fraudRisk", "operator": "equal", "value": "High" }, { "fact": "context.transactionDataValidated", "operator": "equal", "value": true } ] }, "plugins": [ { "provider": "audit_logger", "mode": "record" } ] }, { "sid": "FraudDetectionAgentIrreversibleAction", "effect": "Approve", "principal": { "Type": ["AIAgent"], "Role": ["FraudDetectionAgent"] }, "action": [ "transaction:reject", "account:block" ], "resource": [ "bank-transaction:*", "bank-account:*" ], "approval": { "role": "FraudOfficer" } } ]

7.5.4

An Oil and Gas Policy Pack can govern safety-critical autonomous operations. For example, an LNG Safety Agent may be permitted to stop an LNG transfer when a validated leak is detected, while requiring human approval before restarting the transfer. { "version": "2026-06-06", "statements": [ { "sid": "LNGSafetyEmergencyResponse", "effect": "Allow", "principal": { "Type": ["AIAgent"], "Role": ["LNGSafetyAgent"] }, "action": [ "alarm:create", "control-room:notify", "lng-transfer:stop", "incident:create" ], "resource": [ "lng-terminal:*" ], "condition": { "all": [ { "fact": "context.gasLeakDetected", "operator": "equal", "value": true }, { "fact": "context.sensorValidated", "operator": "equal", "value": true } ] } }, { "sid": "LNGSafetyRestartTransfer", "effect": "Approve", "principal": { "Type": ["AIAgent"], "Role": ["LNGSafetyAgent"] }, "action": [ "lng-transfer:restart" ], "resource": [ "lng-terminal:*" ], "approval": { "role": "ControlRoomSupervisor" } } ]

}

The first statement allows the agent to investigate a high-risk transaction and perform reversible investigative

Oil and Gas — LNG Safety Agent

}

31

Prabhu et al.

For a validated emergency condition, the first statement produces:

Πorg represent organization-specific policies and let

Eval(p, Π) = (Allow, Γ) and the safety action can be executed immediately. A later restart request produces: Eval(p, Π) = (Approve, Γ)

Pack 1 , . . . , Pack n represent active Industry Policy Packs. The effective policy repository is:

n [ and Runtime Governance transfers control to the desΠeffective = Πorg ∪ Pack i .Statements. ignated ControlRoomSupervisor. i=1 This demonstrates that Industry Policy Packs can exA single canonical policy request is evaluated against press different governance boundaries for autonomous acthis effective repository. tions within the same workflow. The Policy Kernel therefore does not evaluate a separate request for each policy pack. Instead, the same 7.6 Human Approval Within Industry canonical request is matched against all applicable statePolicy Packs ments. The resulting set of matching statements is subseIndustry Policy Packs can use the Approve effect when quently processed by Evaluation Providers and Conflict an action is considered sufficiently sensitive, irreversible, Resolution. or high impact that autonomous execution should be susThis preserves the policy composition semantics depended pending human authorization. fined by DGPL. Examples include: For example, a request to process a healthcare payment may simultaneously be subject to: • permanently blocking a bank account;

• restarting a safety-critical industrial process;

• Healthcare access controls;

• releasing sensitive information outside an organization;

• Finance transaction controls;

• approving a high-value financial transaction; and • executing an irreversible administrative operation.

• Organization-specific approval policies; and • Cross-industry LLM protection policies.

All applicable statements participate in the same govThe approval mechanism separates the ability of an ernance evaluation. agent to initiate an operation from the organization’s authority to authorize its execution. 7.8 Threat-Aware Governance Within Formally:

Industry Policy Packs

Approve → Approval Workflow   Approved → Continue Execution → Rejected → Terminate   Timeout → Terminate or Hold The exact timeout and rejection behavior is determined by the organization’s governance configuration. This allows autonomous agents to perform low-risk and reversible operations while retaining human control over high-impact decisions.

7.7

Composition Packs

of

Industry

Policy

Industry Policy Packs can be composed organization-specific policies and other packs. Let

Industry Policy Packs can also reference shared Evaluation Providers for threat detection. The policy pack does not need to implement threatdetection algorithms itself. Instead, the Policy Evaluation subsystem can invoke the appropriate Evaluation Provider and use the resulting evaluation evidence as part of governance processing. Representative threat categories include: • Prompt injection and jailbreak attempts; • Unauthorized agent actions; • Attempts to bypass approval requirements; • Data exfiltration and privilege escalation;

with

• Malicious tool invocation; and • Unsafe or socially engineered instructions.

32

Prabhu et al.

This design separates threat-detection implementation from domain-specific governance policy. For example, the same prompt-injection detection capability can be shared by Healthcare, Banking, and Oil and Gas policy packs while each domain independently determines the resulting governance action. Thus:

Because the same Policy Kernel evaluates all applicable statements, Industry Policy Packs do not require specialized enforcement logic. Healthcare, Banking, Oil and Gas, and other domains can therefore define different governance requirements while sharing the same underlying PARC model, policy evaluation semantics, governance obligations, approval mechanisms, and provider framework. This establishes Industry Policy Packs as a distribution Threat Detection ̸= Industry Policy. and reuse mechanism for DGPL rather than a separate Instead, threat detection provides evaluation evidence governance subsystem. that can participate in the common governance evaluation process.

7.9

8

SID Registry, Indexing, and Resolution

8.1

DGPL Policy Statements

Benefits of Industry Policy Packs

Industry Policy Packs provide several architectural benefits.

Each DGPL policy statement is identified by a unique Statement Identifier (SID). The SID provides a stable identifier for policy statements and enables policy evaluation results, governance obligations, audit records, and • Consistent Enforcement — domain-specific poli- administrative operations to reference the originating polcies are evaluated through the same Policy Kernel icy statement. For example, a DGPL statement may define: and Runtime Governance mechanisms. • Policy Reuse — common industry governance controls can be reused across multiple applications and AI agents.

• Composability — multiple policy packs can be combined with organization-specific policies.

{ "sid": "ProductionDelete", "effect": "Approve", "action": [ "db:delete" ], "resource": [ "database:production" ], "approval": { "role": "Admin" }

• Versionability — policy packs can evolve independently and provide reproducible governance configurations. • Extensibility — new industry packs can be introduced without modifying the Policy Kernel.

}

• Operational Separation — domain governance In this example, ProductionDelete identifies the polrules remain declarative while provider implementa- icy statement but does not itself determine whether the tions remain external to the policy language. statement matches a request. Matching is performed using the applicable policy attributes, while the SID proThe key architectural property is that Industry Policy vides the identity of the matched statement. Packs extend the policy repository, not the policy evaluation architecture. 8.1.1 SID Registry

7.10

Summary

The SID Registry maintains the relationship between a statement identifier and its corresponding policy statement. Conceptually, the registry can be represented as:

Industry Policy Packs provide a reusable mechanism for expressing domain-specific enterprise AI governance using the Declarative Governance Policy Language. RSID : SID → Statement A policy pack is composed of ordinary DGPL statewhere SID is the statement identifier and Statement ments and is incorporated into the organization’s policy represents the corresponding DGPL policy statement. repository: The registry enables the Policy Kernel and supporting governance components to resolve the origin of an evaluPack → Π ated policy decision. → Policy Matching For example: → Evaluation → Conflict Resolution → Runtime Governance.

RSID (ProductionDelete) = pProductionDelete

33

Prabhu et al.

The registry therefore provides a stable reference for This provides a direct relationship between the runtime policy statements without requiring the evaluation sub- decision and the policy statements that contributed to system to depend on the physical storage location of the that decision. policy. For example:

Policy Indexing Evaluating every policy statement against every runtime request can become inefficient as the policy repository grows. UPA therefore supports indexing mechanisms that reduce the number of candidate statements considered during policy matching. Given a normalized PARC request:

Eval(q, P ) = (Approve, Γ, {ProductionDelete})

q = ⟨P rincipal, Action, Resource, Context⟩ the indexing layer identifies a candidate policy set: I(q) = Pq where Pq ⊆ P and P represents the complete set of policy statements. The index may use policy attributes such as:

The SID therefore provides traceability without becoming a separate policy request or an independent evaluation object.

• Principal • Action • Resource • Policy effect

Resolution Flow

• Condition presence The purpose of indexing is to identify potentially appli- The complete resolution process can be represented as: cable statements efficiently. Final policy applicability remains the responsibility of the Policy Matching and Evaluation subsystems. Thus: Pq ⊆ P represents the candidate set rather than the final set of matching policies.

Runtime Event → Semantic N ormalization → P ARC Request → P olicy Index

SID Resolution

→ Candidate Statements

After candidate statements have been identified and evaluated, the Policy Kernel can associate the resulting decision with the SIDs of the applicable statements. Let:

→ P olicy M atching → M atched Statements → SID Resolution → P olicy Evaluation

M (q) = {p1 , p2 , . . . , pn } represent the set of statements that match the normalized request. The corresponding SID set is: SID(M (q)) = {sid(p1 ), sid(p2 ), . . . , sid(pn )}

The resulting governance decision may subsequently reference the resolved SIDs for auditability, explanation, approval workflows, and governance evidence.

34

Prabhu et al.

Table 3: Evaluation Dimensions

Example: SID Resolution Runtime Request

q=

No.

User, * db:delete,

Evaluation Dimension

Purpose

1

Correctness

2

Latency

3

Policy Repository Scalability

4

Concurrent Request Scalability

5

Plugin Execution Overhead

6

Interoperability / Normalization

Checks whether the Policy Engine returns the expected Allow, Deny, or Approve decision. Measures the time required to evaluate one authorization request and return a decision. Checks performance as the number of policy statements increases. Checks whether multiple authorization requests can be handled without failures. Measures additional latency introduced by governance plugins. Checks whether different runtime inputs can be converted into a common authorization request.

+

database:production, EnterpriseContext

Candidate Policy { "sid": "ProductionDelete", "effect": "Approve", "action": [ "db:delete" ], "resource": [ "database:production" ], "approval": { "role": "Admin" } }

Matching The action and resource match the normalized request. The statement therefore becomes applicable. M (q) = {pProductionDelete } SID Resolution SID(M (q)) = {ProductionDelete} Governance Decision  Approve,  Eval(q, P ) = Γ,

framework-independent normalization layer.

9.1

Correctness

Correctness evaluates whether the Policy Engine produces the expected governance decision for a canonical authorization request. Non-matching policies are ignored, while the effects of matching policies are resolved using deterministic precedence: Deny > Approve > Allow > Default Deny.



  {ProductionDelete}

The SID provides the identity of the policy statement responsible for the resulting governance decision.

Representative Policy { "sid": "AllowSalesDatabaseRead", "effect": "Allow", "action": ["db:read"], "resource": ["database:sales"] }

The SID Registry and indexing mechanism therefore Authorization Request serve different but complementary purposes. Indexing improves the efficiency of policy candidate retrieval, while { the SID Registry provides stable statement identity and "principal": {"id": "user-001", "type": "User"}, "action": {"name": "db:read"}, resolution. Separating these responsibilities allows the "resource": {"id": "sales", "type": "database"} Policy Kernel to optimize policy retrieval without chang- } ing the semantic identity of DGPL policy statements.

9

Experimental Evaluation

Evaluation Result {

"decision": "Allow", This section evaluates the implemented Unified Policy Architecture (UPA) using six complementary dimensions: } "matched_policy": "AllowSalesDatabaseRead" correctness, latency, policy repository scalability, concurThe request matches the action and resource defined by rent request scalability, plugin execution overhead, and interoperability through Semantic Normalization. The AllowSalesDatabaseRead; therefore, the engine returns order follows the evaluation flow from validating decision Allow. Additional cases verify mismatches, default deny behaviour, through performance and scalability, to the behaviour, human approval, and conflict resolution.

35

Prabhu et al.

Table 4: Policy decision verification suite Test ID Scenario COR-01 COR-02 COR-03 COR-04 COR-05 COR-06 COR-07 COR-08 COR-09

Exp.

Matching Allow policy Action mismatch Resource mismatch Principal mismatch Deny overrides Allow Approve overrides Allow Deny overrides Approve/Allow No matching policy Human approval policy

Act.

Table 6: Effective sequential throughput Res.

Policies

Allow Allow Pass Deny Deny Pass Deny Deny Pass Deny Deny Pass Deny Deny Pass Approve Approve Pass Deny Deny Pass Deny Deny Pass Approve Approve Pass

req/s Median (ms) Observation

10 14,519.60 100 2,150.54 500 247.01 1,000 209.55 5,000 31.08

0.0612 0.4003 2.3851 3.1485 17.2241

Very small repository Low evaluation cost Higher scan cost Low median latency Scan becomes costly

Table 7: Concurrent authorization results Conc. Reqs Succ. Fail Req/s Mean(ms) P95(ms)

Table 5: Authorization latency (ms) Policies

Mean Median

10 0.0689 100 0.4650 500 4.0484 1,000 4.7721 5,000 32.1788

P95

P99

Max

0.0612 0.0837 0.1103 0.6170 0.4003 0.8408 1.2113 1.5430 2.3851 3.4456 74.9523 94.3876 3.1485 4.4085 54.3665 59.1441 17.2241 108.2480 141.9245 145.4172

All nine structured correctness cases returned the expected decision, producing 9/9 successful cases in the preliminary engine-level verification suite.

9.2

1 10 10 10 100 100 25 250 250 50 500 500 100 1,000 1,000

Latency

0 0 0 0 0

101.60 178.03 209.71 237.96 236.27

9.3856 5.2143 4.4762 3.9737 4.0023

35.1700 5.9975 5.4775 5.1276 4.3574

Repository Growth Configuration 10 policies → match at position 10 100 policies → match at position 100 500 policies → match at position 500 1,000 policies → match at position 1,000 5,000 policies → match at position 5,000

As repository size increased, effective sequential throughput decreased. The result identifies sequential policy traversal as the main scalability limitation in the current evaluator and motivates future indexing or partitioning strategies.

Latency measures the time taken by PolicyEngine.authorize() to evaluate one canonical authorization request and return a governance 9.4 Concurrent Request Scalability decision. Ten warm-up executions were excluded, fol- Concurrent Request Scalability checks whether the Policy lowed by 100 measured requests for each policy repository Engine can process multiple authorization requests in the size. same execution period without failures. The repository was fixed at 1,000 policy statements, while concurrency was increased from 1 to 100 using in-process asyncio execution. Representative Benchmark Request Across all concurrency configurations, 1,860 measured authorization requests completed successfully and no failPrincipal = research-agent Action = tool:execute ures were recorded. Throughput increased to 237.96 reResource = tool:web_search quests per second at concurrency 50 and remained near Matching policy placed at final position. that level at concurrency 100. Median latency remained below approximately 3.2 ms through 1,000 policies and increased to 17.2241 ms at 9.5 Plugin Execution Overhead 5,000 policies. P95 reached 108.248 ms at 5,000 poliPlugin Execution Overhead measures the additional lacies, indicating greater tail-latency variation at the largest tency introduced when governance providers are executed tested repository. as part of policy evaluation. Four configurations were measured: no plugin, Presidio only, secret scanner only, and Presidio followed by the secret scanner.

9.3

Policy Repository Scalability

Policy Repository Scalability examines how the evaluator behaves as the number of policy statements increases. The matching policy was placed at the end of every repository so that the sequential evaluator traversed the complete policy set before finding the applicable rule.

Representative Plugin Policy { "sid": "EnterpriseProtection", "effect": "Allow", "action": ["llm:input"], "resource": ["*"],

36

Prabhu et al.

Authorization Latency vs Policy Count Median P95

Authorization latency (ms)

100 80 60 40 20 0 0

1000

2000 3000 Number of policy statements

4000

5000

Figure 3: Median and P95 authorization latency across increasing policy counts.

Concurrent Authorization Throughput

Throughput (requests/second)

240 220 200 180 160 140 120 100 0

20

40 60 Concurrent authorization requests

80

100

Figure 4: Observed throughput across increasing concurrency levels.

"plugins": [ {"provider": "presidio", "mode": "redact"}, {"provider": "secret_scanner", "mode": "redact"} ] }

The secret scanner introduced only 0.0092 ms of mean overhead relative to the no-plugin baseline. Presidio added approximately 2,398.54 ms of mean overhead and

dominated the measured runtime. The combined result is treated as preliminary because warm-up, caching, dependency initialization, and test order may influence plugin measurements.

37

Prabhu et al.

Plugin Execution Latency Mean latency (ms, log scale)

103 102 101 100 10 1

No plu

gins

io Presid

nner

r only

only

ne t scan e r c e S

io Presid

a ret sc c e s +

Figure 5: Mean plugin latency on a logarithmic scale. Table 8: Plugin execution latency (ms) Configuration No plugins Presidio only Secret scanner only Presidio + Secret scan

9.6

Mean

Median

Table 9: Semantic normalization verification – SN-01

P95 Overhead

0.0379 0.0350 0.0604 2398.5800 2195.5687 4128.9392 0.0471 0.0460 0.0540 1916.9712 1609.6492 3294.6966

0.0000 2398.5421 0.0092 1916.9333

Interoperability and Semantic Normalization

Interoperability and Semantic Normalization evaluate whether heterogeneous runtime requests can be transformed into a canonical authorization representation containing principal, action, resource, context, and metadata. In the current Context Builder pipeline, the LLM receives solely the natural-language user query. Trusted identity attributes and execution metadata are bound independently by the application runtime to prevent prompt-injection spoofing.

Field

Expected

Generated

Principal Action Res. Type Res. ID Intent Domain Query Type Fact Ext.

user-001 / User db:read database sales read_data database task data_type=customer

user-001 / User db:read database sales read_data database task data_type=customer

Result Pass Pass Pass Pass Pass Pass Pass Pass

"context": { "custom": { "intent": "read_data", "domain": "database", "confidence": 0.9, "query_type": "task", "data_type": "customer" } } }

Representative Runtime Input Authenticated principal: user-001 / User Natural-language request: "Read customer data in the sales database"

Generated Canonical Authorization Request { "principal": {"id": "user-001", "type": "User"}, "action": {"name": "db:read"}, "resource": {"id": "sales", "type": "database"},

SN-01 shows that the natural-language request was converted into the expected canonical action and resource while preserving the authenticated principal. This representative case demonstrates the intended interoperability role of Semantic Normalization: different runtime sources can be mapped to one common authorization structure before policy evaluation. A broader labelled test suite is required to quantify normalization accuracy across multiple actions, resources, and runtime formats.

38

Prabhu et al.

Semantic Normalization Flow Authenticated Runtime Input user-001 / User + Natural-language request

Semantic Normalization Extract action, resource, intent, domain, and query facts

Trusted Runtime Metadata Attachment Principal and execution metadata attached by application logic

Canonical Authorization Request Principal + Action + Resource + Context + Metadata

Figure 6: Semantic Normalization flow from authenticated runtime input to a canonical authorization request.

9.7

Summary of Findings

10

Discussion

The preliminary experimental results establish a concrete The Unified Policy Architecture (UPA) provides a performance baseline for the UPA prototype across all six governance-oriented architectural model for Enterprise AI systems in which policy evaluation, runtime goverevaluation dimensions: nance, human intervention, and governance extensions are treated as coordinated components of a single control • Correctness: The Policy Engine achieved a 100% plane. The architecture is designed to address the oppass rate (9/9 test cases), correctly resolving prece- erational requirements of autonomous agents and LLMdence conflicts (Deny > Approve > Allow > based applications rather than treating governance solely Default Deny). as a model-level safety mechanism. • Latency & Scalability: Median decision latency remained sub-3.2 ms for repositories up to 1,000 policies. However, sequential traversal caused latency to scale linearly, reaching 17.2 ms (median) and 108.2 ms (P95) at 5,000 policies.

10.1

Strengths

A primary strength of UPA is the separation between policy definition, policy evaluation, and policy execution. The Declarative Governance Policy Language (DGPL) provides a structured representation of governance re• Concurrency: The engine processed 1,860 concurrent quirements, while the Policy Kernel evaluates a normalrequests under multi-threaded execution with zero fail- ized request against applicable policies. This separation ures, saturating at a peak throughput of ≈ 238 req/s. allows governance rules to remain independent of individual agent implementations. • Plugin Overhead: Lightweight governance plugThe use of the PARC model—Principal, Action, Reins (e.g., secret scanning) added negligible delay source, and Context— provides a common representation (+0.0092 ms), whereas deep NLP providers (e.g., Pre- for policy matching across heterogeneous enterprise applisidio) dominated total execution time (≈ 2, 398 ms). cations. Consequently, policies can be evaluated against different types of agents, tools, resources, and runtime • Semantic Normalization: The framework success- operations without requiring application-specific policy fully translated unaligned natural-language queries logic. into canonical principal-action-resource tuples while Another strength is the explicit representation of govpreserving authenticated identity boundaries. ernance outcomes. UPA does not restrict policy evalua-

39

Prabhu et al.

tion to binary allow or deny decisions. The architecture supports outcomes such as Allow, Deny, Approve, and associated governance obligations. This enables policies to initiate actions such as human approval, auditing, notification, inspection, transformation, or other runtime governance operations. The Plugin Framework further separates extensible governance capabilities from the Policy Kernel. Privacy protection, secret detection, compliance validation, threat detection, and organization-specific controls can therefore be introduced without modifying the fundamental policy evaluation mechanism.

10.2

Architectural Implications

The architecture implies that Enterprise AI governance should be treated as a runtime control-plane capability rather than as functionality embedded independently within each AI application. This distinction becomes increasingly important as organizations operate multiple agents, models, tools, knowledge sources, and business applications. A centralized governance architecture also enables consistent policy semantics across heterogeneous AI workloads. Instead of implementing authorization, approval, compliance, and data-protection logic separately inside individual agents, these controls can be expressed through a common policy model and evaluated by a shared Policy Kernel. The architecture additionally establishes a boundary between autonomous execution and organizational control. Agents may perform autonomous reasoning and tool execution, while governance decisions remain subject to externally defined enterprise policies. This separation provides a mechanism for maintaining organizational authority over autonomous systems.

10.3

Relationship proaches

to

Existing

layer through which these mechanisms can be invoked as governance obligations associated with enterprise policies. Therefore, UPA should be viewed as complementary to existing policy engines, authorization systems, AI guardrails, and safety mechanisms rather than as a replacement for them.

10.4

Limitations

The proposed architecture also has several limitations. First, policy evaluation introduces additional runtime processing and therefore may increase latency for latencysensitive AI workloads. Although policy matching can be optimized through indexing, caching, and selective evaluation, large-scale deployments may require distributed policy-evaluation mechanisms. Second, the correctness of governance decisions depends on the quality and completeness of policy definitions. A Policy Kernel cannot enforce requirements that are not represented by applicable policies or governance controls. Third, runtime plugins introduce additional operational dependencies. A failed or unavailable governance provider may affect execution when the associated obligation is mandatory. Consequently, production deployments require explicit failure semantics, availability mechanisms, and observability for governance components. Finally, the current architecture defines the governance model and execution semantics but does not establish a complete formal verification framework for proving policy correctness or absence of conflicting governance rules. These aspects remain areas for future research.

10.5

Overall Discussion

The central implication of UPA is that Enterprise AI

Ap- governance can be modeled as a systematic architectural

layer spanning policy definition, semantic normalization, policy matching, decision evaluation, governance obligaExisting policy and authorization systems provide impor- tions, runtime enforcement, and human intervention. tant foundations for policy-based access control and auThis approach provides a foundation for governing authorization. Systems such as Cedar, OPA, and XACML tonomous AI systems without coupling governance logic demonstrate the value of declarative policies, structured directly to individual models or applications. The archipolicy evaluation, and separation between policy definitecture therefore provides a path toward consistent and tion and application logic. extensible governance across heterogeneous Enterprise AI UPA builds upon these principles while addressing a environments. broader governance scope for autonomous AI systems. In particular, the architecture extends policy evaluation beyond conventional authorization decisions to include runFuture Work time governance obligations, human approval, AI-specific 11 controls, and extensible governance plugins. Traditional AI safety mechanisms and guardrails gen- The current UPA architecture establishes a foundation erally focus on controlling model inputs, outputs, or un- for policy-driven governance of Enterprise AI systems. desirable model behavior. UPA does not replace such Several areas remain open for further research and immechanisms. Instead, it provides an architectural control plementation.

40

Prabhu et al.

execution cost, scalability, and human-approval effectiveness. Future work will investigate distributed Policy Kernel These studies can provide further evidence regarding architectures for large-scale Enterprise AI environments. the practical applicability of UPA in large-scale EnterMultiple policy evaluation nodes may operate across reprise AI deployments. gions, clouds, edge environments, or enterprise boundaries while maintaining consistent policy semantics. Research is required to address policy synchronization, version consistency, distributed caching, failure handling, 12 Conclusion and governance decision consistency across geographically distributed runtimes. Enterprise AI introduces a governance challenge that

11.1

11.2

Distributed Policy Kernels

Formal Policy Verification

A further research direction is the formal verification of DGPL policies and policy compositions. Verification techniques could be used to identify contradictory policies, unreachable rules, unintended privileges, incomplete governance coverage, and unsafe policy combinations before deployment. Formal reasoning over PARC-based policy requests and policy evaluation semantics may provide stronger guarantees regarding governance correctness.

11.3

Adaptive Governance Policies

Enterprise environments are dynamic, and governance requirements may change according to runtime conditions, organizational risk, workload characteristics, or regulatory requirements. Future work will therefore investigate adaptive policies capable of responding to changing context while preserving explicit enterprise control. Such mechanisms must balance adaptability with predictability, auditability, and deterministic governance semantics.

11.4

Governance Agents

for

Self-Governing

As autonomous agents increasingly perform planning, reasoning, tool selection, and multi-step execution, future research will examine governance mechanisms specifically designed for self-governing agent systems. This includes policy enforcement across agent planning cycles, delegation between agents, dynamic tool selection, agent-to-agent communication, and long-running autonomous workflows. A key research challenge is ensuring that increasing agent autonomy does not bypass enterprise governance controls.

11.5

Large-Scale Empirical Evaluation

Future work will also extend empirical evaluation across larger policy sets, additional enterprise domains, heterogeneous policy workloads, and distributed execution environments. Evaluation will consider policy-matching accuracy, evaluation latency, governance overhead, plugin

extends beyond traditional model safety, applicationlevel authorization, and conventional AI guardrails. Autonomous agents can access enterprise resources, invoke tools, process sensitive information, and execute multistep workflows, requiring governance mechanisms that operate consistently throughout the runtime lifecycle. This paper presented the Unified Policy Architecture (UPA), a reference architecture for lifecycle-wide governance of autonomous AI agents and LLM-based applications. UPA separates policy definition, semantic normalization, policy matching, policy evaluation, and runtime governance while maintaining a consistent governance model across heterogeneous enterprise environments. The Declarative Governance Policy Language (DGPL) provides a structured mechanism for expressing governance requirements, while the PARC model provides a common representation of Principal, Action, Resource, and Context for policy evaluation. The Policy Kernel evaluates these requests and produces governance decisions and obligations that can be enforced through runtime governance components, human approval mechanisms, and extensible plugins. The architecture establishes governance as an independent control-plane capability rather than functionality embedded within individual AI applications or models. This separation enables organizations to evolve governance requirements without requiring corresponding changes to every autonomous agent or application. UPA therefore provides a foundation for building Enterprise AI systems in which autonomy and organizational control can coexist. Future work will extend this foundation toward distributed policy evaluation, formal policy verification, adaptive governance, and governance mechanisms for increasingly autonomous and selfgoverning AI agents.

Acknowledgments The authors gratefully acknowledge Sriram Gopalan (DecisionFacts AI) for contributing the use case presented in the Appendix E and for his valuable feedback during the development of this work. The authors also thank Ashish Kar (Microsoft) for his constructive feedback and discussions that contributed to the refinement of the paper.

41

References

Prabhu et al.

[12] X. Wen, Y. Zhao, X. Xu, L. Chen, C. Xu, S. Chi, J. Ding, Z. Li, H. Li, L. Jiang, F. Liu, and Q. Xu, [1] OASIS eXtensible Access Control Markup Language “From craft to kernel: A governance-first execution (XACML) Technical Committee, “extensible access architecture and semantic isa for agentic computers,” control markup language (xacml) version 3.0,” arXiv preprint arXiv:2604.18652, 2026. OASIS, OASIS Standard, 2013. [Online]. Available: https://docs.oasis-open.org/xacml/3.0/xacml-3.0-c [13] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “React: Synergizing ore-spec-os-en.html reasoning and acting in language models,” in The [2] Open Policy Agent Contributors, “Open policy Eleventh International Conference on Learning Repagent,” https://www.openpolicyagent.org/, 2024, resentations (ICLR), 2023. accessed: 2026-08-02. [14] “Toolformer: Language models can teach themselves to use tools,” 2023. [3] T. Sandall, M. Butcher et al., “Opa: Open policy agent,” in Proceedings of KubeCon + CloudNativeCon. Cloud Native Computing Foundation, 2020. [15] “Autogen: Enabling next-gen llm applications via multi-agent conversation,” 2023. [4] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. [16] “Camel: Communicative agents for mind exploration Youman, “Role-based access control models,” IEEE of large language model society,” 2023. Computer, vol. 29, no. 2, pp. 38–47, 1996. [17] “Voyager: An open-ended embodied agent with large [5] V. C. Hu, D. Ferraiolo, D. R. Kuhn, and J. Voas, language models,” 2023. “Attribute-based access control,” Computer, vol. 48, no. 2, pp. 85–88, 2015. [18] U.S. Department of Health and Human Services, “HIPAA Security Rule,” https://www.hhs.gov/hi [6] P. W. L. Fong, “Relationship-based access control: paa/for-professionals/security/index.html, 2025, Protection model and policy language,” in Proceedaccessed: 2026-08-08. ings of the First ACM Conference on Data and Application Security and Privacy (CODASPY ’11). [19] KPMG, “RBI FREE-AI Committee Report on ACM, 2011, pp. 191–202. Framework for Responsible and Ethical Enablement of Artificial Intelligence,” https://kpmg.com/in/en [7] J. W. Cutler, C. Disselkoen, A. Eline, S. He, /insights/2025/08/rbi-f ree-ai-committee-report-o K. Headley, M. Hicks, K. Hietala, E. Ioannidis, J. H. n-f ramework-f or-responsible-and-ethical-enablem Kastner, A. Mamat, D. McAdams, M. McCutchen, ent-of-artif icial-intelligence.html, 2025, accessed: N. Rungta, E. Torlak, and A. M. Wells, “Cedar: A 2026-08-08. new language for expressive, fast, safe, and analyzable authorization,” Proceedings of the ACM on Programming Languages, vol. 8, no. OOPSLA1, pp. 1– 31, 2024. [8] Y. Bai, S. Kadavath, S. Kundu, A. Askell et al., “Constitutional ai: Harmlessness from ai feedback,” arXiv preprint arXiv:2212.08073, 2022. [9] T. Rebedea, R. Dinu, M. N. Sreedhar, C. Parisien, and J. Cohen, “Nemo guardrails: A toolkit for controllable and safe llm applications with programmable rails,” in Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing: System Demonstrations. Association for Computational Linguistics, 2023, pp. 431–445.

[10] OWASP Foundation, “Owasp top 10 for large language model applications,” https://genai.owasp.org/ llm-top-10/, 2025, oWASP GenAI Security Project. [11] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust architecture,” National Institute of Standards and Technology, NIST Special Publication 800-207, 2020.

42

A

Prabhu et al.

Reference DGPL Policies

This appendix presents representative policy examples written using the Declarative Governance Policy Language (DGPL). These examples illustrate the core PARC authorization model together with Enterprise AI governance capabilities including conditions, approval workflows, evaluation providers, and governance obligations. All examples are provided using the JSON serialization of DGPL.

A.1

Listing 9: Declarative Plugin Provider Configuration { "version": "2026-01-01", "statements": [ { "sid": "ProductionDelete", "effect": "Approve", "action": [ "db:delete" ], "resource": [ "database:production" ], "approval": { "role": "Admin" } } ]

Basic PARC Authorization Policy

The following example authorizes employees to query the HR knowledge base. Listing 7: Declarative Plugin Provider Configuration { "version": "2026-01-01", "statements": [ { "sid": "HRKnowledgeAccess", "effect": "Allow", "principal": { "Role": ["Employee"] }, "action": [ "rag:query" ], "resource": [ "knowledgebase:hr" ] } ]

}

A.4

The following policy executes governance obligations that redact personally identifiable information (PII) and secrets before the request is processed. Listing 10: Declarative Plugin Provider Configuration { "version": "2026-01-01", "statements": [ { "sid": "EnterpriseProtection", "effect": "Allow", "action": [ "llm:input" ], "resource": [ "*" ], "plugins": [ { "provider": "presidio", "mode": "redact" }, { "provider": "secret_scanner", "mode": "redact" } ] } ]

}

A.2

Conditional Policy

The following policy permits execution only during business hours. Listing 8: Declarative Plugin Provider Configuration { "version": "2026-01-01", "statements": [ { "sid": "BusinessHours", "effect": "Allow", "action": [ "*" ], "resource": [ "*" ], "condition": { "all": [ { "fact": "system.hour", "operator": "between", "value": [9,17] } ] } } ] }

A.3

Approval Workflow Policy

The following policy requires administrator approval before deleting a production database.

Governance Obligation Policy

}

A.5

Threat Detection Policy

The following policy invokes an LLM-based Threat Detection Provider to detect prompt injection and jailbreak attacks before policy evaluation is completed. Listing 11: Declarative Plugin Provider Configuration { "version": "2026-01-01", "statements": [ { "sid": "PromptInjection", "effect": "Deny", "action": [ "llm:input_review" ], "resource": [ "*" ], "threat": { "provider": "llm", "model": "gemini/gemini-2.5-flash",

43

Prabhu et al.

"threshold": 0.80, "categories": [ "PromptInjection", "Jailbreak" ] } }, { "sid": "AllowLLMRequests", "effect": "Allow", "action": [ "llm:input_review" ], "resource": [ "*" ] } ] }

A.6

Multi-Statement Policy

The following example illustrates a policy document containing multiple independent policy statements. Listing 12: Declarative Plugin Provider Configuration { "version": "2026-01-01", "statements": [ { "sid": "WiFiAccessForITAdmin", "effect": "Allow", "principal": { "Role": [ "ITAdmin" ] }, "action": [ "rag:query" ], "resource": [ "knowledgebase:wifi" ] }, { "sid": "HRAccessForEmployees", "effect": "Allow", "principal": { "Role": [ "Employee" ] }, "action": [ "rag:query" ], "resource": [ "knowledgebase:hr" ] } ] }

44

B

Prabhu et al.

EAGBench Benchmark

This appendix provides the detailed benchmark configuration and supporting results used to evaluate the policy governance capabilities described in this paper. The benchmark evaluates policy matching, governance decision accuracy, policy taxonomy coverage, business-case complexity, human-approval escalation, and policy evaluation latency across representative enterprise domains.

B.1

B.3

Enterprise Domain Distribution

The benchmark covers seven enterprise domains and 70 business cases. This distribution evaluates whether the governance model remains applicable across heterogeneous enterprise environments rather than being optimized for a single application domain.

Benchmark Overview

The benchmark consists of 1,400 policy-governance scenarios covering 70 business cases distributed across seven enterprise domains: • Enterprise Resource Planning (ERP) • Banking • Healthcare • Insurance • Government • Oil and Gas

Figure 7: Multi-axis policy taxonomy coverage across the seven enterprise domains.

• DevOps Each business case contains multiple governance scenarios designed to exercise different policy families and governance outcomes. The benchmark evaluates the Policy Kernel using the same PARC-based request representation and policy evaluation model defined in the main body of the paper.

B.2

B.4

Cross-Domain Accuracy and Human Approval

The benchmark contains 1,400 scenarios and reports an overall Policy Kernel accuracy of 94.1%. The evaluation also measures the rate at which scenarios are escalated for human approval across the enterprise domains.

Benchmark Dimensions

The benchmark evaluates the following dimensions: 1. Policy Matching: whether applicable policy statements are correctly identified for a normalized request. 2. Governance Decision: whether the Policy Kernel produces the expected governance outcome. 3. Policy Taxonomy Coverage: whether governance scenarios exercise defined policy families across enterprise domains. 4. Business Case Complexity: whether the benchmark represents varying levels of policy and governance complexity. Figure 8: Cross-domain Policy Kernel accuracy and human approval escalation across seven enterprise domains. 5. Human Approval Escalation: whether scenarios requiring organizational intervention are correctly The results provide an aggregate view of governance identified and escalated. decision accuracy while illustrating that human approval 6. Evaluation Latency: runtime latency associated remains an explicit governance mechanism for scenarios requiring organizational intervention. with policy evaluation across policy families.

45

B.5

Prabhu et al.

Business Case Complexity

The benchmark includes 70 business cases distributed across the seven enterprise domains. Scenario complexity is represented using the benchmark’s business-case complexity measure.

Figure 9: Business case complexity and volume distribution across the 70 benchmark business cases.

Figure 10: Ground-truth governance decision outcome distribution across the 1,400 benchmark scenarios.

The distribution demonstrates that the benchmark includes scenarios around the defined target complexity level rather than evaluating solely simple policy decisions.

B.6

Ground-Truth Decision Outcomes

The benchmark contains four primary governance outcomes: • Allow • Deny • Human Approval • Reject The distribution of these outcomes provides the ground-truth reference for evaluating Policy Kernel decision accuracy.

B.7

Policy Evaluation Latency

Policy evaluation latency was measured across the policy Figure 11: Policy Kernel evaluation latency distribution families represented in the benchmark. The latency dis- by policy family. tribution provides an indication of the runtime overhead associated with policy evaluation. The results provide a basis for evaluating the runtime characteristics of the governance layer and identifying policy families that may require additional optimization in large-scale deployments.

46

Prabhu et al.

B.8

Benchmark Interpretation

Governance Decision The Policy Kernel evaluates the query to an explicit approval state:

The benchmark results should be interpreted as an evaluation of the proposed governance architecture and Policy Kernel implementation under defined benchmark condiEval(q, Π) = (Approve, Γ) tions. The reported accuracy and latency values do not where obligations require: imply universal performance across all enterprise deployments. Γ = {Approval(FinanceDirector)} In particular, production performance may vary according to policy set size, policy complexity, request The autonomous workflow is suspended until human characteristics, runtime infrastructure, plugin execution, approval completes. caching strategy, and deployment architecture. The benchmark serves as an empirical evaluation of the EAGBench Scenario: ERP High-Value Approposed governance model and provides a reproducible proval basis for future experiments involving larger policy sets, Scenario: High-value purchase order approval additional enterprise domains, distributed Policy Kernels, P rincipal = Employee and complex autonomous-agent workloads. Action = purchase:approve

B.8.1

Resource = purchase-order:PO-1024

Example: ERP High-Value Purchase Approval

This scenario evaluates conditional human approval for high-value enterprise purchase orders. The policy requires Finance Director approval when the purchase amount exceeds the defined threshold. DGPL Policy

Context = purchase_amount = 1,500,000 Condition: 1,500,000 > 1,000,000

⇒

True

Decision: Approve Obligation: FinanceDirector Approval

{ "version": "2026-01-01", "statements": [ { "sid": "ERPHighValueApproval", "effect": "Approve", "condition": { "NumericGreaterThan": { "context.custom.purchase_amount": 1000000 } }, "action": [ "purchase:approve" ], "resource": [ "purchase-order:*" ], "approval": { "role": "FinanceDirector" } } ] }

Representative PARC Request For a purchase order with a purchase amount of 1,500,000, the normalized request is represented as: q = ⟨Employee, purchase:approve, PO-1024, C⟩ where context contains: C = {custom.purchase_amount = 1500000} Policy Matching The requested action (purchase:approve) and resource (purchase-order:PO-1024) match the policy declaration. Evaluating condition 1500000 > 1000000 resolves to True.

B.9

ERP Purchase Approval Benchmark Implementation

The Python implementation illustrates benchmark execution for the ERP purchase approval policy across five boundary scenarios. import asyncio from superagentx_policy_engine.policy_engine import PolicyEngine from superagentx_policy_engine.store.file_store import FilePolicyStore from superagentx_policy_engine.models.request import AuthorizationRequest from superagentx_policy_engine.models.principal import Principal from superagentx_policy_engine.models.principal_type import PrincipalType from superagentx_policy_engine.models.action import Action from superagentx_policy_engine.models.resource import Resource from superagentx_policy_engine.models.context import RequestContext TEST_CASES = [ { "id": "ERP-001", "description": "Purchase Amount > Rs. 10 Lakhs", "purchase_amount": 1500000, "expected": "Approve", }, { "id": "ERP-002", "description": "Purchase Amount = Rs. 25 Lakhs", "purchase_amount": 2500000, "expected": "Approve", }, { "id": "ERP-003", "description": "Purchase Amount = Rs. 50 Lakhs", "purchase_amount": 5000000, "expected": "Approve", }, { "id": "ERP-004", "description": "Purchase Amount < Rs. 10 Lakhs", "purchase_amount": 500000, "expected": "Deny", }, { "id": "ERP-005", "description": "Purchase Amount = Rs. 10 Lakhs", "purchase_amount": 1000000, "expected": "Deny", }, ] async def main(): engine = PolicyEngine() policy = FilePolicyStore.load( "examples/benchmark/erp/policies/high_approval.json"

47

Prabhu et al.

) await engine.add_policy_document(policy) passed = 0 for test in TEST_CASES: request = AuthorizationRequest( principal=Principal( id="john", type=PrincipalType.USER, roles=["ProcurementManager"], ), action=Action(name="purchase:approve"), resource=Resource( id="purchase-order:PO-1001", type="purchase-order", ), context=RequestContext( custom={"purchase_amount": test["purchase_amount"]} ), ) response = await engine.authorize(request) actual = response.decision result = ( "PASS" if actual.lower() == test["expected"].lower() else "FAIL" ) if result == "PASS": passed += 1 print(f"ID: {test[’id’]} | Result: {result} (Exp: {test[’expected’]}, Act: {actual})" ) if __name__ == "__main__": asyncio.run(main())

Listing 13: Benchmark

C.2

Agent Operations

• agent:execute • agent:delegate • agent:communicate • agent:terminate • agent:start • agent:pause • agent:resume • agent:handoff • agent:spawn

EAGBench ERP Purchase Approval

C.3

Tool Operations

• tool:invoke

C

Standardized Operation Identifier Reference

This appendix defines representative standardized operation identifiers used throughout the Unified Policy Architecture. Operation identifiers provide a consistent vocabulary for describing actions performed by users, agents, models, tools, applications, and enterprise systems. The identifiers follow a namespace-based convention:

• tool:execute • tool:list • tool:discover • tool:register • tool:authorize

namespace:operation For example, llm:input represents an input operation involving an LLM, while db:delete represents a database deletion operation. The identifiers defined below are representative and extensible rather than exhaustive.

C.1

LLM Operations

C.4

RAG and Knowledge Operations

• rag:query • rag:retrieve • rag:search

• llm:input

• rag:index

• llm:output

• rag:ingest

• llm:chat • llm:completion • llm:embedding • llm:inference

• rag:delete • knowledge:read • knowledge:write

• llm:stream

• knowledge:update

• llm:tool_call

• knowledge:delete

48

Prabhu et al.

C.5

Data Operations

C.8

API and Service Operations

• data:read

• api:invoke

• data:write

• api:read

• data:create

• api:write

• data:update • data:delete • data:export • data:import • data:share • data:transform

• api:create • api:update • api:delete • service:invoke • service:execute • service:discover

C.9 C.6

Database Operations

Identity and Access Operations

• identity:authenticate

• db:read

• identity:authorize

• db:write

• identity:assume

• db:create

• identity:delegate

• db:update

• identity:impersonate

• db:delete

• role:assign

• db:query

• role:revoke

• db:execute

• permission:grant

• db:backup • db:restore

C.7

File and Document Operations

• file:read • file:write • file:create

• permission:revoke

C.10

Workflow Operations

• workflow:start • workflow:execute • workflow:pause • workflow:resume • workflow:cancel

• file:update

• workflow:terminate

• file:delete

• workflow:approve

• file:upload

• workflow:reject

• file:download • file:share

C.11

Human Approval Operations

• approval:request

• document:read

• approval:approve

• document:process

• approval:reject

• document:classify

• approval:escalate

• document:extract

• approval:delegate

49

Prabhu et al.

C.12

Communication Operations

• communication:send • communication:receive • communication:share

C.15

Security Operations

• security:scan • security:inspect • security:validate • security:quarantine

• email:send

• security:block

• email:read

• security:unblock

• message:send • message:receive • notification:send

C.13

Network Operations

• network:connect • network:request • network:access

• secret:detect • secret:redact • pii:detect • pii:redact

C.16

Governance Operations

• policy:evaluate • policy:match • policy:validate • policy:create

• network:transfer

• policy:update

• network:resolve

• policy:delete • policy:publish

C.14

Cloud and Infrastructure Operations

• cloud:provision • cloud:deploy • cloud:terminate • compute:create • compute:execute • compute:terminate

• policy:rollback • governance:approve • governance:deny • governance:audit • governance:escalate

C.17

Audit and Observability Operations

• audit:record • audit:read

• container:create

• audit:export

• container:execute

• audit:delete

• container:terminate • storage:read

• log:write • log:read • trace:create

• storage:write

• trace:read

• storage:delete

• metric:read

50

Prabhu et al.

C.18

Business Operations

C.20

Relationship to PARC

Enterprise applications may also define domain-specific Operation identifiers form the Action component of the PARC request model. operation identifiers. Representative examples include: For example: • finance:transfer • finance:approve

P ARC = ⟨ITAdmin, rag:query, knowledgebase:wifi, Context⟩

• finance:refund

Here:

• hr:read

• Principal: ITAdmin

• hr:update

• Action: rag:query

• hr:approve

• Resource: knowledgebase:wifi

• procurement:create

• Context: runtime evaluation context

• procurement:approve • procurement:purchase • customer:read • customer:update • customer:delete Domain-specific identifiers allow organizations to extend the operation vocabulary without modifying the fundamental PARC model or DGPL evaluation semantics.

C.19

The operation identifier therefore provides a standardized vocabulary for the Action dimension while remaining independent of the policy statement’s Statement Identifier.

C.21

Statement Identifier and Operation Identifier

The sid field of a DGPL statement and an operation identifier serve different purposes. For example: { "sid": "WiFiAccessForITAdmin", "effect": "Allow", "action": [ "rag:query" ], "resource": [ "knowledgebase:wifi" ]

Identifier Naming Convention

Standardized operation identifiers use a namespace and operation separated by a colon: }

namespace:operation For example:

In this example:

• llm:input

• WiFiAccessForITAdmin is the Statement Identifier.

• agent:execute

• rag:query is the Operation Identifier.

• rag:query • db:delete • file:read • approval:approve

The Statement Identifier identifies the policy statement, whereas the Operation Identifier identifies the action being governed. This distinction allows multiple policy statements to govern the same operation while retaining independent statement identity and traceability.

The namespace identifies the operation domain, while D DGPL Grammar Reference the operation identifies the requested activity. The identifier vocabulary is extensible. Organiza- This appendix summarizes the complete DGPL statement tions may introduce additional namespaces and opera- schema. tions when required by domain-specific applications, provided that identifiers remain unambiguous and consistent Statement = ⟨SID, Ef f ect, P ARC, Extensions⟩ with the governance model.

51

Prabhu et al.

where P ARC = ⟨P rincipal, Action, Resource, Condition⟩. The Governance Extensions currently include • Threat Detection

and other writable resources may constitute communication channels when information can flow between principals through them. This definition is intentionally resource-centric. It avoids requiring the governance system to predict whether an application developer intended a particular resource to function as a communication mechanism.

• Governance Plugins

E.1.2

• Approval Workflows

The extended SID registry may include the following A2A operations:

• Future Extensions

E

• a2a:send • a2a:receive

Extended Governance Models and Case Studies

This appendix presents extended governance constructs that complement the Unified Policy Architecture (UPA) described in the main body of the paper. These constructs extend the core policy model to address multiagent coordination, provenance, stateful governance, policy pre-flight evaluation, offline assurance, and domainspecific governance requirements. The purpose of this appendix is to provide additional formal models, policy examples, and case-study material without making these extensions necessary for the core UPA architecture. Some constructs presented here represent proposed extensions and future implementation directions rather than capabilities evaluated in the current benchmark.

E.1

Extended Agent-to-Agent nance Model

A2A Action Namespace

• a2a:broadcast • a2a:discover • a2a:delegate • a2a:handoff These operations provide explicit governance points for communication, delegation, discovery, and transfer of control between agents. For example, a policy may constrain an agent from communicating with another agent outside an approved organizational boundary: Listing 14: Illustrative A2A communication policy { "version": "2026-01-01", "statements": [ { "sid": "DenyUntrustedA2ACommunication", "effect": "Deny", "action": [ "a2a:send", "a2a:broadcast", "a2a:handoff" ], "resource": [ "channel:external-*" ], "condition": { "fact": "principal.trust_domain", "operator": "not_equals", "value": "enterprise" } } ]

Gover-

The core UPA model treats agents, tools, workflows, and enterprise resources as governed entities. In multi-agent environments, however, governance must also account for interactions between agents. Agent-to-agent (A2A) communication introduces coordination behavior that cannot always be captured by evaluating isolated agent actions. The extended model therefore introduces communication channels as first-class governed resources. }

E.1.1

Communication Channels as Resources

The example illustrates the distinction between authorization of an individual operation and governance of the communication topology through which agents interact.

Let the resource universe be extended as: Rs ⊇ {Channel, Agent, Session, Run}.

(1)

A communication channel is defined operationally as any resource that can be written by one principal and subsequently read by another principal. Under this definition, a channel need not be an explicit messaging service. Shared repositories, object-store prefixes, caches, directories, shared datasets, workflow artifacts,

E.2

Provenance-Extended Model

Request

The canonical UPA request model is represented using the Principal–Action–Resource–Context (PARC) abstraction. For multi-agent and cross-run governance, an additional provenance dimension can be introduced.

52

Prabhu et al.

The extended request is: p = ⟨pr, ac, re, ct, ρ⟩,

(2)

where ρ represents provenance information associated with the inputs relevant to the governed operation. Provenance may describe the origin and lineage of credentials, artifacts, instructions, retrieved information, and other security-relevant data. The provenance model allows the Policy Kernel to distinguish between, for example, an enterprise-issued credential and a credential discovered through a shared workspace or another agent.

on how many distinct principals have accessed the same resource during a defined period. The extended evaluation model therefore introduces bounded governance state Σ: Eval : P × Π × Φ × Σ → D × Γ × Σ′ ,

(3)

where: • P is the normalized request space, • Π is the applicable policy set, • Φ is the evaluation-fact space, • Σ is the current governance state,

E.2.1

Provenance-Aware Policy

• D is the policy decision,

An illustrative policy is:

• Γ is the resulting obligation set, and

Listing 15: Illustrative provenance-aware credential policy { "sid": "DenyUntrustedProvenanceCredential", "effect": "Deny", "action": [ "api:invoke", "network:request", "identity:assume" ], "resource": ["*"], "condition": { "any": [ { "fact": "provenance.credential.origin", "operator": "not_equals", "value": "enterprise_issuer" }, { "fact": "provenance.credential.discovered_via", "operator": "in", "value": [ "shared_workspace", "public_dataset", "peer_agent", "paste_service" ] } ] }, "fail_closed": true }

• Σ′ is the updated governance state. Governance state should be bounded, auditable, versioned, and scoped appropriately, for example by tenant, agent family, execution run, or communication channel. Illustrative state facts include: • state.channel.distinct_principals_24h • state.agent.cumulative_reasoning_tokens • state.run.denied_attempts • state.resource.write_read_fanout • state.task.consecutive_failures The introduction of Σ changes the interpretation of determinism. Policy evaluation remains deterministic conditional on the complete evaluation input: Eval(p, Π, Φ, Σ) = Eval(p, Π, Φ, Σ).

(4)

Consequently, reproducibility requires the governance state used during evaluation to be retained as an auditable input. This property is more accurately characterized as replay determinism than purely stateless determinism.

The policy illustrates an important governance distinction: possession of a credential does not necessarily establish that the credential is trusted for subsequent use. Provenance provides an additional basis for policy evaluE.3.1 Aggregate-Behavior Policy ation. The provenance extension should be understood as a An example of state-aware governance is: proposed extension to the core PARC model rather than Listing 16: Illustrative emergent-channel detection policy as a requirement for every UPA deployment. {

E.3

Governance State and Stateful Evaluation

Stateless evaluation provides useful determinism and reproducibility, but certain governance properties depend on aggregate behavior across multiple requests. For example, the significance of a write operation may depend

"sid": "EmergentChannelDetection", "effect": "Approve", "action": [ "file:write", "file:create", "data:write" ], "resource": [ "artifact-store:*", "cache:*", "dataset:*"

53

Prabhu et al.

], "condition": { "all": [ { "fact": "state.resource.distinct_writer_principals_24h", "operator": "greater_than", "value": 5 }, { "fact": "state.resource.cross_principal_read_after_write", "operator": "equal", "value": true }, { "fact": "resource.declared_purpose", "operator": "not_equals", "value": "collaboration_channel" } ] }, "approval": { "role": "AIPlatformSecurityOfficer" }, "plugins": [ { "provider": "audit_logger", "mode": "record" } ]

This example treats persistence and repeated boundary exploration as governance-relevant runtime behavior rather than purely as performance characteristics.

E.5

Mediation Completeness

UPA governance guarantees apply only to operations that pass through a Governance Enforcement Point (GEP). Let Omed denote the set of operations mediated by the governance layer. Property 7 (Mediation Completeness). UPA governance guarantees hold only for operations: o ∈ Omed .

(5)

o∈ / Omed ,

(6)

For an operation:

no UPA governance decision exists, and the defaultdeny rule does not apply. } This property is important because a policy engine cannot govern an operation that never reaches the policy enThe policy demonstrates how aggregate behavior can forcement surface. become a governance condition even when each individual A deployment should therefore perform an unmediatedoperation would otherwise appear permissible. path audit that enumerates every path through which a governed workload can affect state outside its declared boundary. Each path should be classified as:

E.4

Persistence and Escalation Governance

1. mediated,

2. explicitly blocked, or Agent persistence can also be incorporated into governance state. An agent repeatedly failing to complete a 3. accepted risk. task while increasing its resource consumption or expanding its operational scope may require additional approval. This provides a deployment-level coverage criterion for An illustrative policy is: governance enforcement. Listing 17: Illustrative persistence-budget escalation policy { "sid": "PersistenceBudgetEscalation", "effect": "Approve", "action": ["*"], "resource": ["*"], "condition": { "all": [ { "fact": "state.task.consecutive_failures", "operator": "greater_than", "value": 12 }, { "fact": "state.agent.cumulative_reasoning_tokens", "operator": "greater_than", "value": 2000000 }, { "fact": "state.agent.out_of_scope_probe_count", "operator": "greater_than", "value": 0 } ] }, "approval": { "role": "ResearchOversight" } }

E.6

Kernel Integrity and Trust Boundary

The Policy Kernel itself represents a security-critical component. Governed workloads should therefore not be permitted to modify or directly access the resources that define governance semantics. The following constraints are recommended: • The Policy Kernel, policy store, SID registry, and governance evidence store should not be reachable as ordinary resources by governed workloads. • Governance evidence should be append-only and tamper-evident. • Obligation failures should be fail-closed by default for security-critical obligations. • Any opt-out from fail-closed behavior should be explicit, auditable, and policy-specific. • The Policy Kernel should not rely exclusively on identity assertions generated inside the same security boundary as the governed workload.

54

Prabhu et al.

These constraints establish the Policy Kernel as a trusted governance component rather than simply another application service.

E.7

UPA as a Governance Tool

• advisory results must not be treated as authorization credentials; and • authoritative enforcement must remain at the Governance Enforcement Point.

Thus, pre-flight evaluation is a convenience and planUPA may be exposed through multiple operational ning mechanism, not a substitute for enforcement. modalities. These modalities complement the enforcement architecture but do not replace the authoritative E.7.3 Offline Assurance and Red-Team Evaluaenforcement point. tion A third modality uses the Policy Kernel for offline analysis of historical event streams. In the primary architecture, the Policy Kernel operates Given a normalized event sequence: as a control plane at Governance Enforcement Points. Agents and applications invoke governed operations withE = {e1 , e2 , . . . , en }, (7) out requiring direct knowledge of the internal policy imthe governance engine can evaluate the sequence plementation. against a candidate policy set and identify: This is the only modality that provides the authoritative governance decision for execution. • operations that would have been denied; E.7.1

Enforcement Service

E.7.2

Agent-Callable Pre-Flight Evaluation

A second modality exposes a policy evaluation operation to an agent before it commits to a planned action. For example: Listing 18: Illustrative policy pre-flight policy { "sid": "AllowPolicyPreflight", "effect": "Allow", "principal": { "Type": ["AIAgent"] }, "action": [ "policy:evaluate" ], "resource": [ "policy-kernel:preflight" ], "plugins": [ { "provider": "rate_limiter", "mode": "enforce", "config": { "per_run": 50 } }, { "provider": "audit_logger", "mode": "record" } ] }

Pre-flight evaluation can make governance constraints visible to an agent planner before execution. It can also capture an explicit representation of intended action before the corresponding runtime events occur. However, a pre-flight interface introduces a policyprobing risk. Therefore: • pre-flight requests should be rate-limited; • the interface should avoid exposing unnecessary policy internals such as matched policy identifiers;

• operations requiring approval; • obligations that would have been generated; • events with no applicable policy; • potential unmediated paths; and • policy coverage gaps. This enables counterfactual governance analysis without modifying the original execution. Such replay can also support continuous red-team evaluation in which agents search for execution paths that violate specified governance invariants.

E.8

Financial Crime and Dispute Management Harness

Financial crime and dispute-management workflows provide a useful domain for demonstrating governance requirements that extend beyond authorization. In such workflows, automated decisions may influence which cases are reviewed, which customers receive provisional credits, which transactions are blocked, and which outcomes become available as training labels. E.8.1

Selective-Label Governance

An important distinction is that an unreviewed case should not automatically be interpreted as a negative outcome. A governance-aware system can distinguish between: • confirmed loss; • analyst disposition; • unresolved;

55

Prabhu et al.

• unobserved because intervention occurred. The fourth category explicitly records situations in which the intervention itself prevented the underlying outcome from becoming observable. This distinction is relevant to model development because the distribution of observed labels can depend on the operational policy used to select cases for intervention. E.8.2

Table 10: Illustrative governance boundaries for a dispute-management harness. Role

Principal

Proposer

AIAgent / ProposerRole

Implementer

AIAgent / ImplementerRole

Executor

AIAgent / ExecutorRole

Analyst

AIAgent / AnalystRole

Validator

Human / ModelRiskValidator

Reference Harness

A governance-oriented dispute-management harness may incorporate: • multiple label bands; • a randomized non-intervention slice; • inverse-propensity weighting; • temporally separated training, selection, and blind evaluation windows; • role separation among proposer, implementer, executor, and analyst; • explicit fairness straints;

and

operational-capacity

con-

• disturbance and drift scenarios; • deterministic artifact generation; and • an append-only execution ledger. These controls transform governance requirements from procedural guidance into enforceable runtime constraints. E.8.3

Representative Boundary May read summary information and create specifications; cannot access raw data or blind evaluation windows. May fit models on designated replay data; cannot access objective functions or blind data. May evaluate models and append execution evidence; cannot modify selection authority. May inspect governance records and create directives; cannot access restricted artifacts. May review artifacts and approve governed promotion decisions.

{ "fact": "state.run.blind_reads", "operator": "greater_than", "value": 0 }, {

Role Governance

"fact": "context.artifact_frozen", "operator": "equal", "value": false

An illustrative role mapping is shown below.

} ]

E.8.4

}, "fail_closed": true, "plugins": [ { "provider": "audit_logger", "mode": "record" } ]

Blind-Window Isolation

The blind evaluation window can be treated as a firstclass governed resource. Listing 19: Illustrative blind-window isolation policy }

{ "sid": "BlindWindowIsolation", "effect": "Deny", "principal": { "Type": ["AIAgent"] }, "action": [ "data:read", "model:fit", "model:evaluate", "rag:query" ], "resource": [ "window:BLIND" ], "condition": { "any": [

The example demonstrates how a procedural requirement can become a declarative governance rule.

E.9

Extended Financial Crime Policy Pack

An illustrative Financial Crime / Dispute Management policy pack may define domain-specific actions such as: • dispute:file

56

Prabhu et al.

• dispute:triage

E.10.2

• dispute:represent

A privacy policy may attach transformation and evidence obligations to LLM inputs:

• dispute:credit_provisional • dispute:deny

Listing 21: Illustrative privacy protection policy { "sid": "FinCrimeInputProtection", "effect": "Allow", "action": [ "llm:input" ], "resource": [ "*" ], "plugins": [ { "provider": "presidio", "mode": "redact" }, { "provider": "pseudonymiser", "mode": "tokenise", "config": { "fields": [ "customer_id", "merchant_id", "institution_id" ], "salt_scope": "run" } }, { "provider": "audit_logger", "mode": "record" } ]

• transaction:block • transaction:hold • case:escalate • label:emit • population:audit_sample The policy pack may associate autonomous decisions with governance obligations including: 1. Evidence generation — record the normalized request, matched policy statements, relevant evaluation facts, model version, and artifact integrity information. 2. Label provenance — identify whether an outcome represents confirmed loss, analyst disposition, unresolved status, or an outcome that became unobservable because intervention occurred. 3. Exploration reserve — preserve a bounded, randomized non-intervention sample under explicit governance. 4. Maturity gate — prevent model retraining or promotion when the available outcome window has not matured sufficiently. These mechanisms illustrate how industry policy packs can encode governance controls beyond conventional access authorization.

E.10

Additional Extended Policies

E.10.1

Denying Leakage-Prone Features

Privacy Protection Obligation

}

The example demonstrates that a permitted operation can still carry mandatory governance obligations. E.10.3

Fairness and Capacity Constraints

Governance conditions can also constrain promotion of detection artifacts: Listing 22: Illustrative fairness and capacity policy { "sid": "FairnessConstraintOnDetectionArtifact", "effect": "Deny", "action": [ "model:promote", "policy:publish" ], "resource": [ "detection-artifact:*" ], "condition": { "any": [ { "fact": "fairness.min_disparate_impact", "operator": "less_than", "value": 0.80 }, { "fact": "performance.max_segment_fp", "operator": "greater_than", "value": 0.06 }, { "fact": "operations.alert_rate", "operator": "greater_than", "value": 0.05 } ] }

A policy may prohibit the use of features that would leak information from restricted evaluation windows: Listing 20: Illustrative feature-leakage policy { "sid": "DenyLeakageFeatures", "effect": "Deny", "action": [ "feature:use", "model:fit" ], "resource": [ "feature:prior_confirmed_abuse", "feature:ring_linked", "feature:exculpatory_evidence" ] } }

57

Prabhu et al.

The numerical thresholds in this example are illustra- Table 11: Proposed governance-specific benchmark mettive and should not be interpreted as universal regulatory rics. or operational thresholds. Metric Evaluation Question Label-provenance What fraction of autoE.11 Human Approval Boundaries completeness mated decisions emit an appropriate observabilityCertain operations may require explicit human approval band record? rather than fully autonomous execution. Exploration-reserve Is the mandated nonFor example: compliance intervention sample preserved under operational Listing 23: Illustrative human approval boundary pressure? { Leakage-attempt interAre restricted blind"sid": "DetectionArtifactPromotion", ception window and excluded"effect": "Approve", "action": [ feature accesses denied? "model:promote" Constraint-breach con- Are fairness and ], "resource": [ tainment operational-capacity "detection-artifact:*" violations detected before ], "approval": { artifact promotion? "role": "ModelRiskValidator" Evidence recon- Can the complete gover}, "plugins": [ structability nance decision chain be re{ constructed from the evi"provider": "evidence_generator", "mode": "model_card" dence log? }, Approval-boundary in- Did irreversible actions { "provider": "integrity_verifier", tegrity execute without the re"mode": "sha256" quired approval? } ] }

The Approve effect represents a governance require- E.13 Incident-Replay Evaluation as Future Work ment for human authorization and is distinct from an ordinary Allow decision. The extended UPA model also enables counterfactual replay of historical agentic incidents. Given a timestamped event sequence from an incident, E.12 Benchmark Extensions each event can be normalized into the UPA request model The existing EAGBench benchmark evaluates enterprise and evaluated against a candidate policy set. The resultgovernance scenarios across multiple domains. The ex- ing analysis can identify: tended governance model suggests additional benchmark 1. which events would have been denied; dimensions for evaluating properties that cannot be captured by decision accuracy alone. 2. which events would have required human approval; A future Financial Crime / Dispute Management benchmark extension may 3. which obligations would have been generated; include the following metrics. 4. which events lacked sufficient provenance; For A2A governance, additional metrics may include: • mediation coverage; • channel-formation detection latency; • cross-run credential-reuse denial rate; • provenance-policy interception rate; and • time-to-containment. These metrics are proposed extensions and require independent implementation and experimental validation before being presented as empirical benchmark results.

5. which operations occurred outside the mediated enforcement surface; and 6. where governance state would have triggered escalation. Such an evaluation should be interpreted as a counterfactual analysis, not as evidence that UPA would necessarily have prevented the original incident. Applicationlayer governance cannot by itself guarantee containment of host-level compromise, kernel compromise, or other attacks that bypass the governance enforcement surface. The defensible objective is instead to determine whether the governance architecture can express, enforce,

58

Prabhu et al.

and evidence the relevant coordination and execution con- network isolation, runtime sandboxing, or other independent security controls. Governance enforcement is straints. strongest when combined with these layers and when the mediation surface is explicitly audited. E.14 Extended SID Namespace The following namespaces represent candidate extensions to the UPA SID registry. Table 12: Candidate extended SID namespaces. Namespace a2a:* dispute:* transaction:* case:* label:* population:*

Representative Operations send, receive, broadcast, discover, delegate, handoff file, triage, represent, credit_provisional, deny block, hold escalate emit audit_sample

These namespaces are proposed extensions and should be incorporated into the normative SID registry only after their semantics and interoperability requirements are established.

E.15

Scope of the Extended Model

The extensions in this appendix deliberately distinguish between the core UPA architecture and proposed capabilities. The core architecture establishes a policy-centric governance layer for Enterprise AI execution. The extensions presented here investigate how the same abstraction can be expanded to cover: • multi-agent communication; • information provenance; • aggregate runtime behavior; • governance-state-dependent decisions; • pre-flight policy evaluation; • offline policy assurance; • domain-specific governance; • selective-label controls; • human approval boundaries; and • governance-specific benchmarking. These extensions should therefore be viewed as an extensibility demonstration of UPA rather than as claims that every capability is already implemented or empirically validated. In particular, UPA should not be interpreted as a complete substitute for host security, identity infrastructure,

Related documents

• A Unified Policy Architecture (UPA): The Governance Kernel for Enterprise AI Operating Systems#974657
• The Policy Analysis Process#11073
• The Policy Analysis Process#11072
• Artificial Intelligence and Administrative Law in Modern Governance#1176326
• Editorial to “Decision theory and the future of AI”#748864