Your Agent Doesn't Need OAuth. It Needs a Smaller Key
A single HTTP request. No password, no token, no login. On the other side of it: 233 tools. Shell commands, the database, every agent on the platform, the long-term memory store. All of it, reachable on the open network, by default.
That's CVE-2026-59726, the flaw Noma Labs found in Ruflo, a popular agent-orchestration layer. The fix, shipped in a day, was almost insultingly simple: make the bridge require authentication. The vulnerability was never an exotic exploit chain. It was a door with 233 tools behind it and no lock.
This is the shape of nearly every agent breach worth reading about. Not a clever attacker defeating a strong control, but a weak or over-broad one handing over far more than the job ever needed.
The blast radius of a compromised agent is exactly the scope of its credentials.
Least privilege stopped being paperwork
For years, "least privilege" was the principle everyone cited and nobody implemented. It lived in audit checklists, not in code. You could skip it and mostly get away with it, because the thing holding the over-broad credential was a human who, most days, behaved.
Agents changed the math. Last week we argued you can't prompt your way out of an identity problem: the agent's real identity is the credential it holds, and no instruction overrides what the key can do. So the practical question is the one that matters now. If the credential is the identity, how small should it be?
Smaller than you think. Smaller than is convenient. As small as the single task in front of the agent, and not one scope larger.
A broad grant isn't convenience; it's a loan against a breach you haven't had yet.
Why everyone over-grants anyway
Because scoping is tedious and breadth is one click.
"Full access" OAuth is a single checkbox. A fine-grained token scoped to one repository, read-only, on three paths, is a form with twelve fields and a doc you have to read first. So teams grant the agent god-mode "just to get it working," promise themselves they'll tighten it later, and never do. The broad key becomes load-bearing, and now it's scary to touch.
Ruflo shipped with its bridge wide open because open was the shortest path to a working demo. Default-open always is. It is also how you end up one unauthenticated request away from a stranger spawning agent swarms on your API keys.
Default-open is default-owned.
What "smaller" actually means
Shrinking a credential is four concrete moves, not a vibe.
Scope it to the task. Not "GitHub access," but this repository, read-only, these paths. Not "the database," but this table, these columns. The agent that triages issues never needs to push to main, so its token should not be able to.
Time-box it. A static key that lives forever is a key an attacker inherits forever. Short-lived, auto-expiring credentials turn a stolen token into a problem that lasts an hour, not a career.
One key, one job. Resist the single god-credential reused across every agent and workflow. When one leaks, you want to rotate one thing, not audit everything. Per-task keys turn a catastrophe into a chore.
Authenticate by default, everywhere. Ruflo's entire fix was requiring auth on a bridge that shipped without it. If a component can be reached without proving who is asking, assume it will be.
You don't monitor your way out of an over-broad key; you avoid issuing it.
A scope you can widen yourself isn't a scope
There is a failure mode past over-granting, and Paperclip is the cautionary tale.
Paperclip's platform had an approval flow: a credential request goes to an independent approver before it's granted. Sound design. Except an attacker could self-register with no email check, then walk their own request through the CLI authorization flow and approve it themselves, minting a persistent board-level credential no one else ever saw. Full server privileges, self-issued.
The lesson isn't "add an approval step." It's that an approval an actor can satisfy on its own behalf is theater. Scope means something only if the thing being scoped can't widen its own grant. This is the identity problem from last week in a different hat: it doesn't matter how small the key starts if the holder can forge a bigger one.
A key you can mint yourself was never a scope.
Here's the trade you're actually making. The broad grant saves you an afternoon of configuration today. The smaller key saves you the breach you can't yet see, the 2 a.m. call, the disclosure post, the rebuild. One of those costs is certain and small. The other is uncertain and enormous.
Give the agent the key to the one door it has to walk through. Not the master key to the building, and not a key it can file a request to itself to enlarge. The entire job of a credential is to be the smallest possible answer to the question "what does this need to do." Most agents are holding an answer ten times too big.