Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.kubiya.ai/llms.txt

Use this file to discover all available pages before exploring further.

Policies enforce guardrails on when, how, and by whom automations are executed. They apply consistently across Environments, Teams, and Agents, and are evaluated by Kubiya’s built-in OPA engine on every task or workflow step. Below are two real-world policy use cases that show why a policy is needed, how to write it, and how to create and validate it using the CLI.

​
Use Case 1: Business Hours Execution Policy

A company wants to restrict automation runs to business hours (weekdays 09:00–17:00). All non-critical tasks should be blocked outside these hours to avoid unintended changes during off-hours.

​
Purpose

  • Prevent accidental production changes at night or on weekends
  • Reduce risk from unattended automation
  • Enforce consistent operational windows across all agents and teams
  • Provide clear violation messages when a run is attempted outside allowed hours

​
Policy Logic (Rego)

The policy checks current time and day provided in the input and only allows runs during the defined window. 
package business_hours

default allow = false

allowed_time {
    input.time.hour >= 9
    input.time.hour < 17
    input.time.weekday >= 1   # Monday
    input.time.weekday <= 5   # Friday
}

allow {
    allowed_time
}

violations[msg] {
    not allow
    msg := "Execution allowed only Monday–Friday, 09:00–17:00"
}
Save this as business_hours.rego.

​
Create the Policy (CLI)

kubiya policy create \
  --name "business-hours-policy" \
  --file business_hours.rego \
  --validate

​
Attach Policy

Attach it to the relevant Environment(s) and/or Teams where execution should be restricted. (Attachment follows the standard mechanism: policies can be associated with Environments, Teams, and Agents.)

​
Validate Before Enabling (CLI)

Test the policy using different timestamps. Allowed example: 
kubiya policy evaluate \
  --policy-file business_hours.rego \
  --input '{"time":{"hour":10,"weekday":3}}' \
  --query "allow"
Expected: true Denied example: 
kubiya policy evaluate \
  --policy-file business_hours.rego \
  --input '{"time":{"hour":22,"weekday":6}}' \
  --query "violations"
Expected: "Execution allowed only Monday–Friday, 09:00–17:00"

​
Runtime Behavior

When any task runs during off-hours:
  • The evaluator loads the policy
  • The run is blocked
  • The violation message appears in the task log
  • No action is executed

​
Example Usage Scenarios

  • A user tries to deploy a service at midnight → blocked
  • A workflow tries to modify infrastructure on a Saturday → blocked
  • A read-only diagnostic runs at 14:00 on Tuesday → allowed

​
Use Case 2: Required Labels for Governance and Cost Allocation

The organization requires that every task include metadata labels: owner, service, and purpose, to maintain traceability and cost allocation rules. Tasks missing these labels must be rejected.

​
Purpose

  • Ensure all automation runs are traceable
  • Enforce mandatory metadata for audit and billing
  • Apply uniform governance across all teams
  • Stop runs that omit required labels

​
Policy Logic (Rego)

package required_labels
default allow = false
required := {"owner", "service", "purpose"}
missing[label] {
    label := required[_]
    not input.labels[label]
}

allow {
    count(missing) == 0
}

violations[msg] {
    some label
    missing[label]
    msg := sprintf("Missing required label: %v", [label])
}
Save as required_labels.rego.

​
Create the Policy (CLI)

kubiya policy create \
  --name "required-labels-policy" \
  --file required_labels.rego \
  --validate

​
Attach Policy

Associate it with Environments or Teams where metadata enforcement is required.

​
Validate Policy Behavior (CLI)

Allowed input (all labels present): 
kubiya policy evaluate \
  --policy-file required_labels.rego \
  --input '{"labels":{"owner":"alice","service":"billing","purpose":"deploy"}}' \
  --query "allow"
Expected: true Denied input (missing label): 
kubiya policy evaluate \
  --policy-file required_labels.rego \
  --input '{"labels":{"owner":"alice","service":"billing"}}' \
  --query "violations"
Expected example message: "Missing required label: purpose"

​
Runtime Behavior

When a workflow or tool call runs:
  • The evaluator loads the task’s metadata
  • If any required label is missing, the step is blocked
  • The violation explicitly states which label is missing

​
Example Usage Scenarios

  • Developer launches a build without purpose → blocked
  • Automated cost-allocation job submits metadata with all fields → allowed
  • Platform engineer runs a workflow missing service → blocked
  • Team triggers an audit job with full metadata → allowed