Least privilege does not govern AI agents. Approval does.

The industry's response to what an AI agent can reach is a permissions project: scope down what the agent can touch. That response is correct and overdue. It is also not the response that governs what the agent does with the access it keeps. A new report from Opsin Labs, the research arm of the enterprise security company Opsin, puts a number behind what security leaders already suspected: most agents provisioned past their starting defaults end up with broad, standing access rather than the narrow set of permissions their task requires, and a striking share are built by employees outside engineering entirely, faster than the provisioning discipline security teams rely on to scope access safely.

The report and the instinct behind it

Opsin Labs' first research publication, the State of Agentic Adoption report, studied production environments across eight industry verticals and found what most security leaders suspected but had not measured: enterprises now run roughly one agent for every employee, live or in draft, and adoption accelerated sharply in the first half of the year. Engineering is not building most of them. Sales, customer success, and operations teams are, solving their own workflow problems, which means the people scoping access to a system are often the same people who need broad access to make the agent useful.

The instinct to respond with a permissions project is sound, and it deserves the credit it is getting. An agent with standing access to everything it might someday need is a wider target if a prompt gets hijacked, a credential leaks, or the agent misreads its own instructions. The first agent-run intrusion disclosed on a major platform this year ran on harvested credentials and standing scope, exactly the exposure a permissions project closes. Narrowing access narrows what a bad day costs.

What scoping fixes, and what it leaves ungoverned

A permissions project cannot evaluate whether any single action the agent takes was correct. That is by design. Scope answers a static question, set once when the agent is provisioned and revisited on whatever cadence the security team can sustain. Governance answers a live question, asked fresh every time the agent proposes to do something. An agent that can only read a customer record and draft a follow-up email is properly scoped. It can still draft a follow-up email that misstates a contract term, contradicts what a different system says about the same account, or goes out days after it should have. Narrow access did not cause that mistake, and narrow access does not catch it. Nothing in the permissions model was built to.

A human approves, edits, or rejects a proposed action before it executes, and that step is what closes the gap a scoping exercise leaves open. Every proposed workflow at Nodes carries the evidence behind it and the cost of acting against the cost of waiting, and a designated person decides before anything happens across the systems it touches. The decision produces a signed Decision Trace regardless of which identity made the request: what was proposed, what evidence supported it, what a human changed or approved, and when.

For the workflows that carry the most consequence, a second signer reviews before execution, a separate checkpoint that has nothing to do with what the agent was permitted to reach and everything to do with what it was about to do. All of this runs inside the customer's own VPC, single-tenant, with no data egress, so the approval layer sits inside the same boundary as the access it is checking rather than a separate audit tool nobody consults until something breaks. Digital labor still needs a management layer for the same reason a new hire needs a manager: access to a system is not the same as authority over what happens on it.

The distinction matters because permission scoping and action governance solve different failure modes, and an enterprise that only fixes one believes it fixed both. A scoped agent with no approval gate can still take a wrong action inside the narrow lane it was given, and nobody sees it happen until the output causes a problem somewhere downstream. An unscoped agent with a real approval gate still carries the full blast radius of a broad credential, and a compromised one can still read and reach far more than it should. What it has not done is push a wrong action into a downstream system on its own, because a human still reviews what it proposes before anything executes. The second enterprise has a security finding to close. The first enterprise has already shipped a decision nobody checked.

Where least privilege breaks down: the read-only case

Push the scoping argument to its cleanest case and the gap gets sharper, not smaller. Take an agent limited to read-only access on a single system, the tightest permission footprint a provisioning team can hand out. Read-only access cannot corrupt data and cannot trigger an external action on its own, which is exactly why it clears most security reviews quickly. But a read-only agent can still surface a wrong pattern, a stale signal, or a recommendation built on data that changed an hour ago, and a manager who trusts the agent because security already reviewed it will act on that recommendation anyway. The permission model did its job. The manager acted on a wrong recommendation anyway, and the security review that cleared the agent is part of why they trusted it.

The report's other finding sharpens the same point instead of softening it. Two thirds of these agents come from outside engineering, which means the person who scopes an agent's access and the person who will act on its output are often the same person. Ask that person to tighten permissions and they will, because a tighter permission list still lets the agent do the job they built it for. Ask that person to say what should happen before the agent's recommendation reaches a client, a contract, or a paycheck, and the permissions project has nothing to hand them. That question was never the permissions team's to answer. It belongs to whoever owns the workflow the agent sits inside, and it stays unanswered until an approval step exists for them to use.

This is also where the current response to over-permissioning diverges from the response the AI agent insurance market is building: one prices what happens after a wrong action, the other narrows what an agent can reach before it acts. Both are reasonable, and neither answers the question that sits between them, which is what happens at the exact moment the agent decides to do something. A claims payout after the fact and a tighter access list before the fact both skip the one checkpoint that would have caught the actual mistake: a person looking at the specific proposed action, with its evidence attached, before it goes out.

What governs the action

The proof here is architectural, not statistical, because the claim is about a mechanism rather than an outcome measured after the fact. The system proposes and then waits: it finds work, attaches the evidence, and stops until a person acts on it. Waiting is the governance. A workflow that skips it because the agent's permissions were already narrow has moved the risk from the access layer to the decision layer, where nobody was watching for it.

The Nodes architecture documents the same boundary from the inspection side: single-tenant deployment inside the customer's own environment, customer-owned weights, and a Decision Trace on every action a workflow takes, available for a security team to query directly rather than reconstruct after an incident. That evidence exists because the Decision Traces methodology treats the approval step itself as the object worth logging, instead of a footnote to the access review. A permissions audit tells a CISO what an agent could reach six months ago. A Decision Trace tells them what a human approved this morning, and why.

The two projects enterprises need running at once

None of this argues against the permissions work underway right now. It argues against treating it as the finish line. The right posture runs both projects in parallel: scope every agent to what its task requires, and put an approval gate in front of every action regardless of how tight that scope already is. The two are related and they are not the same, and the industry currently has a report proving the first is unfinished and almost nothing proving the second has started.

Before the next agent gets scoped down and shipped, somebody in the room should be able to name the person who sees its first real action before it happens. If nobody can name that person, the access list got shorter and nothing else changed.

Sources

• Opsin Labs, State of Agentic Adoption Report
• Decision Traces: What Multi-System Data Fusion Reveals About Institutional Knowledge in Enterprise Hiring

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.