Skip to main content
The Palyra security model relies on a central policy evaluation engine and a structured tool governance framework. This system ensures that every tool execution or sensitive action is authorized against a set of logic-based policies (using the Cedar policy language) and, where necessary, intercepted for human-in-the-loop approval.

Cedar-Based Policy Engine (palyra-policy)

The palyra-policy crate implements the core authorization logic using the Cedar policy language. It provides a structured way to evaluate whether a principal is allowed to perform an action on a resource within a specific context.

Key Components

Default Policy Logic

The engine uses a “deny-by-default” baseline. The internal Cedar policy set defines several critical guards:
  1. Sensitive Action Block: Forbids actions flagged as sensitive if allow_sensitive_tools is false crates/palyra-policy/src/lib.rs#100-105.
  2. Tool Execution: Permits tool.execute only if the tool is allowlisted and the principal/channel are authorized crates/palyra-policy/src/lib.rs#120-127.
  3. Read-Only Actions: Broadly permits non-mutating status and health checks crates/palyra-policy/src/lib.rs#107-118.
Sources: crates/palyra-policy/src/lib.rs#1-215

Tool Governance and Decision Flow

When an agent proposes a tool execution, the system enters a multi-stage governance flow to determine if the execution can proceed, requires approval, or must be blocked.

Tool Execution Flow (Natural Language to Code Entities)

The following diagram bridges the high-level intent of executing a tool to the specific Rust functions and structs that handle the governance logic. “Tool Execution Governance Flow” Sources: crates/palyra-daemon/src/application/run_stream/tool_flow.rs#105-134, crates/palyra-daemon/src/application/approvals/mod.rs#100-135, crates/palyra-daemon/src/tool_protocol.rs#29-34

Sensitive Action Classification

Palyra classifies certain tools and actions as “sensitive,” requiring explicit escalation. Sources: crates/palyra-daemon/src/tool_protocol.rs#46-70, crates/palyra-policy/src/lib.rs#40-58

Human-in-the-Loop Approval Loop

If the PolicyEngine determines that approval_required is true, the GatewayRuntimeState suspends tool execution and generates a PendingToolApproval.
  1. Approval Creation: build_pending_tool_approval creates a PendingToolApproval record with a unique ULID and a prompt containing risk levels and options (e.g., “Allow once”, “Allow for session”) crates/palyra-daemon/src/application/approvals/mod.rs#100-135.
  2. Persistence: The request is recorded in the JournalStore as an ApprovalRequested event crates/palyra-daemon/src/application/run_stream/tool_flow.rs#239-246.
  3. Resolution: Users resolve approvals via the Web Console or CLI. The console_approval_decision_handler processes the response and updates the state crates/palyra-daemon/src/transport/http/handlers/console/approvals.rs#57-82.
  4. Resumption: Once approved, apply_tool_approval_outcome updates the ToolDecision to allow execution crates/palyra-daemon/src/application/approvals/mod.rs#32-64.
Sources: crates/palyra-daemon/src/application/approvals/mod.rs#1-183, crates/palyra-daemon/src/transport/http/handlers/console/approvals.rs#57-155

Tool Attestation

To provide a verifiable audit trail, every tool execution generates a ToolAttestation. This record cryptographically links the execution to the environment and the specific tool call.

ToolAttestation Structure

The attestation includes:

Attestation Generation Flow

“Cryptographic Tool Attestation Flow” Sources: crates/palyra-daemon/src/tool_protocol.rs#73-88, crates/palyra-daemon/src/sandbox_runner.rs#120-126