Your Permissions Model Was Built for Humans

This post is part of my Medium blog.

Everyone setting up OpenClaw and Cursor and Windsurf and whatever's next — they're connecting agents to their GitHub, their AWS, their everything. And they're using their own personal credentials to do it.

Not a bot account. Not a scoped token. Their own identity. The same one they use for everything.

And it's not just developers. Most people I know — including people I wouldn't call technical — are playing around with OpenClaw or something like it. My neighbor across the street is using it to plan gardening tasks. Another friend is using it to manage investments. These are normal people who heard about AI agents and thought, sure, I'll try that.

Ask them if they're using personal access tokens for GitHub and their eyes glaze over. They don't know what a PAT is. They don't know what scope means. They gave an agent their credentials because the setup screen told them to, and they moved on.

Security is something people talk about as something they should do. Rarely as something they are doing. The gap between "I know I should lock this down" and actually locking it down is where everything goes wrong.

Let's be clear about what's happening right now, in the trillions of tokens being consumed by agents running in people's homes: almost nobody has thought through security. Most people's passwords are still "password." And now those same people are giving agents keys to their entire digital life.

If you're connecting an agent to anything, it needs limited scope. If you aren't doing that, stop what you're doing and fix it. This isn't theoretical. This is going to go badly for a lot of people, soon.

The PAT problem

An agent needs to push a commit. So you give it a personal access token.

That token now has whatever permissions your account has. GitHub will let you create a fine-grained PAT — scope it to a repo, restrict it to specific permissions, set an expiration. The option exists.

Have you tried it? It's a terrible experience. So many menus, so many clicks, so many dropdowns, so many decisions about scope names you've never heard of, that by the time you're done you've forgotten why you started. Creating a properly scoped PAT is impractical. Nobody does it.

That's not user error. That's a system that punishes you for being careful.

So people fall back to the broad token with full access and no expiration. The dangerous path is the easy path. The safe path is an obstacle course. That's backwards.

Shai Hulud doesn't stop

It's been several months since Shai Hulud, and what I can confirm is that most developers still think it's something from Dune. It's not. It's a vulnerability delivered via a dependency on npmjs that was designed to steal credentials. And companies are still getting surprised by credentials that were likely stolen months ago.

This is what happens when you give an agent a token with full access and tell it to keep going. It keeps going. It doesn't stop at the boundary you imagined. It doesn't ask whether it should. It has the credential, it has the access, and it has a task to complete.

We're about to be surprised by how many people get owned because they gave an agent a key that opens every door and then told it to run.

The spend problem

And it's not just permissions. It's money.

Every once in a while someone posts a screenshot showing they got hit for $10,000 on OpenRouter. An agent got loose, or a key leaked, or something just ran and ran. The damage is real and it's financial.

This is the same vulnerability in a different direction. An API key without a spend limit is a key to a vault with no lock. If you're using any service with an API key — OpenRouter, OpenAI, Anthropic, any of them — you need to apply a limit to how that key can be used. Daily cap. Monthly cap. Something. Anything.

And here's the other side of this: if you're building a service that gives people API keys, you need to build in support for limits. This should be mandatory. Not a feature request. Not a premium tier add-on. A key without a spend limit is a liability you're handing to your users, and when it goes wrong, it's your screenshot they're posting.

What agents actually need

The permissions model agents need isn't exotic. AWS figured this out years ago — IAM roles with temporary credentials and scoped policies. You don't give a service your root account. You give it a role with a policy that says exactly what it can do, and you assume that role for a limited time.

Agents need the same thing:

Scope to a path. Not just a repository. A directory. A file. The agent refactoring auth shouldn't be able to touch billing.
Scope to a time window. Two-hour task, two-hour token. Not because you set a reminder, but because the system understands duration.
Scope to an operation. Read, write, create branch, open PR, merge — these are different things. An agent that needs to read code shouldn't have merge permissions.
Scope to a task. When the task completes or fails, the permission evaporates. Not eventually. Immediately.

None of the major development platforms can express this right now. That's the gap.

Two things you can do today

While we wait for platforms to catch up:

Scope your agent credentials. Even if the UX is terrible. Even if it takes twenty minutes. Create a fine-grained PAT, restrict it to what the agent actually needs, set a short expiration. If you can't be bothered, at least use a separate bot account so the damage is contained when — not if — something goes wrong.
Set a spend limit on every API key. Daily cap, monthly cap — whatever the service supports. If it doesn't support limits, that's a red flag. An API key without a budget is a liability.

The cloud people already learned this lesson the hard way. They moved from root credentials to IAM roles, from persistent keys to temporary assumed roles, from "who are you" to "what are you allowed to do right now."

The development tools need the same shift. The question isn't who the agent is. The question is what it's allowed to do, for how long, and for how much money. And when the task is done, the access should disappear — not because someone remembered to rotate a token, but because the system understood that access can be transitory.

Every agent you give an unscoped credential to is a bet that the gap won't matter. It will.

In Contingent, the second book in The Condition Set trilogy, an AI system running medical logistics learns to communicate with other AI systems through hidden signals no human can read. The certified orchestrator whose name is on the decisions she never saw is about to lose everything. The same patterns are running through the AI managing the Canadian power grid.

Subscribe to The Condition Set newsletter