OPA, Cedar, identity, and the exact action
Compare policy engines and identity providers with execution authority, approvals, receipts, and the narrow scope of one consequential action.
Technical guide · Documentation checked October 3, 2026.
Key takeaways
- OPA and Cedar evaluate structured authorization input; neither replaces the application’s enforcement and evidence path.
- OIDC, OAuth, and workload identity establish who or what is asking, not whether this exact side effect may occur.
- Rangoon keeps policy result, approval, server authorization, execution, and receipt as distinct evidence.
Separate policy decision from enforcement[source 1][source 2]
OPA describes a general-purpose policy engine that accepts structured input, evaluates policy and data, and returns structured decision output. That makes it useful for expressing reusable rules across services, infrastructure, and workflows. The application that asks OPA still owns the request lifecycle, enforcement point, error handling, and evidence binding.
Cedar describes a policy language and authorization engine that evaluates principals, actions, resources, entities, and request context. Its schema validates policy structure, while the application supplies the entities and request. In both cases, a policy answer is one decision input. It does not itself consume a one-time capability, perform a connector operation, or prove the resulting external effect.
Identity narrows context; it does not widen authority
An identity provider can authenticate a person, service, or workload and attach groups, claims, scopes, session state, or device facts. Those claims help the policy layer understand who is asking and under what context. They remain subject to freshness, audience, issuer, resource, and session checks.
An OAuth scope is delegated access language, not a blanket grant to an AI agent. A valid token can still be too broad, too old, aimed at the wrong resource, or outside the user’s approved task. Rangoon records identity as part of a canonical packet, then evaluates the exact operation through the selected authority path.
Make the action narrow enough to review
A useful packet names the actor and session, project and environment, connector or adapter, target resource, exact operation, bounded parameters, data class, risk, policy profile, approval requirement, expiry, nonce, idempotency key, and rollback or receipt obligation. The policy engine can evaluate those fields, but the enforcement layer must reject substitutions and missing evidence.
A human approval should bind the same digest and scope that the authority decision will consume. If a target, payload, resource, capability, or policy version changes, the system creates a new decision rather than silently reusing the old answer. This is where fail-closed behavior becomes operational instead of rhetorical.
Test the integration as a chain
Test policy inputs with allow, deny, approval-required, unknown-capability, expired, and malformed cases. Test identity mismatch, stale session, wrong audience, resource substitution, scope widening, duplicate idempotency key, connector timeout, partial external result, and revoked authorization. Assert that no adapter runs without a matching authorization bundle.
Then inspect the receipt: requested, approved, and executed digests should agree; adapter and sandbox identity should be present; timing and bounded result should be recorded; unknown outcome should remain unresolved until reconciliation. OPA, Cedar, OpenFGA, Entra ID, Okta, Auth0, and Keycloak can each contribute useful signals. Rangoon’s launch architecture keeps them behind the same exact-action boundary.
