Skip to main content
The Palyra Policy Engine provides a fine-grained, attribute-based access control (ABAC) system for tool execution and system actions. It integrates the Cedar policy language to evaluate requests against a set of security rules, ensuring that autonomous agent actions remain within operator-defined boundaries.

Cedar Policy Integration

Palyra uses the palyra-policy crate to wrap the Cedar SDK. The engine evaluates PolicyRequest objects against a PolicySet to produce a PolicyDecision (Allow or Deny).

Core Data Structures

Default Policy Logic

The system ships with a built-in Cedar policy source that enforces baseline security crates/palyra-policy/src/lib.rs#99-181:
  1. Deny Sensitive: Forbids sensitive actions if allow_sensitive_tools is false crates/palyra-policy/src/lib.rs#100-105.
  2. Allow Read-Only: Permits safe actions like tool.list or daemon.status crates/palyra-policy/src/lib.rs#107-118.
  3. Allowlisted Execution: Permits tool.execute only if the tool is in the allowlist and the principal/channel are authorized crates/palyra-policy/src/lib.rs#120-127.
Sources: crates/palyra-policy/src/lib.rs#11-181

Tool Authorization Workflow

When an agent or user requests a tool execution, the palyra-daemon invokes the evaluate_with_context function.

Policy Evaluation Data Flow

The diagram below illustrates how internal tool metadata and request context are transformed into a Cedar authorization request. Tool Authorization Mapping Sources: crates/palyra-policy/src/lib.rs#211-215, crates/palyra-daemon/src/tool_protocol.rs#67-70

Tool Sensitivity and Capabilities

Tools in Palyra are classified by their ToolMetadata. This metadata determines if a tool is “sensitive” and requires explicit operator approval.

Sensitivity Defaults

A tool is considered sensitive if default_sensitive is true or if it requires any of the following ToolCapability values crates/palyra-daemon/src/tool_protocol.rs#148-149:
  • process_exec: Execution of arbitrary system binaries.
  • network: Outbound network access.
  • secrets_read: Access to the Palyra Vault.
  • filesystem_write: Modification of the host filesystem.

Tool Attestation

Every tool execution generates a ToolAttestation crates/palyra-daemon/src/tool_protocol.rs#73-80. This structure provides cryptographic and environmental proof of the execution: Sources: crates/palyra-daemon/src/tool_protocol.rs#47-80, crates/palyra-daemon/src/tool_protocol.rs#148-149

Approval Lifecycle

If a policy evaluation results in a “Deny” due to sensitivity, or if the tool configuration requires manual intervention, the request enters the Approval Lifecycle.

Lifecycle States

  1. Pending: The palyrad gateway holds the execution and creates an entry in the JournalStore.
  2. Review: The operator uses the Web Console or CLI (palyra approvals list) to inspect the request crates/palyra-cli/src/args/approvals.rs#5-24.
  3. Decision: The operator issues a Decide command crates/palyra-cli/src/args/approvals.rs#30-42.
  4. Resumption: If approved, the RunStateMachine in the gateway continues the tool execution.

Execution & Approval Data Flow

The following diagram bridges the high-level approval concept to the specific CLI and Sandbox entities. Approval and Execution Flow Sources: crates/palyra-daemon/src/sandbox_runner.rs#147-151, crates/palyra-daemon/src/tool_protocol.rs#82-88, crates/palyra-cli/src/args/approvals.rs#30-42

Sandbox Integration

The Policy Engine works in tandem with the Sandbox Runner. While Cedar determines if a tool can run, the SandboxProcessRunnerPolicy determines how it runs crates/palyra-daemon/src/sandbox_runner.rs#81-93. Before execution, the runner validates that the requested_hosts match the allowed_egress_hosts defined in the policy if EgressEnforcementMode is set to Strict crates/palyra-daemon/src/sandbox_runner.rs#186-194. Sources: crates/palyra-daemon/src/sandbox_runner.rs#47-93, crates/palyra-sandbox/src/lib.rs#8-13