Policy as code for AI agents
Policy as code expresses operating rules in a machine-evaluable form. Each rule can be versioned, tested, approved, and applied to a proposed agent action before the action reaches a tool or system of record.
KLA evaluates the agent, action, tool, permissions, and business context together. Every Decision Request resolves to allow, warn, require approval, or block with explicit reason codes.
- 01Proposed actionIssue refund · EUR 12,400
- 02Policy checkpointrefund.manual_review
- 03Decisionrequire_approval
- 04Recordlin_01K0A7Y9 · policy v4.2.1
- Decision unit
- Decision Request
- Outcomes
- Allow · Warn · Require approval · Block
- Authoring surface
- Policy Builder
- Runtime surface
- KLA Policy Engine
01: Concept
How policy-as-code checkpoints works in operation
Useful policy is precise enough to execute and clear enough for risk, operations, and engineering teams to review together.
Policy as code expresses operating rules in a machine-evaluable form. Each rule can be versioned, tested, approved, and applied to a proposed agent action before the action reaches a tool or system of record.
- Evaluate the full action context
- Rules can use agent identity, delegated authority, tool, parameters, environment, data boundary, and business attributes in one decision.
- Test rules before publication
- Simulations run representative Decision Requests against draft policy so teams can inspect outcomes and reason codes before a Release is governed by it.
- Return an operational outcome
- The four-outcome model gives the runtime an explicit instruction. A hold creates a Decision Request; a block prevents the action from proceeding.
- Preserve the policy version
- Every verdict records the policy, version, matched rules, and reason codes that governed the action at that moment.
02: KLA implementation
How KLA implements policy-as-code checkpoints
KLA carries one policy model from collaborative authoring through decision-time enforcement and evidence capture.
- 01
Model the operating rule
Policy Builder defines the subject, action, resource, conditions, and outcome using the same vocabulary operators recognize.
Output · Draft policy
- 02
Simulate representative actions
Test cases cover ordinary traffic, thresholds, missing authority, restricted data, and exception paths.
Output · Simulation results
- 03
Approve and publish
The reviewed policy is versioned and published for the intended tenant, environment, agents, and tools.
Output · Published policy version
- 04
Evaluate at the checkpoint
The KLA Policy Engine resolves each Decision Request before the governed action commits and writes the verdict into Execution Lineage.
Output · Verdict and reason codes
Example · Customer refund
A threshold becomes an enforceable decision
A service agent proposes a refund above the amount delegated to automated processing. The policy creates a controlled hold at the action boundary.
The refund remains inside the original Process. KLA resumes the held action after approval and links the policy decision, reviewer rationale, and downstream result.
- Decision Request receivedreceived
refunds.issue · EUR 12,400 · agent customer-resolution-eu
- Rule matchedheld
refund.manual_review.above_10000 · policy v4.2.1
- Reviewer approvedapproved
Senior refund analyst · rationale and evidence attached
- Outcome recordedrecorded
Refund executed · source result correlated to Lineage Record
04: Evidence record
What KLA records for review
The verdict becomes durable evidence that the published rule operated on the specific action.
| Record layer | Captured evidence | Review purpose |
|---|---|---|
| Decision context | Agent, principal, action, tool, parameters, environment, and business attributes | Reconstruct the facts evaluated by the policy |
| Effective authority | Tool grant, data boundary, role, and authority snapshot | Show the access boundary in force at decision time |
| Policy verdict | Policy ID, version, outcome, matched rules, and reason codes | Explain why the runtime allowed, warned, held, or blocked the action |
| Result | Decision Request, reviewer outcome, tool response, and resulting state | Connect the rule to the final operational effect |
05: Connected controls
Follow the complete governed action path
The four concepts operate together across one action. Continue with the control layer closest to your next question.
06: FAQ
Questions about policy-as-code checkpoints
Definitions, runtime behavior, integration, and evidence boundaries for this control layer.
- What is policy as code for AI agents?
- Policy as code is a versioned, testable representation of the rules that govern an agent action. It evaluates the proposed action and its context before execution and returns an explicit runtime outcome.
- What outcomes can a KLA policy return?
- The KLA Policy Engine returns allow, warn, require approval, or block. Require approval pauses the action and creates a Decision Request in Decision Desk. Block prevents the action from reaching the governed tool.
- Can a team test a policy before it governs production actions?
- Yes. Policy Builder Simulations replay representative Decision Requests against a draft. Teams can inspect the outcome and matched rules before approving and publishing the policy.
- Does policy as code require one agent framework?
- KLA accepts Decision Requests through SDK checkpoints and APIs. The same policy model can govern agents built with different frameworks and providers.
- How does KLA prove which policy governed an action?
- The Lineage Record stores the policy ID, version, verdict, matched rules, reason codes, and action context. Related approvals and downstream outcomes share stable correlation identifiers.
Start with one action
Put one consequential action behind a policy checkpoint
Map the action, authority, outcomes, and evidence fields with the KLA team, then validate the policy against representative requests.