> ## 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 Use Cases

> Practical OPA policy examples showing how to write, validate, and attach guardrails to Environments, Teams, and Agents to control execution windows, approvals, access, and safety constraints.

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.

```bash theme={null}
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)**

```bash theme={null}
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:**

```bash theme={null}
kubiya policy evaluate \
  --policy-file business_hours.rego \
  --input '{"time":{"hour":10,"weekday":3}}' \
  --query "allow"
```

Expected: `true`

**Denied example:**

```bash theme={null}
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)**

```bash theme={null}
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)**

```bash theme={null}
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):**

```bash theme={null}
kubiya policy evaluate \
  --policy-file required_labels.rego \
  --input '{"labels":{"owner":"alice","service":"billing","purpose":"deploy"}}' \
  --query "allow"
```

Expected: `true`

**Denied input (missing label):**

```bash theme={null}
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**