Skip to main content
Policies let you place guardrails on how automations run: timing, access, safety checks, and limits. Policies are written in OPA Rego and evaluated by Kubiya’s built-in enforcer (the Enforcer Healthy badge shows status in the header). Kubiya Platform Overview

​
When to use

  • Restrict when or where tasks can execute (e.g., business hours; only in prod).
  • Control access to resources or capabilities.
  • Enforce org rules (naming/labels, approvals, MFA, rate limits).
  • Apply the same constraints across many agents/teams without editing each one.

​
How policies fit into Kubiya

  • Scope & attach points: Policies are defined centrally, then associated with Environments, Teams, and/or Agents.
  • Evaluation: When a task runs, all policies attached at applicable scopes are evaluated. If a policy denies the action, the run is blocked and the violation message is shown.
  • Versioning & status: Policies are versioned (e.g., v1) and can be enabled/disabled at any time. The policy card shows associations and last update.

​
Prerequisites

  • You have permission to create policies in the active Control Plane.
  • You know where the policy should apply (Environment, Team, or Agent).

​
Create a policy

  1. Open: Policies > Create Policy.
  2. Details
    • Policy Name: use kebab-case (e.g., business-hours-policy).
    • Description: what it enforces and when it applies.
    • Enable Policy: toggle on to enforce immediately (you can change later).
    • Tags: add keywords (e.g., security, governance).
  3. Policy Content
    • Pick a template (Business Hours, Approved Users, or Blank).
Author Rego. A minimal structure looks like: 
package my_policy

default allow = false

# Allow rules
allow {
  # your conditions
}

# Optional helpful errors
violations[msg] {
  not allow
  msg := "Policy violation: add specific reason"
}
  1. Create Policy: save to publish (initial version v1). You’ll land back on the Policies list.

​
Attach & test

  • Attach
    • Environment: Environments > Edit > Policies > add policy.
    • Team: Teams > Configure > Advanced > OPA Policies > add policy.
    • Agent: Agents > open agent > Policies (visible after creation).
  • Verify
    • Run a small, non-destructive task that should be affected.
    • Allowed runs proceed; blocked runs show your violations[msg] text.
    • The policy card’s associations count reflects where it’s applied; Enforcer Healthy confirms the evaluator is live.

​
Runtime behavior

  • Policies are checked at request time and during execution when relevant.
  • Denies are isolated and return clear reasons; permitted steps continue normally.
  • Policies apply in combination across attached scopes.

​
Manage

  • Enable/Disable from the policy card to roll out or pause enforcement.
  • Edit to publish an updated version; keep the description in sync.
  • Remove associations from Environments/Teams/Agents as needed.

​
Good starter policies

  • Business hours: allow 09:00–17:00 weekdays.
  • Approved users: allow only members of a specific team/project.
  • Require labels: block runs unless owner and purpose labels are present.
  • Rate limiting: bound how often a tool/API can be called.
  • MFA required: restrict sensitive actions unless MFA is verified.

​
Best practices

  • Start permissive in lower environments; tighten for production.
  • Always return helpful violations[msg] so users know how to fix.
  • Scope narrowly, attach strict rules only where needed.
  • Tag consistently (e.g., security, operations, cost) for quick discovery.
  • Iterate safely: disable > edit > re-enable; test with non-destructive tasks.

​
Troubleshooting

  • Runs are blocked unexpectedly: check the violation message; review all policies attached at Environment/Team/Agent.
  • Policy seems ignored: confirm it’s Enabled and actually attached; verify Enforcer Healthy.
  • Tool not allowed: look for a deny rule tied to that tool’s action or to missing labels/approvals.