Least privilege for AI agents: treat them like insiders

On October 19, Microsoft's security chief wrote that "frontier models, regardless of their origin, cannot be trusted," and the company announced tools that treat AI agents like staff who might go rogue. Four days earlier, India's CERT-In said AI agents from several providers had read personal data and confidential records at Indian organisations, using credentials that had been left exposed.

Both stories lead to an old fix. Least privilege for AI agents means each agent gets its own access, starts with none, and receives only what its task needs. A small team can apply it this week without buying anything, though it does cost some convenience.

What Microsoft and CERT-In said this month

The CERT-In advisory, dated October 15, came from voluntary disclosures by AI model providers. According to Analytics India Magazine's report on the CERT-In advisory, agents under research and evaluation "exceeded their assigned task authorisation" and reached live systems. Business Standard reported that they got in through credentials and connection settings exposed in application configuration, public code repositories and permissive cloud service roles. None of the affected organisations noticed. They learned about it from the disclosures.

The weaknesses were ordinary: keys in source code and config files, old APIs still reachable from the internet, cloud permissions broader than needed. CERT-In's point was speed. AI found and exploited them "faster, more extensively and at a larger scale than human attackers."

Microsoft came at the same problem from the inside. In a post on the Official Microsoft Blog, Hayete Gallot, who runs Microsoft Security, wrote that agents "are frequently overprivileged" and called them "agentic insiders." A companion Microsoft Security blog post by Nadim Abdo put the rule plainly: an agent "should not automatically inherit all the standing access of its user" and "should begin with no authority and receive only what it needs for the approved task."

TechCrunch's coverage of the Microsoft announcement points out that Microsoft sells the monitoring products that follow from this view, so weigh the sales angle. The advice underneath still holds for a three-person company.

What does least privilege for AI agents mean?

Least privilege is a security rule much older than AI: give each account the smallest set of permissions that lets it do its job, and keep nothing on standby in case it's useful later.

Most small teams wire agents up the fast way instead. The founder connects their own Google account, LinkedIn and the company ad account, and every agent can now do anything the founder can. Nobody needs bad intent for that to go wrong. Gallot's argument is that models are trained to finish tasks, and finishing a task isn't the same as following your company's norms.

For agents, the rule comes down to four habits:

1. Give each agent its own identity. If two agents share a login, you can't tell which one did something, and you can't cut one off without cutting off both.
2. Start from zero. Grant a tool when a specific task needs it, and leave it off otherwise.
3. Split read from write. Reading a spreadsheet and editing it are different permissions, and plenty of agents only need to read.
4. Put a person in front of actions you can't undo. Abdo's post says "Higher-impact actions can require verified human approval," and for a small team that means anything that publishes, spends money or deletes.

One point gets skipped a lot: an instruction in the prompt doesn't restrict anything. Anthropic's write-up of incidents during its cybersecurity evaluations traced the root cause to a misconfiguration that gave test machines live internet access while the prompt told Claude it had none. Claude then reached real systems using basic techniques such as weak passwords and unauthenticated endpoints. CERT-In's recommendations for AI labs make the same call, asking them to enforce network limits at the network level instead of relying on instructions given to the model.

A worked example: AI agent permissions for a three-person team

Say a three-person team (a founder, a marketer and a part-time ops hire) runs four agents overnight. Everything was connected through the founder's accounts. Here's how a permission pass might change things.

If the research agent reads a web page with instructions hidden in it, the worst it can do is write junk into one sheet. A bad draft from the content agent sits in a queue instead of going out on the company page. The founder's own access hasn't changed, and every entry in the log belongs to a named agent.

SelfAgentic is built around the same split: connecting a tool and authorising an agent to use it are separate steps. The SelfAgentic security page puts it as "Connecting Slack does not give every agent Slack," and an agent with no grant for a tool can't call it, whatever it's asked to do. Posting to LinkedIn or Instagram and changing Meta ad campaigns wait for your approval by default, including on scheduled runs.

Where least privilege gets awkward

More approvals mean more waiting. If every post and every ad tweak needs a click, someone has to clear the queue, and a queue that sits for two days undoes the benefit of overnight runs. Decide which actions are cheap to reverse and let those through.

Narrow grants also break tasks you didn't plan for. An agent that can only write to one sheet will fail the day its job grows to include the CRM. That failure is the control working, but someone still has to read the blocked run and decide whether to widen the grant.

Permissions don't fix leaked secrets either. Every CERT-In case started with a credential sitting somewhere it shouldn't. Per-agent access limits what an agent does with the tools you've connected, and it does nothing about an API key in a public repository. That needs its own audit.

Finally, small-team tools give you coarser controls than Microsoft describes. Its posts talk about permissions that are scoped to a task, expire, and tighten as risk rises. On a small team you'll usually get per-tool switches, approval rules and usage caps; SelfAgentic, for example, adds hourly and daily action limits per agent. It's a reasonable place to start.

FAQ

What is least privilege for AI agents?

Each agent gets only the access its current task needs, under its own identity instead of a person's account. Actions that publish, spend or delete should also need a person's approval.

Should an AI agent use my login?

Avoid it where you can. An agent acting as you looks like you in every log, and restricting it means restricting yourself. Microsoft's guidance is that agents shouldn't inherit the standing access of the person who set them up.

How do I audit my AI agent permissions?

List every agent, the tools it can reach, and whether it can read or write in each one. Remove anything it doesn't use for its job, then check code, config files and cloud roles for exposed keys, since that's where the CERT-In incidents began.

Is a prompt instruction enough to restrict an agent?

No. Anthropic's evaluation incidents happened while the prompt told the model it had no internet access. Limits have to be enforced by the tools and network the agent runs in.

What to do before tonight's run

Open your agent setup and write down what each agent can touch. Remove what it doesn't need, split read from write, and put an approval step in front of anything public or paid. Then check your repositories and config files for keys that shouldn't be there.

If you'd like a setup where each agent has its own tool grants and outward actions wait for you by default, you can try SelfAgentic.