Policy-Gated Execution

When an enterprise AI agent tries to do something consequential (issue a refund, send a document for review, call an external API), KLA Control Plane evaluates that action against policy before it runs. KLA Control Plane is a govern-in-place runtime safety, audit, and governance layer for AI agents: you instrument your existing agents instead of re-platforming them. Policy-gated execution is the mechanism that decides, in real time, whether an action proceeds, proceeds with a warning, pauses for a human, or is stopped. This page explains the decision model and how a paused action becomes an Escalation routed to the Decision Desk.

The Four Decision Outcomes

Every policy evaluation in KLA resolves to exactly one outcome. The outcomes are ordered by precedence: when multiple rules match an action, the strongest applicable outcome wins.

Precedence makes the model fail-closed and predictable. If a broad rule says allow but a narrower, higher-precedence rule says require_approval, the action is paused. A single block anywhere in the matching set stops the action regardless of how many allow rules also matched.

flowchart LR
  A["Agent action"] --> B{"Policy Engine decision"}
  B -->|allow| C["Execute"]
  B -->|warn| D["Execute and record advisory"]
  B -->|require_approval| E["Create Escalation"]
  E --> F["Decision Desk"]
  F -->|approved| C
  F -->|rejected| G["Stop action"]
  B -->|block| G

How an Action Is Evaluated

The agent (or the KLA SDK on its behalf) submits a Decision Request: the action plus its context. Context includes the calling agent, the tool being invoked, the parameters, and any business attributes you attach (transaction amount, customer tier, document classification). KLA evaluates this request against the policies currently published for your tenant and returns one of the four outcomes.

curl https://api.kla.digital/v1/decisions.evaluate \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: acme" \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "claims-triage",
    "action": "execute_refund",
    "attributes": { "amount": 420.00, "customer_tier": "standard" }
  }'

A require_approval response includes the identifier of the Escalation that was opened, so your integration can show the end user that the action is awaiting review rather than failing.

{
  "outcome": "require_approval",
  "reasonCodes": ["REFUND_OVER_THRESHOLD"],
  "remediation": "Refunds above $100 require a reviewer. This request was routed to the Decision Desk.",
  "escalationId": "esc_01HZ8K..."
}

Reason Codes and Remediation

Every non-allow decision carries two things beyond the verdict: one or more reason codes and remediation guidance. A reason code is a stable, machine-readable identifier (for example REFUND_OVER_THRESHOLD) that explains why the outcome was reached. Remediation guidance is a short, human-readable instruction on what to do next.

This pairing serves all three readers. Developers branch on reason codes instead of parsing prose. Reviewers at the Decision Desk see plain-language context for the action in front of them. Compliance officers get a consistent vocabulary that maps cleanly onto control frameworks. Reason codes and remediation are required on warn, require_approval, and block outcomes so that no denial or pause is ever a silent dead end.

The Policy Engine

KLA evaluates policies at the application layer, close to the agent action and its business context. The policy engine combines two kinds of checks:

• Access checks decide whether the caller may use the tool, data source, workflow, or action at all.
• Runtime checks evaluate the action in context (the tool and its arguments, its destination, the model metadata, and the business attributes you attach) against the policy pack you published.

Both kinds of checks resolve to the same four customer-facing outcomes: allow, warn, require_approval, or block. The strongest matching outcome wins, so a runtime check can still pause or stop an action even when the caller is otherwise allowed to use the tool.

# Policy rules (illustrative): refunds over $100 pause for review
- rule: low-value-refund
  when:
    tool: execute_refund
    amount: "<= 100.00"
  then:
    decision: allow
    reasonCode: REFUND_WITHIN_THRESHOLD

- rule: high-value-refund
  when:
    tool: execute_refund
    amount: "> 100.00"
  then:
    decision: require_approval
    reasonCode: REFUND_OVER_THRESHOLD
    route: Decision Desk

In this example, a $420 refund matches the second rule and resolves to require_approval, pausing execution and opening an Escalation. A $40 refund matches the first rule and proceeds.

Where Approvals Go

A require_approval outcome creates an Escalation: a paused unit of work waiting on a human decision. Escalations land in the Decision Desk, where an authorized reviewer sees the action, its attributes, the reason codes, and the remediation guidance, then approves or rejects. Approval resumes the original execution exactly where it paused; rejection stops it. The full sequence (the request, the decision, the Escalation, and the reviewer's verdict) is captured as a Lineage Record, giving you a defensible trail for every gated action.

Policy enforcement at KLA lives at the application layer, close to the agent action, which is where business context like amount and customer tier is available. Infrastructure-level admission controls can also enforce policy at the platform boundary, but the runtime gating described here is what governs agent behavior in place.