Highlights
A public 8-K disclosed an employee pasting company data into an AI tool
Always allow is a standing grant made by one human in one click
Agent risk arrives through the human column, not around it
The agent security market has settled on a story, and it is a machine story. Sandbox the agent. Scope its credentials. Log its calls. Put a policy engine in the path and an observability layer underneath. All of it is correct, all of it is necessary, and all of it treats the agent as the thing with agency.
Then you sit in a room where a security leader cites a public 8-K filing: an employee pasted company data into an AI tool, and the company had to disclose it. No agent escaped a sandbox. No credential was stolen. A person made a decision with their hands.
I have started to think the most consequential control surface in agentic security is not the runtime. It is a dropdown with two options. Allow once, or always allow. That is the thesis: agent risk enters the enterprise through the human column, and the industry is building for the column next to it.
One click, standing access
Consider what "always allow" actually is. It is a person granting permanent, unattended authority to a non-deterministic system, in a single click, usually while trying to finish something else. There is no second approver. There is no expiry. There is no record the person will remember making.
We already have a name for a small human decision that hands an outside process durable access. We call it a phishing click, and we have built an entire industry around measuring how often people make it.
The uncomfortable symmetry is that "always allow" is a better outcome for an attacker than a phishing click, because it is sanctioned. It leaves no suspicious artifact. And an agent granted a senior person's permissions inherits that person's reach: their repositories, their approvals, their financial systems. Permissions flow downhill from whoever clicked.
What one team decided to watch
The clearest signal I saw this week came from a proof of concept where the customer set the success criteria themselves. Their primary pillar was not agent containment. It was observability on human behavior: which employees are using which AI tools, what moves between those tools and company systems, where sensitive material is being pasted, and whether a nudge arrives in the moment with a link to the relevant policy.
They did not describe that as agent security. They described it as human risk. They are right, and they got there before most vendors did.
Two columns, one ledger
The practical consequence is a merge, not a new product category. Agent behavior and human behavior belong in the same risk view, because they are joined at the click. The employee who approves everything without reading is the employee whose agents have the widest blast radius, and today those two facts live in separate tools owned by separate teams reporting different numbers.
There is a second half to this, which is testing agents the way we test people: unannounced, at runtime, before they act rather than after they log. We run that, we see things in it, and I am not going to put our internal numbers in a public post until I can stand behind every one of them.
So the narrow claim, and it costs nothing to act on. Find out who in your organization is clicking "always allow," on what, and how often. That list is a human risk list. It probably rhymes with the one your awareness program already keeps, and if it does not, you have learned something more interesting than any dashboard could have told you.
Key Takeways
Inventory which people grant standing permissions to agents, and to which systems.
Treat "always allow" as a reportable event inside your existing awareness program.
Test agents the way you test people: unannounced, at runtime, before they act.
Put AI tool usage in the same risk view that already holds phishing and data handling signals.
