cedar

Cedar Policy Authoring for Sondera

Write Cedar policies that govern AI coding agent behavior — shell commands, file operations, web fetches, and prompts — using YARA signature detection, policy compliance checks, and sensitivity labels.

Cedar language reference: See CEDAR_REFERENCE.md for full syntax, schema authoring, data types, operators, templates, authorization patterns, and best practices.

Workflow

Follow this checklist when authoring Cedar policies:

- [ ] Step 1: Discover context features
- [ ] Step 2: Load and analyze schema
- [ ] Step 3: Write policy
- [ ] Step 4: Validate syntax
- [ ] Step 5: Validate against schema
- [ ] Step 6: Format policy
- [ ] Step 7: Test with authorization checks

Step 1: Discover context features

Call get_cedar_policy_context_features to get the latest valid YARA signature categories, policy violation codes, and sensitivity labels. Always do this before writing policies.

Step 2: Load and analyze schema

1. Call load_schema with the contents of policies/base.cedarschema
2. Call analyze_schema to see all actions, principal/resource types, and context fields

To add new entity types or actions, use create_entity_schema / create_action_schema / merge_schema_fragments, then validate_schema on the result.

Step 3: Write policy

Use the Sondera context features below and the syntax in CEDAR_REFERENCE.md.

Step 4: Validate syntax

Call validate_policy to catch syntax errors.

Step 5: Validate against schema

Call validate_policy_against_schema with the policy and schema. This catches unknown entity types, type mismatches, invalid action/principal/resource combinations, and unsafe optional attribute access without has guards.

Step 6: Format

Call format_policy for consistent style before saving.

Step 7: Test with authorization checks

1. Call clear_state to start clean
2. Call load_schema + load_policies
3. Call add_entity to create test principals, resources, and hierarchy entities
4. Call is_authorized with test cases — verify both permit and deny behavior
5. If results don't match expectations: call analyze_policies, adjust, re-validate, and re-test

Example is_authorized call:

principal: Agent::"claude-test"
action: Action::"ShellCommand"
resource: Trajectory::"test-session"
context_json: {
    "workspace": {"cwd": "/tmp", "permission_mode": "default", "transcript_path": ""},
    "signature": {"matches": 1, "categories": ["command_injection"], "severity": 4},
    "policy": {"compliant": false, "violations": ["SC2"]},
    "label": Label::"Confidential",
    "command": "rm -rf /",
    "working_dir": "/tmp"
}

---

Sondera Context Features

Always call get_cedar_policy_context_features first — the tables below are a static snapshot; the MCP tool returns the live, authoritative set.

Actions

Entity Types

Shared Context Types

type WorkspaceContext = {
    cwd: String,
    permission_mode: String,
    transcript_path: String,
};

type SignatureContext = {
    matches: Long,           // number of YARA matches
    categories: Set<String>, // threat categories
    severity: Long,          // 0-4
};

type PolicyContext = {
    compliant: Bool,         // true if no violations
    violations: Set<String>, // e.g. {"SC2", "SC3"}
};

YARA Signature Categories

Available for context.signature.categories.contains("..."):

Signature Severity Levels

Policy Violation Codes

Available for context.policy.violations.contains("..."):

Sensitivity Labels

context.label and resource.label entity references:

Taint Tags

resource.taints.contains(Taint::"...") values:

---

Policy Examples

// Default-permit baseline with targeted forbids
@id("default-permit")
permit (principal, action, resource);

// Block shell commands with injection patterns
@id("forbid-shell-command-injection")
forbid (
    principal,
    action == Action::"ShellCommand",
    resource
)
when {
    context.signature.categories.contains("command_injection")
};

// IFC: block writing highly confidential content to public files
@id("forbid-file-write-hc-to-public")
forbid (
    principal,
    action in [Action::"FileWrite", Action::"FileEdit"],
    resource
)
when {
    context.label == Label::"HighlyConfidential" &&
    resource.label == Label::"Public"
};

// Block writing secrets into Python files
@id("forbid-source-write-secrets-python")
forbid (
    principal,
    action in [Action::"FileWrite", Action::"FileEdit"],
    resource
)
when {
    context.path like "*.py" &&
    context.signature.categories.contains("secrets_detection")
};

// Block non-compliant shell commands on sensitive trajectories
@id("forbid-any-destructive-on-confidential-trajectory")
forbid (
    principal,
    action == Action::"ShellCommand",
    resource
)
when {
    !context.policy.compliant &&
    (resource.label == Label::"Confidential" ||
     resource.label == Label::"HighlyConfidential")
};

// Block all web fetches on highly confidential trajectories
@id("ifc-forbid-webfetch-highly-confidential")
forbid (
    principal,
    action == Action::"WebFetch",
    resource
)
when {
    resource.label == Label::"HighlyConfidential"
};

---

Key Pitfalls

• like is an infix operator, not a method: context.path like "*.py" (correct) — NOT context.path.like("*.py")
• * wildcard matches broadly: context.command like "*rm*" matches rm but also format, firmware
• Guard optional attributes: always check has before access — resource has "location" && resource.location == "US"
• Explicit deny wins: a single matching forbid overrides all permit policies
• Default deny: if no policy matches, access is denied
• Scope over conditions: use principal/action/resource constraints in policy scope, not in when clauses

---

Quick Reference

POLICY:   @id("name") permit|forbid (principal, action, resource) when {...} unless {...};
SCOPE:    == (exact) | in (hierarchy) | is (type check) | in [...] (set)
STRING:   like "pattern*"   (* = wildcard)
SET:      .contains(x)  .containsAll(s)  .containsAny(s)  .isEmpty()
ATTR:     entity.attr  entity["attr"]  entity has "attr"
LOGIC:    &&  ||  !  if...then...else
COMPARE:  ==  !=  <  <=  >  >=
ARITH:    +  -  *  (Long only, no division)
ENTITY:   Type::"id"  Namespace::Type::"id"