Context Graph vs Policy-as-Code: Rule Evaluation vs Decision Authority

Q: What is the difference between policy-as-code and a context graph?

Policy-as-code engines like OPA and Cedar evaluate declared rules over the request attributes they are handed at evaluation time. A context graph determines which policies, entitlements, exceptions, and facts actually govern a specific proposed action, evaluates their applicability at decision time, and records why the outcome was reached.

Q: Is OPA enough to govern AI agent actions?

No. OPA answers whether a request matches declared rules, but it evaluates only the attributes provided in the input document. It does not resolve which policy version is in force, whether an entitlement is stale, which exception overrides the default, or whether the action is applicable to the entity's current state. That governing context is what a decision context graph supplies.

Q: Do policy engines and context graphs work together?

Yes. A policy engine is a strong evaluation component inside a decision boundary. The context graph resolves the governing context: applicable policy versions, current entitlements, active exceptions, scope, and provenance. The engine then evaluates rules against facts that are guaranteed current and applicable, and the boundary records a causal decision trace.

Q: Why do policy-as-code deployments fail for autonomous agents?

Because agents compose actions at runtime that no policy author anticipated. A policy evaluates the case it is shown. If the input omits the fact that a return window closed or a policy version was superseded, the engine correctly approves an action that should have been escalated. Garbage-in applies to policies too: rule evaluation is only as valid as the context assembled for it.

Patrick Joubert; Patrick Joubert

Context Graph vs Policy-as-Code

Rule Evaluation Is Not Decision Authority

Policy-as-code is becoming the standard enforcement layer for AI agents: OPA sidecars at the gateway, Cedar policies in the authorization path, Rego bundles versioned and tested like any other artifact.

That layer matters. It is also easy to mistake for decision authority.

A policy engine answers whether a request, as described by its input attributes, satisfies the declared rules. A context graph answers which rules govern this case right now, with which facts, and whether the proposed action is applicable, scoped, current, and traceable before it changes a system.

The Core Distinction

A policy engine is an evaluator. It takes a rule set and an input document and computes a verdict. Both are supplied by the caller. If the input omits the fact that a return window closed or that a policy version was superseded, the engine correctly approves an action that should have been escalated. The verdict is sound; the case was wrong.

A decision context graph operates one layer below: it resolves the case itself. It holds policy versions, entitlements, contract terms, exceptions, and approval history as connected, queryable state, so the question “which rule governs this entity, in this scope, at this moment” is computed at decision time, not assumed at input-assembly time.

Side-by-Side Comparison

Dimension	Policy-as-Code	Context Graph
Core question	Does this request, as described by its input attributes, satisfy the declared rules?	Which rules govern this case right now, and is this proposed action valid under them?
Control point	Policy decision point invoked at authorization or gateway checkpoints	Per-action decision boundary before execution
Input	The attribute document the caller assembles and passes in	Connected, queryable business state: policy versions, entitlements, exceptions, scope, provenance
Primary artifact	Allow or deny verdict, sometimes with a rule reference	Applicability result, allow, escalate, or block decision, causal decision trace
Failure caught	Requests that visibly violate a declared rule	Actions that satisfy every declared rule but are invalid for this case: stale entitlement, superseded policy, closed window, out-of-scope entity

What Policy-as-Code Does Well

Policy control	Good at	Does not prove
Rego / OPA policy	Declarative allow/deny logic over structured input	Whether the input document reflects the current, governing state of the case
Cedar policy	Fast, verified authorization over principals, actions, and resources	Which policy version, exception, or contract term applies to this entity right now
Policy gateway	Enforcing policies at the API or MCP boundary	Whether the composed action is applicable to the business case behind the call
Policy bundle CI	Versioning and testing rules like code	Whether the deployed rule set is the one in force for this jurisdiction and time
Attribute-based access control	Granting by attribute instead of role	Temporal validity and provenance of the attributes themselves

Why Rule Evaluation Is Not Applicability Logic

A policy engine evaluates the rules it is handed against the attributes it is handed. Applicability logic determines which policy version, contract, jurisdiction, tenant, customer state, and exception hierarchy actually govern the proposed action.

A rule can be correct, versioned, tested in CI, and still be the wrong rule for this case, because an exception supersedes it, because the version in force changed, or because the entity’s state moved after the input document was assembled.

A policy verdict says allow or deny. A causal decision trace explains why: which context was consulted, which rules applied, which exception won, and which evidence makes the outcome accountable to an auditor.

Production Scenarios

Refund approval

Policy-as-code: The policy checks that the caller has the refund permission, the amount is under the threshold, and the resource type matches. All attributes pass. The refund is allowed.

Context graph: The decision context graph resolves the governing context first: the return window closed two days ago, the policy version cited in the input was superseded, and the entitlement went stale. The same action evaluates to escalate, with the trace showing why.

Cross-tenant data update

Policy-as-code: The policy verifies the agent identity, the tenant claim in the token, and the operation type. The request matches the rules as written.

Context graph: The context graph checks whether this record set belongs to the scope of the case the agent is working, whether a migration freeze is active, and whether the data source authorized this write path. Scope isolation is evaluated per action, not per token.

Contract discount

Policy-as-code: The policy allows discounts up to 15% for the sales-agent role. The proposed 12% discount passes.

Context graph: The context graph finds that this customer's master service agreement pins discounts to a negotiated schedule and that an active exception granted by legal supersedes the default. The generic 15% rule was never the governing rule for this case.

Where This Fits in the Agent Stack

Policy-as-code is necessary infrastructure. Declaring rules as versioned, testable artifacts is strictly better than burying them in application code, and engines like OPA and Cedar evaluate them fast and verifiably.

Decision context graphs are necessary for accountable agents. They supply what no engine can infer from an input document: which policy is in force, which exception overrides it, which facts are current, which source has authority, and whether the action can be replayed as a causal decision trace.

The strongest architecture uses both: the context graph resolves the governing context for each proposed action, the policy engine evaluates rules against facts guaranteed current and applicable, and the decision boundary records the outcome with its trace. Rule evaluation becomes one step inside pre-execution enforcement, not a substitute for it.