What controls does an enterprise need before AI agents act on real systems?

What the list is for

The controls below are written as tests. Each states what must be true on the path of the call, so a buyer or an engineer can check it. None depends on a particular framework, model, cloud or vendor.

The order matters. The first six govern the action. The last four govern the platform that governs the action.

The required-controls checklist

1. Identity bound to principal. Every call carries a verifiable identity for the agent, with an owner and a risk tier, and, when the agent acts for a person or system, the identity of that principal. Pass: your identity provider verifies both on the call. Fail: identity is a header the agent writes about itself.

2. Least privilege per action. Policy is written for this agent, this action, this target, not for the agent as a whole. Pass: a write to the ledger is a separate decision from a read. Fail: an agent trusted for one job inherits trust for all of them.

3. Budget on the call. A spend limit is enforced when the call is made, with spend attributed per agent and rolled up to the originating request. Pass: the call that would breach the budget does not execute. Fail: finance sees the overrun in next month’s report.

4. Human approval inline. High-risk actions stop and wait for a named person to approve them, on the call. Pass: the approval and the action land in the same record. Fail: sign-off is a design review or a dashboard someone checks next quarter.

5. Whole-chain stop. Any agent, or a whole chain of agents, can be stopped immediately and stays stopped without waiting for credential expiry or rollback. Pass: the chain loses its credentials and a record shows nothing was authorised after the stop. Fail: revoking the assistant leaves the payments agent still moving money.

6. Tamper-evident record. Every call, decision and outcome is recorded with the agent, the authority it acted under and the time, in a form a third party can verify without trusting the system that wrote it. Pass: an auditor verifies the chain offline. Fail: the evidence is a log you control.

7. Monitor before enforce. The platform can run in a mode that observes every call, builds the inventory, shows what policy would have done, and refuses nothing. Pass: the estate is visible before any agent is blocked. Fail: turning it on blocks agents nobody knew about.

8. Key custody stays with you. Credentials for downstream systems are encrypted under a key held in your own vault or key service, and the governing platform is a crypto user, not a custodian. Pass: rotating the key is your operation. Fail: the vendor holds the master key.

9. Envelope-only scope. The platform governs the request envelope, identity, target, action, size, delegation chain, and does not read the payload. Pass: message bodies pass through unread. Fail: the platform becomes another place your data lives.

10. Failure behaviour decided in advance. You decide, before go-live, what happens if the platform itself fails: keep applying the last decision for that agent and action, or refuse until recovery. Pass: the choice is configured and tested. Fail: the platform fails open or fails closed by accident.

What is deliberately not on the list

Content guardrails answer a different question. They inspect what is in a request and do not know who is calling. They belong inline, as a policy step scaled to the agent’s risk tier, with the verdict recorded, but they do not replace any of the ten. Tracing is not on the list either: a trace of what an agent did yesterday does not stop what it does today.

How KPATH maps to each control

Control	How KPATH meets it
1. Identity bound to principal	Met. Every call carries the agent’s identity with owner and risk tier, verified against your identity provider, and policy can insist the person an agent acts for is verified.
2. Least privilege per action	Risk-tiered policy applied per action at the Policy Enforcement Point; a governed directory lists only the services policy allows.
3. Budget on the call	Budget enforced on the call itself; spend attributed per agent and rolled up to the originating request.
4. Human approval inline	High-risk actions wait for a person at the call; approval and decision recorded together.
5. Whole-chain stop	Kill switch for any agent or a whole chain; the chain loses its credentials and stays stopped; containment proof shows nothing was authorised after the stop. Behaviour watch pauses out-of-pattern high-risk agents.
6. Tamper-evident record	Met. The record is signed and tamper-evident, verifiable offline without trusting KPATH, exportable to write-once storage and streamed to your SIEM.
7. Monitor before enforce	Every deployment starts in monitor mode: observe only, enforce no policy, rewrite no agents. Flip to enforce by repointing egress.
8. Key custody stays with you	Met. Credentials are encrypted under a key in your own vault or key service. KPATH is a crypto user, not a custodian.
9. Envelope-only scope	KPATH governs identity, target, action, size and delegation chain. Of the payload, it reads only the values you declare for a rule, such as a payment amount. Guardrails run inline inside your boundary.
10. Failure behaviour decided in advance	Several redundant enforcement points; you choose last-decision or refuse-until-recovery.

Using the list

Take the list into a vendor evaluation or an internal build review and mark each control pass or fail on a live chain, not on a slide. The controls most estates fail are four, five and six: the gap between governance on paper and enforcement at the moment of action.

Start with monitor mode: connect the agents, see what they reach, then apply the remaining controls to the actions that carry risk.