AI Agent Least Privilege: Credentials, Scopes, Audit Trails

AI agents are starting to do real work. They open pull requests, triage tickets, update records, and call internal APIs. Some teams now treat them like teammates, with tasks, tools, and access of their own.

That access is the problem to solve. Our post on the Hugging Face breach showed what happens when an agent holds credentials broader than its task, and it listed the questions worth asking. This post is the next step. It is a build guide for giving each agent only what it needs, and keeping a record of what it did.

If you have read our note on shadow AI, that one is about people pasting data into AI tools. This one is about agents that act on their own, with keys.

Treat each agent as its own identity

An agent should never borrow a person's account. It should have its own identity in your login system or cloud account, with its own name, owner, and purpose.

• One identity per agent, per job. A coding agent and a support agent should not share an account. If one goes wrong, you want to cut off only that one.
• A named human owner. Someone on the team is accountable for each agent. That person approves its access and answers for its actions.
• A written purpose. One or two lines on what the agent is for. This becomes the test for every permission it asks for.
• A clear label. Name agent accounts so anyone reading a log can tell at a glance that an agent acted, not a person.

This is the same idea as an access review, applied to a new kind of user. Agents belong on the list.

Give scoped tokens that expire

Least privilege means the agent can do its task and nothing else. In practice, that comes down to two things: scope and time.

Scope. Grant the smallest set of permissions the task needs. If the agent only reads tickets, it should not be able to close them. If it writes to one repo, it should not see the others. Start narrow and add access only when a real task fails without it.

Time. Prefer tokens that expire in minutes or hours over keys that last forever. Many cloud platforms and CI systems can issue temporary credentials on demand. When a token expires on its own, a leaked copy is worth much less.

A few practical rules:

• Keep secrets in a secrets manager, not in prompts, config files, or code.
• Never paste a key into the agent's instructions. Assume anything in its context could show up in its output.
• Split read access from write access, and grant write only where the task needs it.
• Keep agents out of production by default. Make production access a deliberate choice with its own review.

Keep agent credentials apart from human ones

It is tempting to let an agent run with a developer's personal token or browser session. It works on day one. It also means the agent can do anything that person can do, and the logs will say the person did it.

Keep the two apart:

• No shared tokens. An agent gets its own credentials, never a copy of a person's.
• No inherited sessions. Do not let an agent ride a logged-in browser that belongs to a staff member.
• Clear delegation. If an agent must act on behalf of a user, use a flow that records both: the user who asked and the agent that acted. Many identity platforms support this. If yours does not, write both names into your own logs.
• Separate limits. People and agents can have different rate limits, hours, and network rules. Agents can run thousands of actions in a short window, so their limits should reflect that.

Put approval gates on risky actions

Some actions are hard or impossible to undo. Those should wait for a person to say yes, even when the agent is confident.

Good candidates for a gate:

• Deploying to production or changing infrastructure.
• Deleting data or records.
• Sending email or messages to people outside the company.
• Moving money, issuing refunds, or changing billing.
• Creating new credentials or changing permissions.
• Calling an outside system for the first time.

A gate works best when it shows the person exactly what the agent wants to do, with the inputs, in plain words. A vague "approve agent action" prompt teaches people to click yes. Keep a record of each approval: who approved, when, and what they saw.

Log everything the agent does

When something goes wrong, the first question is what the agent did. You can only answer that if you logged it.

• Tag every action with the agent identity. Agent actions should never blend in with human ones.
• Tie actions to a task. Record which request or run started the work, so you can follow one job from start to end.
• Capture tool calls and results. Log which tools the agent called, with what inputs, and what came back. Mask secrets before anything is written to the log. Mask customer data where you can, and keep logs only as long as your retention rules allow.
• Send logs where the agent cannot edit them. A central log store with its own access rules keeps the record honest.
• Alert on unusual patterns. A burst of actions, a new system, or a denied permission are all worth a look.

These records also help in a vendor review. When a buyer asks how you control AI agents, you can show the owner, the scope, the gates, and the logs. That is a far better answer than a policy alone.

For the rest of that review, use our B2B Vendor Security Review Checklist.

Rotate, review, and offboard

Agents change faster than people do. A prompt gets edited, a new tool gets added, a pilot ends. Access should keep up.

• Rotate secrets on a schedule, and right away if one may have leaked.
• Review agent access on the same calendar as human access. Check scope against the written purpose. Remove anything the agent no longer uses.
• Watch for scope creep. Each new tool or connection is a new permission. Treat it like a change request, with an owner who says yes.
• Offboard agents like people. When an agent is retired, revoke its identity, its tokens, and its connections the same day. Archive its logs.
• Keep a kill switch. Know how to stop an agent and revoke its access in one step, and test that you can.

A short checklist to start

• Every agent has its own identity, owner, and written purpose.
• No agent uses a person's token, password, or browser session.
• Each agent has the narrowest scope that lets it do its job.
• Credentials expire on their own, and secrets live in a secrets manager.
• Risky actions wait for a person to approve them.
• Every agent action is logged with the agent's name and task.
• Logs are stored where the agent cannot change them.
• Agent access is reviewed with human access, and retired agents are offboarded.

None of this needs a new product. It needs the same identity, access, and logging habits you already apply to people, extended to a new kind of teammate.

If you are wiring agents into real systems and want a second set of eyes on their access, you can reach us here.