A Unified Policy Architecture (UPA): The Governance Kernel for Enterprise AI Operating Systems
Organizations: SuperAgentX AI
Abstract
Enterprise AI is evolving into an Enterprise Operating System where autonomous AI agents can plan, reason, use memory, invoke tools, execute workflows, and collaborate with other agents. This shift creates a new governance challenge: existing authorization, security, guardrails, and compliance mechanisms are fragmented and are not designed to govern autonomous AI as a unified system. This paper introduces the Unified Policy Architecture (UPA), a governance architecture for Enterprise AI Operating Systems. UPA provides a unified policy model for governing AI and agents, tools, workflows, memory, enterprise resources, and agent-to-agent interactions and enterprise business rules. It extends policy control beyond authorisation to include runtime obligations, human approvals, compliance, audit evidence, and governance evaluation. We present UPA's governance model, declarative policy language foundations, policy evaluation semantics, extensible plugins, industry policy packs, and an evaluation framework for enterprise governance. We also identify extensions for multi-agent coordination, provenance-aware policies, and stateful runtime governance. UPA provides a foundation for building secure, accountable, and governable Enterprise Operating Systems for autonomous AI.
Figures & tables
| Approach | Primary Focus | Primary Governance Scope | Relationship to UPA |
|---|---|---|---|
| RBAC | Role-based authorization | Permissions associated with roles | Authorization foundation |
| ABAC | Attribute-based authorization | Principal, resource, action, and environmental attributes | Context-aware policy foundation |
| ReBAC | Relationship-based authorization | Relationships among principals and resources | Relationship-aware authorization mechanism |
| XACML | Declarative access-control policy | Policy evaluation, combining algorithms, obligations, and advice | Important foundation for declarative governance |
| OPA / Rego | General-purpose Policy-as-Code | Structured policy evaluation across systems | External policy decision mechanism that can serve governance use cases |
| Cedar | Formal authorization | Principal-action-resource-context authorization | Authorization foundation and PARC model |
| Industry | Primary Governance Focus | Example Regulatory / Standards Context |
|---|---|---|
| Healthcare | Patient-record access, treatment relationship, sensitive-data disclosure | HIPAA Privacy and Security Rules [ 18 ] |
| Finance / Banking | Transaction authorization, fraud response, high-risk transaction approval | PCI DSS and applicable financial-sector requirements [ 19 ] |
| Manufacturing | Production-system access, machinery control, operational safety | ISO 12100 and applicable safety requirements |
| Government | Citizen-data access, sensitive records, controlled administrative operations | Applicable public-sector and data-protection requirements |
| Human Resources | Employee records, payroll operations, sensitive workforce information | Applicable employment and data-protection requirements |
| Oil and Gas | Pipeline operations, equipment control, emergency response and safety-critical actions | Applicable process-safety and HSE requirements |
| No. | Evaluation Dimension | Purpose |
|---|---|---|
| 1 | Correctness | Checks whether the Policy Engine returns the expected Allow , Deny , or Approve decision. |
| 2 | Latency | Measures the time required to evaluate one authorization request and return a decision. |
| 3 | Policy Repository Scalability | Checks performance as the number of policy statements increases. |
| 4 | Concurrent Request Scalability | Checks whether multiple authorization requests can be handled without failures. |
| 5 | Plugin Execution Overhead | Measures additional latency introduced by governance plugins. |
| 6 | Interoperability / Normalization | Checks whether different runtime inputs can be converted into a common authorization request. |
| Test ID | Scenario | Exp. | Act. | Res. |
|---|---|---|---|---|
| COR-01 | Matching Allow policy | Allow | Allow | Pass |
| COR-02 | Action mismatch | Deny | Deny | Pass |
| COR-03 | Resource mismatch | Deny | Deny | Pass |
| COR-04 | Principal mismatch | Deny | Deny | Pass |
| COR-05 | Deny overrides Allow | Deny | Deny | Pass |
| COR-06 | Approve overrides Allow | Approve | Approve | Pass |
| Policies | Mean | Median | P95 | P99 | Max |
|---|---|---|---|---|---|
| 10 | 0.0689 | 0.0612 | 0.0837 | 0.1103 | 0.6170 |
| 100 | 0.4650 | 0.4003 | 0.8408 | 1.2113 | 1.5430 |
| 500 | 4.0484 | 2.3851 | 3.4456 | 74.9523 | 94.3876 |
| 1,000 | 4.7721 | 3.1485 | 4.4085 | 54.3665 | 59.1441 |
| 5,000 | 32.1788 | 17.2241 | 108.2480 | 141.9245 | 145.4172 |
| Policies | req/s | Median (ms) | Observation |
|---|---|---|---|
| 10 | 14,519.60 | 0.0612 | Very small repository |
| 100 | 2,150.54 | 0.4003 | Low evaluation cost |
| 500 | 247.01 | 2.3851 | Higher scan cost |
| 1,000 | 209.55 | 3.1485 | Low median latency |
| 5,000 | 31.08 | 17.2241 | Scan becomes costly |
| Conc. | Reqs | Succ. | Fail | Req/s | Mean(ms) | P95(ms) |
|---|---|---|---|---|---|---|
| 1 | 10 | 10 | 0 | 101.60 | 9.3856 | 35.1700 |
| 10 | 100 | 100 | 0 | 178.03 | 5.2143 | 5.9975 |
| 25 | 250 | 250 | 0 | 209.71 | 4.4762 | 5.4775 |
| 50 | 500 | 500 | 0 | 237.96 | 3.9737 | 5.1276 |
| 100 | 1,000 | 1,000 | 0 | 236.27 | 4.0023 | 4.3574 |
| Configuration | Mean | Median | P95 | Overhead |
|---|---|---|---|---|
| No plugins | 0.0379 | 0.0350 | 0.0604 | 0.0000 |
| Presidio only | 2398.5800 | 2195.5687 | 4128.9392 | 2398.5421 |
| Secret scanner only | 0.0471 | 0.0460 | 0.0540 | 0.0092 |
| Presidio + Secret scan | 1916.9712 | 1609.6492 | 3294.6966 | 1916.9333 |
| Field | Expected | Generated | Result |
|---|---|---|---|
| Principal | user-001 / User | user-001 / User | Pass |
| Action | db:read | db:read | Pass |
| Res. Type | database | database | Pass |
| Res. ID | sales | sales | Pass |
| Intent | read_data | read_data | Pass |
| Domain | database | database | Pass |
Appendix figures & tables8 assets
Supplementary material from the paper’s appendix.
Appendix
| Role | Principal | Representative Boundary |
|---|---|---|
| Proposer | AIAgent / ProposerRole | May read summary information and create specifications; cannot access raw data or blind evaluation windows. |
| Implementer | AIAgent / ImplementerRole | May fit models on designated replay data; cannot access objective functions or blind data. |
| Executor | AIAgent / ExecutorRole | May evaluate models and append execution evidence; cannot modify selection authority. |
| Analyst | AIAgent / AnalystRole | May inspect governance records and create directives; cannot access restricted artifacts. |
| Validator | Human / ModelRiskValidator | May review artifacts and approve governed promotion decisions. |
| Metric | Evaluation Question |
|---|---|
| Label-provenance completeness | What fraction of automated decisions emit an appropriate observability-band record? |
| Exploration-reserve compliance | Is the mandated non-intervention sample preserved under operational pressure? |
| Leakage-attempt interception | Are restricted blind-window and excluded-feature accesses denied? |
| Constraint-breach containment | Are fairness and operational-capacity violations detected before artifact promotion? |
| Evidence reconstructability | Can the complete governance decision chain be reconstructed from the evidence log? |
| Approval-boundary integrity | Did irreversible actions execute without the required approval? |
| Namespace | Representative Operations |
|---|---|
| a2a:* | send , receive , broadcast , discover , delegate , handoff |
| dispute:* | file , triage , represent , credit_provisional , deny |
| transaction:* | block , hold |
| case:* | escalate |
| label:* | emit |
| population:* | audit_sample |
AI Agent Governance
AI agent governance studies how to authorize, constrain, monitor, and hold autonomous and multi-agent systems accountable.
See all 445 papers