Policy packs — how authorization works

Orkena authorizes every action before it executes. The mechanism is a policy pack: a versioned set of rules written in Cedar — the AWS-published authorization language — evaluated in-process by Cedar’s Rust evaluator via cedarpy against every proposed action.

The semantics#

• Authorize before execute. Every edge traversal, tool call, credential use and model call is evaluated before any output reaches a system of record.
• Deny is a control, not an incident. When an action is denied, nothing downstream happened. The denial and its record commit in the same transaction.
• Verdicts are permit, deny, or hold. Hold routes to a human approval gate.

Pack structure#

A pack is a set of rules over principals (agents), actions (tool calls, model calls, credential use, edge traversal), resources, and context (taint, data labels, time, region).

// policy.baseline-security v3
forbid (
  action in [Action::"invoke_tool"]
) when {
  resource.side_effects == "irreversible"
  && context.tainted
};

forbid (
  action in [Action::"call_model"]
) when {
  context.secrets_present == true
};

permit (
  principal,
  action,
  resource
) when { context.trusted };

The baseline security pack#

Three rules ship by default:

1. Irreversible + tainted → deny. An irreversible action (payment, credential change, data deletion) derived from untrusted input is denied by default.
2. Secrets in prompt → deny. A model call carrying secrets it was not authorized to see is denied.
3. Four-eyes → hold. High-impact actions open an approval gate with quorum, SLA and escalation.

Evaluation#

Packs are evaluated in-process by the Orkena policy engine — sub-5ms, no network hop. What-if simulation evaluates a proposed pack change against past runs before activation.

Writing a pack#

See Build your first policy pack for the walkthrough and the Policy DSL reference for the full grammar.