Skip to main content
Palyra employs a deny-by-default security architecture powered by the Cedar policy language. Every action within the system—from tool execution to API access—must be explicitly permitted by a policy. The system combines static Cedar policies with a dynamic Approval Gate system for sensitive operations, ensuring a fail-closed posture where any engine error or missing permission results in an access denial crates/palyra-policy/src/lib.rs#1-6.

Cedar Authorization Core

The palyra-policy crate serves as the central evaluation engine. It translates system requests into Cedar entities and evaluates them against an embedded baseline policy set crates/palyra-policy/src/lib.rs#160-161.

Policy Request and Context

Authorization is triggered via a PolicyRequest, which defines the triple of principal, action, and resource crates/palyra-policy/src/lib.rs#19-26. This is augmented by a PolicyRequestContext containing environmental metadata:
FieldDescription
device_idThe originating hardware identifier crates/palyra-policy/src/lib.rs#36-36.
channelThe communication platform (e.g., Discord, Slack) crates/palyra-policy/src/lib.rs#37-38.
session_idCorrelation ID for the current conversation crates/palyra-policy/src/lib.rs#39-40.
capabilitiesSpecific permissions requested by a tool (e.g., net.egress) crates/palyra-policy/src/lib.rs#47-49.

Authorization Data Flow

The following diagram illustrates how a tool proposal is transformed from a code entity into a Cedar decision. Diagram: Tool Proposal to Cedar Evaluation Sources: crates/palyra-daemon/src/application/tool_security.rs#57-64, crates/palyra-policy/src/lib.rs#12-26, crates/palyra-daemon/src/application/tool_security.rs#107-116

Tool Posture and Execution Gates

Tool execution is governed by a multi-stage pipeline. Before a tool runs, it must pass through the evaluate_tool_proposal_security function crates/palyra-daemon/src/application/tool_security.rs#107-116.

Posture States

Palyra defines three primary postures for tools:
  1. AlwaysAllow: Tool executes immediately if Cedar permits.
  2. AskEachTime: Tool requires an explicit operator approval via the Approval Gate crates/palyra-daemon/src/application/approvals/mod.rs#1-7.
  3. Disabled: Tool is blocked regardless of Cedar policies.

Sensitive Actions

Certain actions are hardcoded as sensitive and always require elevated permissions or approvals:

Approval Gate System

The Approval Gate handles “human-in-the-loop” security. When a tool call is permitted by Cedar but marked as approval_required, the daemon halts execution and creates a PendingToolApproval crates/palyra-daemon/src/application/approvals/mod.rs#40-45.

Approval Workflow

  1. Context Assembly: The system builds a PendingToolApproval containing a summary of the request, risk levels, and execution context (e.g., which backend will run the command) crates/palyra-daemon/src/application/approvals/mod.rs#143-164.
  2. Journaling: The request is appended to the JournalStore as an ApprovalPromptRecord crates/palyra-daemon/src/application/approvals/mod.rs#26-27.
  3. Operator Decision: The operator grants or denies the request via the Web Console or CLI.
  4. Decision Application: apply_tool_approval_outcome merges the operator’s decision into the final ToolDecision. If the approval channel is unavailable, the system fails closed and denies the request crates/palyra-daemon/src/application/approvals/mod.rs#65-81.
Diagram: Approval Gate Logic Sources: crates/palyra-daemon/src/application/approvals/mod.rs#65-97, crates/palyra-daemon/src/application/approvals/mod.rs#168-172

Service Authorization and API Tokens

Access to the daemon’s external API (including the OpenAI-compatible compat facade) is managed by the AccessRegistry crates/palyra-daemon/src/access_control.rs#1-8.

Feature Flags and RBAC

The system uses feature flags to gate entire subsystems:

Workspace Roles

Permissions are grouped into WorkspaceRole levels crates/palyra-daemon/src/access_control.rs#114-118:

API Token Scopes

Tokens are minted with specific scopes (e.g., compat.chat.create) and are subject to rate limiting crates/palyra-daemon/src/access_control.rs#53-60. Tokens only store SHA-256 digests of the secret to prevent credential leakage from the state file crates/palyra-daemon/src/access_control.rs#10-11. Sources: crates/palyra-daemon/src/access_control.rs#1-67, crates/palyra-daemon/src/transport/http/handlers/compat.rs#162-169