Highlights
A blocklist moves the risk; it does not remove it: people switch assistants.
Most security teams cannot see which agents their employees already run.
Enforce at the action, then teach the human behind it.
The blocklist reflex
Ask a security team how it plans to govern AI agents and the first answer is a list: approved tools in, everything else out. It is the reflex that governed shadow IT a decade ago. Draw a perimeter and defend it.
Perimeters leak, and this one leaks in two places. A security services leader told me this week that the vast majority of his customers "don't know what agents are being used." You cannot block what you cannot see. And an employee blocked from one assistant tends to open another, often a personal account at home, beyond the reach of any control you own.
Here is the claim: an agent is not a new kind of user. It is a human's judgment, extended and accelerated, so agent risk is human risk with a longer lever. Govern the pair, not the tool.
Visibility moves below the desktop
A security leader at an early-stage company described where his own gaps sit. His endpoint tooling already handles most desktop agent misbehavior. The harder problem is coded workspaces running in sandboxes where system call visibility disappears. What he wanted to see was data flow: when customer data crosses a trust boundary inside an agent session, and through which connection.
Look at the unit he chose. Not the tool, but the flow. And behind every flow is a person who started it, with a deadline and a reason.
Policy at the moment of action
A policy written as a document is a wish. A policy enforced at the moment of action is a control. The workable responses are three: watch it, nudge it, or block it. The nudge matters most, because it carries the policy's reason to both the agent and the person at the instant of the decision, which is the only time a lesson reliably lands.
One advisor described the everyday version: employees using Claude and ChatGPT within policy, and a tool like Grok showing up outside it. He did not want a ban. He wanted the violation to trigger a short reminder.
Why the human stays in the loop
Every violation says something about a person: which team, which habit, which pressure. A violation that sends a short lesson to the employee turns enforcement into education, and feeds the same risk picture as a failed phishing test. One column, not two.
Teams that build a separate program for agents will end up reconciling two views of the same employee, with the agent view missing the context that explains it.
A narrower claim
Do not buy a separate agent security program. Extend the human risk program you already run: same policy, same risk score, same lessons, now applied at the action. Cimento is a human risk company, which is why we put the agent in the human column. The employee is still the one who handed it the keys.
Key Takeways
Inventory which agents and MCP servers your employees actually use this month.
Write your AI policy so it can be enforced at the action, not only read.
Default to nudge before block, and measure what the nudge changes.
Feed agent violations into the same risk score as phishing and training.
