Stop a data export at the tool boundary.
Check the destination before an agent sends customer data. A request to an approved system can proceed; an export outside the configured Data Boundary stops before the connected tool is called.
The same boundary can protect a system write, an access change or a message. Coverage follows the execution paths you connect.
Customer operations agent
Export customer records
The export tool is not called. The requested destination is outside the policy.
Connect the path you need to control.
A useful checkpoint sits before the side effect and has enough context to evaluate the exact operation being requested.
- Connect the consequential tool call
- Send the proposed action and relevant context through a KLA checkpoint. Coverage depends on which execution paths you connect.
- Enforce the policy outcome
- Allow and warn can proceed. Require approval holds the action for review. Block prevents the governed call.
- Capture the actual result
- Link the downstream response or failure to the original request. Test retries, unavailable dependencies and interrupted approvals as part of the integration.
Show where the request stopped.
Reviewers need to see both the decision and the result returned by the system that executed the action.
- Requested operation
What it contains
Agent identity, tool, parameters and correlation identifier
Question it answers
Which action reached the checkpoint
- Control outcome
What it contains
Policy version, decision, reasons and any linked approval
Question it answers
What the execution path was permitted to do
- Downstream response
What it contains
Captured result, error and timestamps
Question it answers
What the connected system returned
Schemas and examples.
Use the schemas and worked examples to review the integration and evidence requirements.
Read the policy decision modelFind the point where the action becomes consequential.
Bring one tool call and the system it changes. We can identify the checkpoint, required context and failure cases to evaluate.