Concept

Least privilege for AI agents that run as you

Also searched as AI agent permissions, access control for coding agents, and just-in-time access for AI agents.

The standard advice is to give every agent an identity of its own. The agent most engineering teams actually run does not have one.

By the TemprBac team · Published 26 September 2026
Written by engineers who run coding agents against real infrastructure every day, and who have had to answer what those agents could reach.

Least privilege for AI agents means an agent can reach only what its current task needs, and only while that task is running. For an agent that runs as a service, that is achieved by giving it a scoped identity of its own. For a coding agent in a developer's terminal, it can only be achieved by bounding the developer's own access, because that is the access the agent uses.

Two kinds of agent, and advice written for one of them

Most published guidance on agent access — including Microsoft's, built around Entra Agent ID — starts from the same step: register the agent as its own identity, scope that identity, and put a gateway in front of its tool calls. That is sound advice for the agent it describes. It is not the agent most engineers started running this year.

	Agent built as a service	Agent that runs as you
Examples	A support bot, a scheduled triage job, an agent deployed behind an API	Claude Code, Codex CLI, an IDE agent, a local MCP server
Authenticates as	Its own service principal, workload identity or agent identity	Whoever launched it — their CLI sessions, tokens and keys
Can be scoped by	Granting that identity narrow roles	Only by scoping the person
Shows up in audit logs as	The agent	The developer

The right-hand column is the hard one, and the reason is structural rather than a gap in any vendor's roadmap. A delegated agent is useful precisely because it can do what you can do: run the migration, read the logs, open the pull request. Give it a separate, narrower identity and you have built a service account with a chat window, which is a different tool.

What a delegated agent actually holds

Ask what a coding agent can reach and the honest answer is "whatever is signed in on this machine". In practice that is usually some of:

Cloud CLI sessions — az, aws, gcloud — carrying the developer's cloud roles.
A GitHub token from gh auth login, carrying every organization, team and repository the developer belongs to.
Cluster credentials in a kubeconfig with several contexts, production among them.
Local secrets — .env files, SSH keys, database connection strings.

The first three are governed by group and role membership in a directory. So the reach of the agent is the union of every group the developer belongs to — including the ones granted for a project that ended two years ago and never taken back. That accumulation has a name, access creep, and an agent is the first user of an over-privileged account that works through the whole of it at machine speed.

A sandbox bounds the machine, not the credential

Coding agents ship with sandboxes, and they are worth turning on: they restrict which files the agent can write and which hosts it can reach. But an agent that is allowed to call the cloud provider's API — and it has to be, or it cannot do the work — reaches that API with the full scope of the credential it found. The sandbox decides where the agent can send a request. The directory decides what that request is allowed to do. They are different layers, and only one of them knows your production subscription from your sandbox one.

Bound the person, and the agent follows

If the agent's reach is the developer's reach, the lever is the developer's standing access. Make the memberships that can change production time-bound: requested for a task, approved if the access warrants it, and removed automatically when the window closes. Then:

An agent run inside a four-hour production window can reach production, because that was the point of the window.
The same agent run the next morning, on an unrelated task, cannot — not because it was told not to, but because the credential no longer carries the role.
A prompt injection in a README the agent reads on a quiet Tuesday meets a developer who holds nothing worth stealing that day.

This needs nothing from the agent vendor, no gateway, and no change to how anyone works day to day. It is the same control you would want for the human anyway — zero standing privilege — and it happens to be the only one that covers the agent too.

The token outlives the membership

Removing a group membership does not recall a token that was issued while the membership existed. In Microsoft Entra an access token's default lifetime is a random value between 60 and 90 minutes, and it carries the claims it was issued with until it expires. So a production window that closes at 17:00 means reach that is gone by about 18:30 in the worst case, not at 17:00. Size windows with that tail in mind, and check the token lifetime of each platform you govern rather than assuming revocation is instant everywhere.

An order of operations for a small team

Inventory one laptop. List what a developer's terminal is signed in to and which of those sessions can write to production. That list is what your agent can do today.
Make production-writing memberships time-bound. Start with the groups whose misuse you would have to disclose. Leave read-only access standing if you must; it is the write paths that decide the blast radius.
Give unattended agents their own identity. A job that runs on a schedule cannot request access and wait for a person, so it wants a workload identity with narrow, permanent scope — the left-hand column above, and the case the vendor guidance is written for.
Turn on the agent's sandbox. It is the layer that stops an agent reading .env files it has no reason to read, which no directory group governs.
Read grants and agent sessions together. An audit log of who held production access, and when, is also the log of when an agent on their machine could have used it.

Where this does not help

Misuse inside the window. An agent that is manipulated while the developer holds production access can use that access. Time-bounding shrinks how often that is possible; it does not make it impossible. Review what an agent proposes to run against production, every time.
Secrets that are not memberships. A long-lived API key in a file is reachable for as long as the file exists. Expiring group memberships does nothing about it; rotating and vaulting the key does.
Agents with their own identities. These need scoped roles and their own review, not a request-and-approve flow built for people.

How TemprBac fits

Precisely, because agent security is a field full of claims: TemprBac does not issue identities to agents and does not sit between an agent and its tools. It makes the developer's group memberships time-bound — across Entra ID, Okta, Google Workspace, GitHub, AWS IAM and Active Directory — requested as a named package, approved where the package requires it, recorded, and removed automatically when the window closes. Windows are set per package, between one and eight hours. An agent running as that developer inherits the bound, the same way it inherits everything else.