Late-bound policy enforcement

Why late-bound policy matters

Distributed systems often hardwire policy into deployment scripts, gateway configuration, or application code. That makes the policy hard to audit and hard to move with the behavior it governs.

UMA keeps the portable behavior separate while letting runtime authority decide whether a specific execution path is allowed under current conditions.

What this page does not replace

The full book goes deeper into how validation, adapter binding, policy, and lifecycle evidence fit together. This page is the orientation layer: it tells you why the idea matters and where to inspect it in code.

Why build-time policy is insufficient

A constraint encoded at build time (a compiled permission check, a hardcoded role requirement, a static ACL resolved during compilation) cannot change without redeployment. That constraint is an artifact of the build, not a parameter of the execution environment.

In a system where the same portable service is intended to run across multiple runtimes with different trust contexts, a single build-time policy creates an inescapable dilemma: the policy must be either too permissive or too restrictive. Too permissive means the policy is calibrated to the most open context the service might encounter, which means it does not actually enforce meaningful constraints in that context. Too restrictive means it is calibrated to the most locked-down context, which means it blocks legitimate execution everywhere else.

This is not a problem that can be resolved by choosing the right hardcoded value. The constraint being hardcoded is the problem. Late binding dissolves the dilemma by making the constraint a runtime parameter rather than a compiled artifact. The service carries a declaration of what policy categories apply to it. The runtime consults that declaration at execution time and evaluates it against the current context: the trust level in effect, the data classification of the current request, the identity of the caller. Different runtimes produce different policy outcomes from the same declaration, without requiring different builds.

Build-time policy also resists audit. When a constraint lives inside a compiled artifact, the only way to know what policy is in effect is to read the source and then trust that the source matches the binary. Late-bound policy is visible in the descriptor: it can be read, compared across environments, and validated before execution starts.

How late-bound policy works in a UMA runtime

The active descriptor declares what policy categories apply to the capability: the trust level required for the caller, the data classification of inputs and outputs, the set of allowed caller identities, and any placement constraints that govern where the capability may execute. These are declarations, not decisions. The decision is made by the runtime at invocation time.

When a call arrives, the runtime evaluates the descriptor's policy declarations against the current execution context. What trust level does the present runtime operate at? What is the caller's declared identity? Does the current data classification permit this operation? Each check is local. The runtime does not need to coordinate with an external policy service for every invocation. The descriptor contains the policy specification. The runtime contains the evaluation logic. The current context contains the facts.

The same WASM binary can run with strict policy in a production runtime and with relaxed policy in a development runtime without recompilation. The binary does not change. The descriptor's policy declarations do not change. What changes is the context the runtime brings to the evaluation: the trust level configured for that runtime, the permitted identity set for that deployment. Policy becomes a runtime configuration, not a build artifact.

The policy decision is recorded as execution evidence. Every invocation that clears the policy check leaves a trace that identifies which policy was applied, against which context, and with what outcome. That trace is the artifact that makes compliance claims inspectable rather than asserted. When an auditor asks whether a capability was executed within its declared policy, the answer is in the run record, not in a conversation about what the code probably does.

What this enables architecturally

Policy changes do not require service redeployment. When a compliance requirement shifts (a new data classification rule, a change in allowed caller identities, a stricter trust level for a category of operation), the change is made in the runtime configuration or in the descriptor, not in the service binary. The service is unchanged. The deployment artifact is unchanged. The policy, as evaluated in production, is updated.

Different runtimes can apply different policy profiles to the same capability. A capability deployed to a high-trust internal runtime and simultaneously deployed to an edge runtime that handles untrusted external callers is governed by two different policy evaluations against the same descriptor. The edge runtime applies the constraints appropriate to external trust. The internal runtime applies the constraints appropriate to internal trust. The service is one binary. The policy contexts are two different configurations. This model is structurally impossible with build-time policy, where the binary would have to encode one or both contexts statically.

Compliance requirements that vary by region, data classification, or caller type can be expressed as runtime policy without forking the service implementation. Rather than maintaining separate builds for each regulatory context, a single portable binary is deployed with runtime configuration that expresses the relevant policy. The proof that each deployment meets its regulatory requirements is in the per-run evidence, not in a claim about the binary's internal logic.

The deeper consequence is that the authority for what is allowed moves from the development process to the runtime layer. That shift is what makes policy genuinely auditable and genuinely adaptable. A runtime that evaluates late-bound policy is an architecture that treats compliance as an operational property, not a build property. That is the only model that holds up when the same service needs to operate correctly across genuinely different trust environments.