How to apply least privilege to AI agents using MCP

Acutis Gate · guides for IT directors · updated October 2026

Short answer: least privilege for AI agents has three layers. Show the model only the tools this person may use, check every call against rules that deny anything not named, and run each allowed call with the person's own access so the app can still say no. The easiest way to write the first rules is to watch a few days of real use and turn what people actually did into rules.

Layer 1: the model only sees allowed tools

An MCP server hands the AI a list of tools. If the list includes "approve payment" for everyone, the model will eventually try it for someone it should not. Filter the list per person, so a tool they may not use is never in the model's context at all.

Layer 2: every call is checked, deny by default

Rules name who (a person, a group or a role), what (read, write, execute, or one tool) and where (an app or a path), with exceptions. Anything no rule names is refused, and an explicit deny always wins over an allow. For example: the HR partners group may read the HR system; nobody's AI touches the Legal share; Finance writes wait for an approver.

Layer 3: the app still decides

Rules can be tighter than the app's own permissions, never looser, because every allowed call still runs with the person's own login to the app. A rule written too broadly cannot grant what HR, finance or the file server would refuse that person.

Build the first rules from real use

Acutis Gate starts in learning mode: everything is allowed and everything is recorded, so day one works and you learn what people's AIs actually do.

1. Connect your AI apps and let people work for a few days.
2. Open Guardrails → Build rules from the trail. Gate drafts one rule per group and app: reads that happened become allow rules, and writes and executes become approval rules. Nothing is invented; a rule exists only because somebody did that thing.
3. Review and trim the draft, add any deny rules (sensitive shares, payroll), and mark the ones that must never change casually as locked (changing them needs an admin and an authenticator code).
4. Save with Dry run on to see what each rule would have done, then turn dry run off. From then on, anything the trail never saw is denied.

A draft rule, as Gate writes it:

{
  "id": "hr-partners-reads-hris",
  "who": ["group:HR-Partners"],
  "effect": "allow",
  "do": ["read"],
  "on": ["hris://tools/get_leave_balance", "hris://tools/search_people"]
}

Gate reads each tool's own hints to decide whether it reads or changes something. A tool with no hint is treated as a change, the cautious choice.

Command line

# fetch the drafted rules for review (admins)
curl -s "https://gate.corp.example/api/v1/gate/policy/suggest?days=14" \
  -H "Authorization: Bearer $GATE_TOKEN"

Frequently asked questions