Skip to main content
The Cedar Policy Engine is the central authorization subsystem within Palyra, implemented in the palyra-policy crate. It leverages the Cedar policy language to provide fine-grained, attribute-based access control (ABAC) for tool executions, skill invocations, and administrative actions.

​
Overview and Purpose

The primary role of the engine is to intercept requests within the palyra-daemon and determine if a given principal (e.g., a user or an automated agent) is permitted to perform an action on a specific resource. This is most critically used during the decide_tool_call flow to ensure that LLM-driven tool requests adhere to security guardrails.

​
Key Components

​
Data Mapping: Tools to Cedar Entities

When a tool call is evaluated, Palyra maps internal Rust structures to Cedar’s Request and Context entities.

​
Entity Mapping Table

Palyra ConceptCedar EntityCode Reference
PrincipalPrincipal::<id>crates/palyra-policy/src/lib.rs#12
ActionAction::<name>crates/palyra-policy/src/lib.rs#13
ResourceResource::<id>crates/palyra-policy/src/lib.rs#14
Capabilitiescontext.capabilitiescrates/palyra-policy/src/lib.rs#25
Sensitivitycontext.is_sensitive_actioncrates/palyra-policy/src/lib.rs#103

​
Natural Language to Code Entity Space

This diagram illustrates how a natural language request from an LLM (“Run the ‘ls’ command”) is transformed into a formal Cedar Authorization Request. Sources: crates/palyra-daemon/src/tool_protocol.rs#205-230, crates/palyra-policy/src/lib.rs#211-230

​
Policy Evaluation Flow

The decide_tool_call function in the daemon is the primary consumer of the policy engine. It prepares a PolicyRequest and evaluates it against the loaded PolicySet.

​
Tool Decision Logic

  1. Budget Check: Validates if the max_calls_per_run has been exceeded. crates/palyra-daemon/src/tool_protocol.rs#242-250
  2. Context Assembly: Gathers principal, session_id, and capabilities (e.g., network, process_exec). crates/palyra-daemon/src/tool_protocol.rs#252-270
  3. Cedar Evaluation: Calls evaluate_with_context in the palyra-policy crate. crates/palyra-policy/src/lib.rs#211-215
  4. Approval Check: If the action is “sensitive” (e.g., process_exec), the engine may return an Allow decision that still flags approval_required. crates/palyra-daemon/src/tool_protocol.rs#315-330

​
Decision Flow Diagram

This diagram traces the internal function calls from the daemon’s tool protocol into the Cedar engine. Sources: crates/palyra-daemon/src/tool_protocol.rs#232-340, crates/palyra-policy/src/lib.rs#211-250

​
Default Policies (DEFAULT_POLICY_SRC)

Palyra ships with a set of embedded policies that define the safety baseline. These are defined in crates/palyra-policy/src/lib.rs.

​
Core Policy Logic

​
Sensitive Actions List

The following actions are categorized as sensitive by default and often trigger a human-in-the-loop approval requirement:
  • cron.delete
  • memory.delete
  • memory.purge
  • tool.execute (if tool has sensitive capabilities like ProcessExec)
Sources: crates/palyra-policy/src/lib.rs#40-41, crates/palyra-policy/src/lib.rs#148-157, crates/palyra-daemon/src/tool_protocol.rs#148-150

​
Configuration: PolicyEvaluationConfig

This struct controls how the engine interprets the runtime state of the daemon. 
pub struct PolicyEvaluationConfig {
    pub allowlisted_tools: Vec<String>,
    pub allowlisted_skills: Vec<String>,
    pub allow_sensitive_tools: bool,
    pub sensitive_tool_names: Vec<String>,
    pub sensitive_actions: Vec<String>,
    pub sensitive_capability_names: Vec<String>,
    pub tool_execute_principal_allowlist: Vec<String>,
    pub tool_execute_channel_allowlist: Vec<String>,
}
crates/palyra-policy/src/lib.rs#29-38

​
Key Fields Explained

Sources: crates/palyra-policy/src/lib.rs#29-58, crates/palyra-daemon/src/tool_protocol.rs#151-186