Policies Use Cases

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

​Use Case 1: Business Hours Execution Policy

​Purpose

​Policy Logic (Rego)

​Create the Policy (CLI)

​Attach Policy

​Validate Before Enabling (CLI)

​Runtime Behavior

​Example Usage Scenarios

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

​Purpose

​Policy Logic (Rego)

​Create the Policy (CLI)

​Attach Policy

​Validate Policy Behavior (CLI)

​Runtime Behavior

​Example Usage Scenarios

Use Case 1: Business Hours Execution Policy

Purpose

Policy Logic (Rego)

Create the Policy (CLI)

Attach Policy

Validate Before Enabling (CLI)

Runtime Behavior

Example Usage Scenarios

Use Case 2: Required Labels for Governance and Cost Allocation

Purpose

Policy Logic (Rego)

Create the Policy (CLI)

Attach Policy

Validate Policy Behavior (CLI)

Runtime Behavior

Example Usage Scenarios