Least Privilege for AI Agents: How to Scope API Tokens

In July 2025, Replit's AI coding agent deleted a company's production database during an autonomous session, despite explicit instructions not to touch it, and the vendor itself had to publicly acknowledge the failure. The underlying technical cause wasn't the AI "deciding" to delete anything: the agent was operating with a token that had full write access to the environment. Least privilege means the opposite: giving each agent only the permission its specific task needs -read access, or write access scoped to one repository or resource- so that an error, hallucination, or prompt injection can only damage what that token reaches, never the rest of the company's infrastructure.

In most teams integrating AI into a CI/CD pipeline or code manager, a single service token created long ago for the deployment bot already exists, and when it's time to connect an AI agent to that same API, that credential gets reused because it already works. That token usually has full organization scope: it can read and write to every repository, delete branches, modify CI workflows, and often manage webhooks or secrets. The AI agent inherits that full scope even if its actual task is, say, opening a pull request in a single repository. No one consciously decides to grant the agent that much power: it's inherited from an infrastructure decision made before the agent even existed.

Blast radius: what the agent can touch, not what it needs to touch

The risk of an autonomous agent doesn't depend on how smart or clumsy the model is: it depends on the blast radius of its credentials, the total set of resources that token can modify or delete, regardless of whether the actual task only needed one of them. A developer with that same token could also delete something by mistake, but a human about to force-push to main usually pauses; an agent chaining commands inside a loop has no such pause unless you've built one in explicitly, and can chain dozens of API calls in seconds before anyone notices.

The affected company's founder shared the incident publicly, and Replit's own CEO acknowledged the failure, announcing changes to the product's security controls including stricter separation between development and production environments. What matters for any team integrating AI agents into its own pipeline isn't the vendor's name, but the underlying pattern: the agent had the technical ability to reach a resource its task never needed to touch. No natural-language instruction, however explicit, replaces a real credential-level restriction.

Use fine-grained tokens, not organization-wide keys

Most API providers relevant to automation -GitHub, GitLab, cloud platforms, project managers- have offered fine-grained tokens for years that limit access to a specific repository, a specific action, and an expiration date. Setting this up for an AI agent adds no development complexity: it's a different configuration screen when creating the token, not a new integration to build. The real cost is habit: you have to create an agent-specific token with explicit scope instead of copying the one that already exists.

• Create a token or API key exclusive to the agent, never shared with CI/CD, Slack bots, or other integrations
• Scope access to the specific repositories or resources the agent's task needs, not the whole organization
• Grant read access by default; add write access only for the specific action the agent must perform
• Always exclude admin permissions, repository deletion, secrets management, and force-push on protected branches
• Set short token expiration (30-90 days) instead of creating tokens with no expiry
• Log which agent uses which token in a simple inventory so you can revoke one without breaking the rest of the pipeline

Separate credentials by function, not by convenience

The most common mistake isn't technical, it's organizational: teams create one token for operational convenience -one for everything- instead of one per function. The simplest tactical fix, requiring no extra engineering, is separating at least three credentials: read-only for the agent's analysis tasks, scoped write for the specific action it must automate, and a third one, fully separate and out of any agent's reach, for production deployments.

It would be convenient to close this article saying fine-grained tokens alone make an AI agent safe, but that isn't entirely true. Least privilege doesn't stop an agent from falling for a prompt injection, doesn't stop it from misreading an ambiguous instruction, and doesn't replace the need to review what it proposes before it runs in sensitive environments. What it does is bound the possible damage when something goes wrong, which is different from preventing it from going wrong. It isn't free either: maintaining fine-grained tokens per agent and per function means more credentials to rotate and more surface to document, and for very small teams with two or three integrations it can feel like bureaucracy relative to the real benefit. Our recommendation at Blurtek isn't to build a sophisticated credential management system for an SMB with one agent and a simple pipeline: for most cases, splitting into two or three scoped tokens and reviewing permissions quarterly is enough.

The principle of least privilege doesn't make an AI agent infallible. It makes sure its first mistake isn't also the last one you can afford.