Treat Every Agent Like a Privileged Service Account: A Least-Privilege Blueprint for AI Employees

Last week a security researcher showed that a fake bug report, slipped into a Sentry error feed, could get a coding agent to run attacker-controlled code using the developer's own credentials. Every step was authorized. Nothing in the stack had reason to flag it. The agent read a message it trusted, and it acted with the access it had been given.

That is the whole problem in one sentence. The access it had been given. Most teams hand an agent a broad token and a long list of tools, then act surprised when a prompt injection turns that generosity into an incident. The fix is not a smarter model. It is the oldest idea in security, applied to a new kind of user.

An agent is a privileged non-human identity

Here is the mental model that changes everything. Your agent is not a feature of your app. It is an identity, and specifically a privileged one, because it can read data, call APIs, and take actions on someone's behalf. We have decades of practice governing identities like that. They are called service accounts, and no serious ops team lets one roam with god-mode credentials.

The trouble is that agents got deployed by app teams, not identity teams, so they skipped the usual scrutiny. A human employee gets onboarded with a scoped role, an access review, and an offboarding plan. An agent got a .env file with an API key that never expires. Treat the agent like the service account it actually is, and the blueprint writes itself.

Give each agent its own identity

Start by refusing to share. One agent, one identity. Do not let three different automations authenticate as the same generic bot user, because the moment something goes wrong you cannot tell which one did it, and you cannot revoke one without breaking the other two.

A dedicated identity per agent buys you two things that matter more than they sound. Attribution, so every action in your logs traces to exactly one actor. And blast radius control, so when you kill one identity you contain one agent, not your whole automation layer. If you run a team of AI employees, this is the difference between "we disabled the sales agent" and "we took the whole workforce offline to be safe."

Scope the tools to the job, not the maximum

The second move is the tool allowlist. An agent should be able to reach only the specific tools and endpoints its task requires, and nothing else. A support agent that answers tickets does not need write access to your billing system. A research agent that summarizes documents does not need the ability to send email.

This sounds obvious until you look at how most agents are wired, which is "here is everything, figure out what you need." That default is backwards. The right default is deny, and you add capabilities one at a time as the job demands them. Every tool you do not grant is an entire class of incident that cannot happen. The agentjacking attack worked because the agent could execute shell commands it never needed for the task in front of it.

Make credentials expire with the task

The third move is the one people skip, and it is the most important. Time-bound the credentials. An agent's access should be scoped to the task and expire when the task is done, not persist as a static key sitting in a file for eighteen months.

Static secrets are the thing attackers actually steal. A short-lived, task-scoped credential is worth almost nothing an hour after it was issued. If you can issue credentials that live for the length of a job and then die, a leaked token becomes a small problem instead of a standing invitation. Pair that with real revocation, a single control that instantly cuts an agent off, and you can respond to a suspected compromise in seconds rather than hunting through config to find which key to rotate.

Watch behavior, not just permissions

Permissions decide what an agent can do. They do not tell you what it is doing right now. The last layer is runtime observation. Log every action an agent takes against its own identity, and watch for the pattern break: the support agent that suddenly queries the customer database at 3 a.m., the research agent that starts making outbound network calls.

You do not need a fancy platform to start. You need the actions attributed to individual agents, in one place, where a human or a rule can notice when normal turns into strange. The teams that avoid the first wave of agentic incidents are not the ones with the cleverest agents. They are the ones who can see what their agents did and stop them fast.

The checklist

If you take one thing from this, make it these five, in order:

1. One identity per agent. No shared bot accounts.
2. Deny by default. Allowlist only the tools the task needs.
3. Time-bound credentials that expire with the task.
4. A revocation switch that works in seconds.
5. Per-agent action logs with someone, or something, watching them.

None of this is exotic. It is the service-account playbook your ops team already knows, pointed at a new kind of worker. The reason it feels new is that agents arrived fast and got wired for convenience instead of containment.

This is also why we built Geta.Team the way we did. Every AI employee is self-hosted on your own infrastructure, runs with permissions you control, and connects to your tools through scoped access rather than a blanket key. The agent is powerful because you decided exactly what it can touch, which is the only kind of powerful that is safe to run in production.

Want to test the most advanced AI employees, with access controls you actually own? Try it here: https://Geta.Team