Policy Builder

Policy Builder is the authoring workspace of the KLA Control Plane, served at the route /policy-studio. The KLA Control Plane is a govern-in-place runtime safety, audit, and governance layer for enterprise AI agents: you instrument your existing agents instead of re-platforming them. Policy Builder is where you write the rules that decide what those agents are allowed to do. Every consequential agent action, whether issuing a refund, sending a document for review, or calling an external API, is checked against the policy you publish here before it runs. This page covers how you set a policy up, the two ways to edit it, how Simulation proves it behaves before publish, and what a signed policy pack is.

Who uses it

Policy Builder is shared ground for two roles. Compliance, risk, and audit officers own the intent (what must be approved, what must be blocked, where the thresholds sit) and increasingly author rules directly. Developers and integrators own the precision: the exact attributes, conditions, and reason codes the runtime evaluates. The workspace is built so both can work in the same draft without one blocking the other: a non-technical author can express an intent and a developer can refine the underlying condition.

Intent-led setup

You do not start from a blank YAML file. Policy Builder opens with intent categories: plain-language starting points that scaffold a working rule you then tune.

• Route by sensitivity: send higher-risk actions down a stricter path.
• Require approval on high-risk operations: pause an action for a human decision.
• Block a tool action: deny a specific capability outright, such as a database write.
• Enforce data boundaries: keep regulated data inside an approved region or system.

Each intent produces a draft rule with the right structure and sensible defaults. You attach the business attributes that matter to your use case, such as transaction amount, customer tier, and document classification, and set the thresholds.

Visual editor or raw rule YAML

Policy Builder gives you two synchronized views of the same rule:

• Visual condition builder: assemble conditions from fields, operators, and values without writing YAML. Best for fast authoring and for reviewers who want to read intent, not syntax.
• Raw YAML editor: edit the underlying rule definition directly for full expressiveness, including compound conditions, runtime checks, reason codes, remediation, and approval routes.

Both views write the same draft, so you can sketch an intent visually and drop into YAML to finish it.

# Draft rule (illustrative): high-value refunds pause for a human
rule: high-value-refund
when:
  tool: execute_refund
  amount: "> 100.00"
then:
  decision: require_approval
  reasonCode: REFUND_OVER_THRESHOLD
  route: Decision Desk

The require_approval decision is what tells KLA to pause execution and route the action to the Decision Desk. A block decision would stop the action outright.

Simulate before you publish

A draft never goes straight to the runtime. You run a Simulation: a policy test run that replays representative Decision Requests (an action plus its context) against the draft and shows how each one resolves. KLA's decision model has four outcomes in precedence order:

Simulation lets you confirm, before anything is live, that a $420 refund pauses and a $40 refund passes, without touching a running system. KLA blocks publishing of any draft that fails lint, so a require_approval or block outcome missing its reason code or remediation guidance is caught here, not in production.

Compiled, signed policy packs

When a validated draft is published, KLA compiles it into a signed policy pack: a versioned, cryptographically signed bundle that the runtime loads to evaluate policy. Signing means evaluation is tamper-evident, since the runtime only enforces packs it can verify, and versioning means every decision can be traced back to the exact policy that produced it. Compilation also makes evaluation fast enough to sit in the path of live agent actions.

flowchart LR
  A["Intent or YAML edit"] --> B["Draft policy"]
  B --> C{"Simulation"}
  C -->|outcomes wrong| B
  C -->|outcomes correct| D["Publish"]
  D --> E["Signed policy pack"]
  E --> F["Runtime enforcement"]

How it connects

Policy Builder is the source of the rules; two other modules are where those rules take effect.

• Policy-Gated Execution is the runtime mechanism that evaluates every Decision Request against your published pack and returns one of the four outcomes. The policies you author here are exactly what it enforces.
• Decision Desk is where a require_approval outcome lands. When a rule pauses an action, KLA opens an Escalation and routes it there for an authorized reviewer to approve or reject.

Author the rule in Policy Builder, prove it in Simulation, publish the signed pack, and the runtime governs every matching action from that moment on.