Skip to main content
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