Your AI Agent Shouldn’t Be You

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 those I wouldn’t call technical — are playing around with OpenClaw or something similar. 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 is it 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 tens of trillions of tokens being consumed by agents every single day running in people’s homes: almost nobody has thought through security. (BTW, most people’s passwords are still a variation of “password.”) And now those same people are giving agents keys to their entire digital life… your Gmail, maybe your brokerage account, your kid’s school logins.

If you’re connecting an agent to anything, it needs a 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

If you have recently been intoxicated by the siren song of agentic development… an agent needs to push a commit to GitHub. I’ll bet you a million dollars you gave it a personal access token that had admin rights to do anything. (Why not? It’s easy.)

That token now has the same permissions as your account. 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.

But have you tried it? Have you taken the time to think about what permissions this agent needs? 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, which has full access and no expiration.

The dangerous path is the easy path. The safe path is an obstacle course.

That’s the backward reality of software security, and more people take the easy path, check all the boxes, and grant everything access to everything.

Shai Hulud gathered credentials that still work…

It’s been several months since Shai Hulud, and what I can confirm is that most developers still think it’s something from Dune. And by that I mean most people are blissfully unaware that Shai Hulud refers to a vulnerability in 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 credentials, the access, and 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 vulnerability” problem

And it’s not just permissions. It’s money. If you are not careful, you’ll be on the hook for thousands (or tens of thousands) of dollars when someone compromises your agent.

Every once in a while, someone posts a screenshot showing they were hit with a $10,000 charge for using OpenRouter or another provider’s API. An agent got loose, or a key was leaked, or something just kept running and running. 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 — with IAM roles, 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 of an operation. Read, write, create a branch, open a PR, merge — these are different things. An agent that needs to read code shouldn’t have merge permissions.
• Scope of 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:

1. Scope your agent credentials. Even if the UX is terrible. Even if it takes twenty minutes. Create a fine-grained PAT on GitHub, restrict it to what the agent actually needs, and set a short expiration period. If you can’t be bothered, at least use a separate bot account (or organization) so the damage is contained when — not if — something goes wrong.
2. 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. When you set your daily limit, predict a dollar figure greater than what you expect to spend and less than what you’d regret if someone compromised your agent.

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.” You need to move to a model closer to Zero Trust for your agents.

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, and I promise this mistake will show up in a high-profile compromise any day now.

Author’s Note

Many of the issues in this post are explored in my novella Essential and, more directly, in its predecessor, Contingent. While Contingent is a work of fiction, one of its central themes is that our systems of governance, identity, permissions, and accountability were designed around human actors — not autonomous agents operating at machine speed and machine scale.

The security problems we’re beginning to see with AI agents today are a small example of that broader challenge. When an agent can act on our behalf, spend money, access information, and make decisions, the question is no longer simply “Who are you?” but “What are you allowed to do, for how long, and under what constraints?” That’s a question that sits at the heart of both modern security architecture and the regulatory challenges we’ll have to solve going forward.