Runtime policy enforcement

Runtime policy enforcement applies a policy decision while an operation is being processed, through a component that can allow, modify, or stop the operation. A post-event alert may inform a response, but it cannot prevent an action that has already completed.

Open Policy Agent's architecture overview explicitly separates policy decision-making from enforcement. That separation is useful even in systems where the components are packaged together.

Identify the component that acts on the decision. A policy evaluator can return “deny” while an application still proceeds if no component enforces that result.

Explore Dome: Authorization · Docs: Authorization model.

Which component decides, and which one stops the request?

For a file export, distinguish the component that decides access, the one that can stop delivery, and the source of the facts used:

The decision and enforcement points may be part of the same service or separate components. What matters is whether enforcement happens before the export.

A gateway can refuse to forward the request, and a backend can refuse to create the export. A monitoring service that sees it afterward can raise an incident, but cannot prevent that disclosure.

NIST's zero trust architecture places resource access decisions at the center of the architecture. Zero trust explains that approach to resource access.

Explore Dome: Tool Gateway · Docs: Tools gateway.

Decide what to do when required information is missing

For the export, the policy might need the verified agent, target dataset, requested destination, and data classification. Identify where each fact comes from, whether the caller can change it, and how you know it is still current.

A caller saying the data is public doesn't establish its classification. Decide what the enforcing component should do if it cannot obtain that information. Assuming the data is safe may let a restricted export proceed.

If the dataset changes after authorization, the backend may need to recheck its classification before exporting it. An earlier gateway decision may not have that updated information.

Dome documents rules evaluation in its tool and model paths, including failure behavior and policy freshness. Check those details before relying on a particular response to an outage or policy update.

Explore Dome: Authorization · Docs: Authorization model.

Check that a denied operation did not run

Using synthetic data, request a file export that should be denied and check that the backend did not create it. Then send an allowed export through the same path.

Then inspect alternative routes. Can the workload contact the service directly? Does a fallback connection use the same decision? Does a retry happen after the application has lost the original result? Record which routes you tested.

Keep the results with the routes and conditions tested, and repeat the checks when those routes change.

Use agent authorization to decide which action facts matter, default-deny versus fail-closed to specify no-match and failure outcomes, and policy testing versus simulation to review the evaluator. Then verify that the component enforcing the decision actually stops the forbidden action.

Explore Dome: Authorization · Docs: Simulate rules.