Static and Runtime Policy Enforcement

• Policy models are formal frameworks that define rules and mechanisms for enforcing security policies both at design-time (static) and execution-time (runtime).
• Static enforcement employs techniques like type checking and static analysis to preemptively eliminate potential policy violations before the system runs.
• Runtime enforcement uses monitors, interposition, and logging to dynamically mediate actions, balancing precision and performance in live environments.

A policy model provides a formal mechanism for specifying, reasoning about, and enforcing security, access control, or regulatory properties at both design-time (static enforcement) and execution-time (runtime enforcement). The distinction between static and runtime enforcement is foundational in the design and assurance of secure systems, as each paradigm presents different trade-offs in precision, efficiency, and enforceability. Advanced enforcement models in contemporary research span program transformation, runtime interposition, dynamic tainting, multiparty computation, and machine-readable governance artifacts.

1. Formal Foundations: Policy Model, Enforcement Definitions, and Lattice Control

Policy languages define what is permitted or forbidden within a system, typically as sets of rules, constraints, or logical relations. Enforcement mechanisms are sound implementations that ensure policies are respected by either refusing, modifying, or instrumenting potentially violating operations.

Static enforcement is performed prior to execution through type checking, static analysis, or syntactic rule matching. A capability or operation is statically allowed if, across all possible states or data instances, it cannot violate policy constraints. Formally, for an update capability $U$ and policy $P$, static allowance requires $U\llbracket U\rrbracket(T') \subseteq [[P]](T')$ for all $T'$ (Cheney, 2013).

Runtime enforcement instead observes or mediates actions during execution. This can be realized via runtime monitors, edit automata, interposition layers, instrumentation hooks, or secure multi-execution (SME). Each runtime monitor is characterized by its "action-control lattice," which defines the manipulations available to the monitor for each action (insert, suppress, observe, etc.) (Khoury et al., 2015).

The control lattice comprises:

• Completely controllable actions (C): monitor may insert and suppress.
• Insertable-only actions (I): monitor may insert but not suppress.
• Deletable-only actions (D): monitor may suppress but not insert.
• Observable-only actions (O): monitor may observe but not alter.

This control structure determines which classes of properties (safety, liveness, renewal, corner-case) are enforceable in principle. A master theorem formalizes the necessary and sufficient conditions for enforceability as the union of three property classes under the action lattice (Khoury et al., 2015).

2. Static Enforcement: Algorithms, Expressiveness, and Complexity

Static enforcement techniques reject or transform programs or operations that could violate a policy, guaranteeing policy adherence without runtime overhead. Classic instances include access control for databases, privacy policy enforcement in secure computation languages, and design-time validation of machine-readable artifacts.

A canonical example is static enforcement of XPath-based access control policies for XML databases (Cheney, 2013). Policies are defined over update capabilities abstracted by XPath expressions. The main static enforcement decision is whether a capability can ever cause a policy violation in any possible instance. This reduces to containment and emptiness checks over XPath fragments. For a policy $P=(−,−,A,D)$ and capability $p$, the test is:

• $p$ is contained in some allow rule $a\in A$.
• $p$ does not overlap any deny rule $d\in D$.

Enforcement is precise (static and dynamic allow the same actions) if and only if the policy is "fair," formalized as openness in the topology generated by the XPath fragment. Deciding fairness is coNP-complete, and enforcement itself can be performed in PTIME for fragments permitting path-containment decomposition (Cheney, 2013).

In multiparty computation, static enforcement is implemented by transforming functional code into a form that enforces desired privacy policies on all executions (Ye et al., 2023). The static "lifting" algorithm rewrites code to avoid unsafe operations and inserts secure encodings, with correctness and noninterference proven by step-indexed logical relations. This eliminates the exponential overhead of dynamic "if-tree" semantics typical in traditional runtime-enforced policy-agnostic MPC.

3. Runtime Enforcement: Monitor Structures, Enforcement Domains, and Frameworks

Runtime enforcement operates by intercepting, modifying, or logging actions during system operation. Its power is characterized operationally by the class of monitors (and the associated action lattice) and the policies they can enforce.

The general enforcement model structures the monitor's power over each action by the control lattice $P$0. Properties enforceable at runtime are characterized by:

• L-safety: properties for which every violation can be detected and suppressed at a controllable or suppressible action.
• L-infinite-renewal: properties for which valid prefixes can always be extended, and invalid prefixes eventually land on a controllable action where enforcement is possible.
• L-corner-case: properties enforceable only when the monitor can uniquely determine the tail of the execution and force valid continuation by action insertions.

Canonical frameworks include edit-automata and SME. For example, the MAP-REDUCE runtime enforcement framework realizes secure multi-execution by spawning parallel filtered views of a base program, with a configurable map (input) and reduce (output) component mediating all I/O based on privilege tables. This framework is parameterized to instantiate enforcement of Non-Interference (NI), Removal of Inputs (RI), and Deletion of Inputs (DI) policies, achieving soundness and, for these classes, precision (Ngo et al., 2013).

Recent runtime governance mechanisms for AI agents employ deployment-layer artifacts (Policy Cards) that specify operational, ethical, and regulatory rules in a machine-readable format. Runtime enforcement is realized via gateways or libraries that interpret the card's attribute-based rules and perform real-time decision, logging, and escalation (Mavračić, 28 Oct 2025).

4. Integrated Static + Runtime Frameworks and Semantic Consistency

A unified enforcement model may combine static and runtime components. For example, web application security can derive static application security testing (SAST) components directly from runtime application security protection (RASP) mechanisms using a two-phase abstract interpretation (Pupo et al., 2021). In this setting:

• Phase I: analyze the uninstrumented program to compute a control/data flow abstraction.
• Phase II: upon detecting policy-relevant operations (traps), invoke the same policy enforcement code used at runtime, but under high-precision abstract interpretation.

This architecture guarantees semantic equivalence between what is statically and dynamically enforced, eliminates redundancy in specification (no dual maintenance of policy code), and ensures that static and runtime violations correspond exactly under analysis limits. Experiments on access control and information flow policies confirm up to a 5x speedup versus monolithic approaches, with no loss of policy precision (Pupo et al., 2021).

Policy Cards for AI governance also integrate static and runtime enforcement. Static enforcement is achieved by schema validation, lint rules, and compliance crosswalks during CI/CD gating; runtime enforcement is realized by interceptors that evaluate, log, and escalate requests in live deployed agents, with continuous audit feedback (Mavračić, 28 Oct 2025).

5. Metatheoretic Guarantees and Limitations

Policy enforcement models are typically accompanied by proofs of soundness, noninterference, and (where feasible) precision. For static enforcement:

• Soundness: No program or operation passes static checks unless it can never violate the policy in any instance.
• Noninterference: For information flow, trace indistinguishability theorems establish that public observations are never influenced by confidential data (Ye et al., 2023).

In runtime enforcement:

• The class of enforceable properties is strictly larger: some liveness and renewal properties are enforceable at runtime but inexpressible in static models.
• However, runtime enforcement incurs monitoring or transformation overhead, and, if the policy is expressible as a static open set, static enforcement suffices.

Limitations include:

• Static enforcement may reject safe operations if the policy is not fair or policy expressivity exceeds available static analysis.
• Dynamic enforcement in MPC or database settings can suffer from combinatorial overhead, as observed in exponential "if-trees" (Ye et al., 2023).
• Hybrid models add analysis complexity; configuration of abstraction levels may be nontrivial (Pupo et al., 2021).
• For machine-readable governance (Policy Cards), formal analysis (e.g., with SMT or constraint solving) is optional, and the main guarantee is determined by schema and evidence completeness (Mavračić, 28 Oct 2025).

6. Application Domains and Future Directions

Static and runtime policy enforcement is central in:

• Database access control (fine-grained static and dynamic checking of XPath-based policies) (Cheney, 2013).
• Secure multiparty computation (policy-agnostic programming and privacy enforcement) (Ye et al., 2023).
• Information flow control in general-purpose computation (SME, MAP-REDUCE) (Ngo et al., 2013).
• Web application security (SAST/RASP integration) (Pupo et al., 2021).
• Autonomous agent governance (Policy Cards) (Mavračić, 28 Oct 2025).

Trends emphasize unification of static and dynamic techniques, lowering performance overhead of dynamic enforcement via static program transformation, increasing policy expressivity, and supporting regulatory crosswalks for auditability. Open directions include handling richer policy languages, mixed-mode secure computation, scaling constraint-solving for policy synthesis, and formalizing the compositionality of hybrid static/dynamic systems.

---

References:

• MAP-REDUCE Runtime Enforcement Framework (Ngo et al., 2013)
• Static Enforceability of XPath-Based Access Control (Cheney, 2013)
• Runtime Enforcement With Partial Control (Khoury et al., 2015)
• Deriving Static Security Testing from Runtime Security Protection for Web Applications (Pupo et al., 2021)
• Taypsi: Static Enforcement of Privacy Policies for Policy-Agnostic Oblivious Computation (Ye et al., 2023)
• Policy Cards: Machine-Readable Runtime Governance for Autonomous AI Agents (Mavračić, 28 Oct 2025)