Give agents tools with clear limits.
Place policy checks at the action boundary: a system write, an access change, or a data export. Control what the agent can do with the tools it can reach.
The action to govern
Create a purchase order
A working credential can authorize more than the business intends.
An agent may need access to a purchasing system to prepare an order. The business still needs limits on the supplier, amount, and final submission. Those rules belong where the tool call becomes a system change.
The purchase order is ready. The supplier needs review.
A procurement agent requests a purchase order for a supplier outside the approved list. At the connected tool boundary, KLA evaluates the proposed action before the purchasing system receives it.
Create a purchase order
The proposed supplier is outside the approved supplier list.
- Requested by
- Procurement agent
- Destination
- Purchasing system
- Supplier status
- Unapproved
Applicable rule
Purchase orders must use an approved supplier.
Blocked
The purchase order is not submitted. The supplier must be reviewed before a new request.
Scope the tool, the action, and the destination.
Tool access is one part of the policy. The action parameters and destination determine what that access means in practice.
Platform team
The execution path
Connect the relevant tool call to the governed path and verify the downstream boundary.
Business owner
The permitted action
Define allowed suppliers, amount limits, and actions that require a reviewer.
Security team
The access scope
Limit credentials and data access to the systems and operations the agent needs.
Execution Lineage
Inspect the action behind the answer.
Execution Lineage connects the request to the policy decision and the downstream result. A blocked call should be as explainable as a permitted one.
Explore Lineage Explorer- What did the agent request?
- The tool, action parameters, and associated execution context.
- Which rule applied?
- The evaluated policy and its allow, warn, require approval, or block outcome.
- What reached the system?
- The downstream result for an executed call, or the recorded denial for a blocked one.
Define what a successful evaluation must show.
Bring one workflow, the action you need to control, and the people who own its rules. Agree the integration scope and acceptance criteria with KLA.
Discuss your workflow- A permitted request reaches the intended tool with the expected parameters.
- A prohibited supplier or action is blocked before the system changes.
- The team verifies coverage and checks for paths around the configured control.
Can we govern agents we already use?
Start by mapping the agent runtime, tool interfaces, credentials, and execution path. The integration approach depends on those boundaries. Review the supported path with KLA before committing to a rollout.
Does KLA automatically govern every tool call?
Coverage depends on the connected execution path and its access controls. An unconnected tool or a direct route to the target system needs its own integration and verification.
Can some tool calls continue with a warning?
Yes. The policy model includes allow, warn, require approval, and block. Configure the outcome for each action and test both permitted and restricted requests.