Cedar and OPA policy backends

Path patterns and conditions cover most access control. When rules get genuinely complex (cross-resource logic, org-specific data lookups), 1Claw supports two declarative policy backends alongside the built-in engine.

• Cedar (Team tier and above): AWS's authorization language. Principal, action, resource, context.
• OPA (Business tier and above): Open Policy Agent, using Rego and custom data documents.
• Both are additive. The built-in policy engine still runs; these express rules it cannot.

1. 1

   Write a Cedar policy. This one forbids any agent from reading production secrets outside business hours.

   bash Copy

   curl -s -X POST https://api.1claw.co/v1/org/cedar-policies \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "name": "no-prod-reads-after-hours",
       "policy": "forbid(principal in Group::\"agents\", action == Action::\"read\", resource in Vault::\"production\") when { context.hour > 18 };"
     }'

2. 2

   Dry-run it before trusting it. Supply a principal, action, resource, and context and see the decision.

   bash Copy

   curl -s -X POST https://api.1claw.co/v1/org/cedar-policies/test \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
       "principal": "Agent::'$AGENT_ID'",
       "action": "read",
       "resource": "Vault::production",
       "context": { "hour": 22 }
     }'

3. 3

   List what is active, from the CLI.

   bash Copy

   1claw cedar-policy list
   1claw opa-policy list

4. 4

   The OPA equivalent takes Rego plus an input document.

   bash Copy

   curl -s -X POST https://api.1claw.co/v1/org/opa-policies/test \
     -H "Authorization: Bearer $ONECLAW_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{ "input": { "agent": { "environment": "preview" }, "path": "prod/db" } }'

You rarely write Cedar by hand for a first agent. Policy presets (Team+ for the Cedar export) answer a plainer question instead: read-only-assistant, small-business-spender, inbox-agent, treasury-operator, each a sentence that compiles to the same guardrail columns, access policies and approval rules you would otherwise write by hand.

A preset is not a way around approval. Applying one that loosens a guardrail returns 202 or 403, never a silent 200, because a preset builds the same request a person editing the agent by hand would send and passes it to the same handler: same widening classification, same approval queue, same step-up. A wizard that wrote guardrail columns directly would be a way around that flow wearing a friendlier interface.

The Cedar export makes the same discipline visible in the generated policy itself. Presets state limits in dollars; Cedar's schema only exposes transaction value as value_gwei, a native-token amount. Converting needs a live price, and a price baked into a policy at write time is wrong the moment it is written and stays silently wrong from then on.

Policies created from a Cedar export start in shadow mode, the same enforcement: log setting taught earlier in this course, reporting what they would decide without deciding anything until someone promotes them. Dry-run one with the same test endpoint you already used above before promoting it.