Highlights
A three-layer AI governance stack, defeated daily by one engineer's scheduled script
The riskiest agent operators are your best employees, not your phishing-test failures
Audits increasingly cannot tell agent actions from human ones under borrowed credentials
Enforcement bolted to your EDR contract breaks the day you switch vendors
The emerging playbook for AI governance is architecture-shaped: deploy an endpoint client, a browser extension, and an MCP gateway, push all three through MDM, route every model call through a choke point, and enforce policy centrally. Sandbox the agent, guardrail the model, scan the traffic.
This week, a security leader walked me through the most complete version of that playbook I have seen running in production. All three layers live on every workstation. A scanner detects MCP configurations inside developer IDEs and rewrites the connection URLs to point at the gateway, so every agent call is inspected by default. Sanctioned tools are provisioned to everyone. Unsanctioned models are blocked outright. It is impressive, disciplined work.
And one of his engineers defeats it every day. The engineer doesn't like security rewriting his config files, so he wrote a script that rewrites his MCP connections back to base and runs it on a cadence, overwriting the config again and again in a standing fight with both the MDM and the scanner. The vendor is shipping a fix. The engineer will look for the next seam. As the security leader put it, this is the constant arms race.
Here is the thesis that anecdote proves. An agent has no risk profile of its own. It inherits one, the way a thrown object inherits velocity, from the human who launched it: their permissions, their skill, their patience, and their opinions about your controls. Score the agent in isolation, and you are measuring the projectile while ignoring the arm.
The bypass is the org chart
Notice who won that exchange. Not a careless employee, and not an attacker: a capable engineer with strong preferences. A security leader in financial services made the same observation to me that week. The employees who fail phishing simulations are not the employees building agents. The builders are the power users, wiring agents into workflows that quietly cross policy lines. Your existing risk signals point at one population. Your agent risk lives in another.
The head of security at a leading AI company completed the triangle: after the fact, audit trails often cannot distinguish actions a human took from actions an agent took under that human's credentials. An employee instructs an agent, the agent touches data it should not, and nothing in the log separates intent from automation. Inherited identity produces inherited ambiguity.
Architecture cannot see intent
The same conversation surfaced two quieter technical lessons. First, the ban list is not the usage list: tools this company explicitly prohibits are still in daily use by a meaningful slice of the org, because familiarity beats policy. Second, enforcement anchored to EDR add-on modules is fragile by construction: mid-contract, you cannot buy modules, and coupling AI governance to a single EDR vendor means your controls dissolve the day you swap vendors. Gateways, scanners, and blocklists are necessary. Every one of them assumes the traffic consents to being routed, and the humans decide that.
Start with the humans
Before buying runtime controls, answer three human questions. Who is running agents, and against which MCP servers and data: discoverable today. What is each operator's existing risk history: phishing results, data handling, policy exceptions. And who holds the toxic pairing of broad permissions and a habit of routing around controls.
That inventory will not surface your risky-on-paper population. It will surface your most productive people, which is why blunt blocking fails; the answer is weighting, coaching, and scoped trust. We started Cimento on the belief that security's most underpriced signal is human behavior, and agents have amplified it. The narrow claim: you cannot govern what your agents do until you can name the humans behind them and say, with evidence, how much you trust each one.
Key Takeways
Build the human-to-agent map first: who runs what, with which permissions.
Weight agent risk by the operator's existing behavioral history, not the tool's feature list.
Assume your ban list undercounts real usage; measure what runs, not what is approved.
Avoid coupling AI governance enforcement to a single EDR vendor's add-on modules.
Expect your riskiest agent operators to be high performers, and design for coaching over blocking.
