Least privilege for AI agents: give each one only the access its job needs

The safest way to run an AI agent is to assume it will one day do the wrong thing, then make sure the wrong thing is small. That is least privilege: each agent gets the narrowest access its job needs, for as long as it needs it, and nothing it could use to cause damage it was never asked to cause.

This matters more for agents than for ordinary software because agents act on text, and text can come from anyone. An agent with send rights on your mailbox can be talked into sending. An agent with delete rights on your drive can be talked into deleting. The Australian Signals Directorate's joint guidance, Careful adoption of agentic AI services, describes privilege risk as agents holding excessive access so that a single compromise has far-reaching consequences, and recommends strict adherence to least privilege. It's one of the three controls at the centre of our guide to sovereign AI for Australian operators.

The permission ladder: read, draft, act with approval, act alone

Most AI agent permissions questions get easier once you sort every capability onto one of four rungs. Start every new agent on the lowest rung that is useful and promote one capability at a time.

Our view: almost nothing customer-facing should ever reach rung 4. The time saved by skipping a ten-second approval is tiny compared with the cost of one wrong email to a client. Keep autonomy for internal housekeeping that is easy to undo. We cover the design of approval steps in approval gates for autonomous agents.

The OWASP Top 10 for LLM Applications makes the same point from the attacker's side. Its entry on excessive agency traces damaging actions to three causes: excessive functionality, excessive permissions and excessive autonomy. The ladder addresses all three: fewer tools, narrower scopes, more approvals.

Give agents their own scoped accounts, not your login

The quickest way to connect an assistant is to sign in as yourself and click 'allow'. It is also the worst. Your account can see every folder, every client, every admin setting. An agent connected under it inherits all of that, and its actions look like yours in every log.

What a scoped setup looks like

• A separate identity where the service allows it, for example a dedicated user or a service connection, so the agent's actions are distinguishable from yours.
• Narrow scopes on each integration. Read-only mail for a triage agent; access to one shared drive folder rather than the whole drive; one CRM pipeline rather than all of them.
• No administrator rights, ever. ASD lists restricting administrative privileges among its Essential Eight mitigations. An agent never needs to manage users or billing.
• Separate agents for separate jobs. An agent that reads inbound email from strangers should not also be the one with access to your trust account records.

That last point deserves emphasis. ASD's advisory on agentic AI harnesses recommends configuring sub-agents with only the tools, permissions and context needed for a specific task, which limits exposure to untrusted content. Splitting work this way is exactly what an orchestrator is for; how Fulcrum Sessions plans and splits work shows one approach, and the Sessions page has the overview.

Shared business accounts need fixing before an agent touches them

Plenty of small businesses run on shared logins: one admin@ mailbox, one supplier portal password on a sticky note, one social media account everyone uses. Connecting an AI agent to a shared account multiplies an existing problem. You can't tell who did what, you can't revoke one person, and if the password leaks everyone's access goes with it.

1. List every shared account the agent would need. Most businesses find more than they expected.
2. Turn on multi-factor authentication for each one. It's another Essential Eight mitigation and the single biggest improvement for shared logins.
3. Where the service supports delegated access (shared mailboxes, team drives, multiple users on one CRM), move people and agents onto their own identities with delegation rather than a shared password.
4. Where it doesn't, keep the password in a password manager, not in a document, chat or prompt.
5. Never paste a shared password into a chat with an agent. Connect through the service's integration or authorisation flow instead.

Keep secrets out of prompts and logs

A prompt is not a vault. Anything you type to an agent may be stored in conversation history, passed to a model provider and written to logs that other people can read. Passwords, API keys, bank logins, card numbers and tax file numbers should never appear in a prompt, a chat message or a document you ask an agent to read.

Logs deserve the same discipline. A good audit trail for AI agent actions records what happened without copying secrets into the record.

Treat every integration as an access decision

Each time you click 'connect', you grant a standing permission that outlives the task you connected it for. Keep a simple register so those decisions stay visible. A spreadsheet is enough.

The rows are illustrative. The discipline is real: if a connection isn't in the register, it shouldn't exist.

A 15-minute quarterly access review

• Open the register and each service's connected-apps page side by side. Remove anything connected that isn't on the register.
• For each integration, ask: did the agent use write access this quarter? If not, drop it to read.
• Check for people who have left. Revoke their access and any agent connections they authorised.
• Look at the audit trail for anything outside an agent's normal pattern: new recipients, unusual volumes, access to folders it doesn't usually touch.
• Update the review date.

Least privilege also limits the damage from prompt injection: an agent that can only read and draft can be tricked into writing a bad draft, but not into sending it. We explain that attack in prompt injection through email.

When least privilege gets in the way

It does sometimes. An agent restricted to one folder can't find the contract in the other folder; an agent without calendar access can't propose meeting times. The answer is to grant the extra access deliberately, write it in the register and review it, not to start with everything to avoid the friction. If a task genuinely needs broad access to sensitive systems, such as bank accounts or payroll, our advice is to keep it a human task with the agent preparing the work alongside.

Fulcrum Cortex is built around the same idea: agents draft emails and SMS, and the owner approves before anything goes out. The platform page shows how the pieces connect.