Cedar Policies

Rensei's authorization layer is built on a pure TypeScript Cedar policy engine - no external Cedar service or sidecar required. The Policy Enforcement Point (PEP) evaluates all access decisions: tool invocations, credential references, A2A dispatch, memory transfers, workflow controls, and the BFSI compliance policy library.

Core concepts

Cedar policy structure

Cedar policies use permit and forbid clauses with when and unless conditions. The platform's engine applies a forbid-wins semantic: any matching forbid clause overrides all permit clauses.

// Allow agents to invoke any tool by default
permit (
  principal is Agent,
  action == Action::"invoke_tool",
  resource is Tool
);

// Except: production data tools are restricted to approved agents
forbid (
  principal is Agent,
  action == Action::"invoke_tool",
  resource is Tool
)
when {
  resource.sensitivity == "production" &&
  !principal.approved_for_production
};

Entity types

The engine works with typed entities. The platform schema defines these principal/resource types:

Request shape

Every Cedar evaluation takes a CedarRequest:

interface CedarRequest {
  principal: CedarEntity   // { type, id, attrs }
  action: string           // e.g. "invoke_tool", "invoke_model"
  resource: CedarEntity    // { type, id, attrs }
  context: Record<string, unknown>
}

The engine returns a CedarDecision:

interface CedarDecision {
  decision: 'allow' | 'deny'
  diagnostics: {
    reason: string
    matchedPolicies: string[]  // policy ids that matched
  }
  evaluationTimeUs: number
}

Policy management

Storing policies

Policies are stored in the policies table, scoped to a workspace (org) and optionally a project. The platform loads all status = 'active' policies for the relevant workspace at evaluation time.

Creating a policy via the API

curl -X POST https://rensei.ai/api/policies \
  -H "Authorization: Bearer rsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Block production data access",
    "description": "Prevent agents from accessing production-classified tools",
    "policyText": "forbid (principal is Agent, action == Action::\"invoke_tool\", resource is Tool) when { resource.sensitivity == \"production\" };",
    "scope": "org",
    "status": "active"
  }'

YAML compiler

For complex policies, write Cedar in a YAML envelope and compile it:

# policy.yaml
id: restrict-pci-tools
name: Restrict PCI tool access
effect: forbid
principal:
  type: Agent
action: invoke_tool
resource:
  type: Tool
conditions:
  - type: when
    expression: 'resource.data_classification == "pci" && !principal.pci_cleared'

import { compileCedarYaml } from '@/lib/cedar/yaml-compiler'
const policyText = compileCedarYaml(yamlContent)

Policy check endpoint

Test a policy decision without triggering a real action:

curl -X POST https://rensei.ai/api/policy-check \
  -H "Authorization: Bearer rsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "principal": { "type": "Agent", "id": "agent_...", "attrs": { "workspaceId": "org_..." } },
    "action": "invoke_tool",
    "resource": { "type": "Tool", "id": "bash", "attrs": { "sensitivity": "production" } },
    "context": {}
  }'
# Returns: { "decision": "deny", "diagnostics": { "reason": "...", "matchedPolicies": ["restrict-production-tools"] } }

Policy domains

The PEP evaluates requests across six domains, each covering a different action surface:

Tool access

evaluateToolAccess(agentId, toolName, context) - called before every tool invocation in a running session. This is the primary enforcement point for preventing agents from accessing sensitive operations.

Credential references

evaluateCredentialRef - called when an agent expression references a credential by name. Prevents agents from accessing credentials they should not see (e.g., production API keys in a dev-only workflow).

A2A dispatch

evaluateA2ADispatch - evaluated when one agent attempts to dispatch a task to another A2A agent. Enforces trust boundaries between agents. See A2A Policies.

Memory transfer

evaluateMemoryTransfer - evaluated before cross-project memory observations are injected into an agent's context. See Cross-Project Transfer.

Model invocation (BFSI)

resolveCedarAgentModel - intercepts model routing between project-scope and org-scope fallback. BFSI tenants use this to enforce model risk tiering. See BFSI Compliance.

Knowledge graph access

enforceGraphAccess (graph-pep.ts) - evaluated before every read/write to graph_node and graph_edge resources via the knowledge-graph MCP tools. Maps verbs (read, write, subgraph) to Cedar actions (read_node, write_node, read_edge, write_edge, read_subgraph). Emits typed graph.access.permit / graph.access.deny audit events in addition to the generic policy.evaluated event. Uses the A2AAgent entity type (shared with the A2A and memory PEPs).

Marketplace publish and install

enforceMarketplacePublish / enforceMarketplaceInstall (marketplace-enforcement.ts) - evaluated when a user publishes a workflow node to the org marketplace or installs one from it. These are system-level static policies (not DB-stored workspace policies); workspace_admin or workspace_owner role is required to publish.

Cross-project memory transfer

enforceCrossProjectTransfer (cross-project-pep.ts) - a specialised wrapper around the memory PEP for the case where an agent in Project B requests observations produced in Project A. Evaluates stack_similarity (Jaccard similarity between project stacks), memory classification (public/internal/confidential/restricted), and whether the org admin has enabled transfer for this project pair. restricted and confidential observations cannot be permitted by workspace policies - only the org-level default allows them.

Operator impersonation

The PEP supports an operator impersonation capability for platform-level support workflows. When an impersonation context is active, the principal is re-scoped to the operator's context before policy loading and evaluation. All audit events during impersonation are attributed to the operator ID. Operator impersonation configuration is covered in the operator docs.

Required workflow policies

Org admins can seed and enforce policies that must be present on every workflow before it can be deployed. This "seed-and-enforce" mode is configured at POST /api/admin/required-workflow-policies.

curl -X POST https://rensei.ai/api/admin/required-workflow-policies \
  -H "Authorization: Bearer rsk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "policyId": "bfsi-segregation-of-duties",
    "enforce": true
  }'

See Required Workflow Policies for the full configuration model.

BFSI policy library

For regulated organizations, the platform ships 11 pre-built policies aligned to financial regulatory requirements. These are installed through the BFSI onboarding flow:

See BFSI Compliance for the full installation instructions and pipeline stage definitions.

Audit integration

Every evaluated Cedar decision emits a policy.evaluated event to the audit trail, including the matched policy IDs, the decision, and the evaluation latency. Policy create, update, and archive operations also emit policy.created, policy.updated, and policy.archived events.

Related pages

• BFSI Compliance - regulatory policy packs and risk scoring
• Approval Gates - human approval gates wired through Cedar
• A2A Policies - inter-agent authorization
• Required Workflow Policies - enforced policy seeding
• Audit Trail - policy.evaluated events and chain integrity