Least Privilege for AI Agents: A Capability-Tag Authorization Model

The debt of “just get it running”

Agent adoption typically follows one path: hand it a working token, let it complete the workflow, validate the value, put it into use.

Nothing wrong with that path — validating value first is sound engineering judgment. The problem is step two: almost no team ever comes back to tighten the permissions. That organization-wide token issued for debugging convenience follows the agent all the way into production.

The consequences are not theoretical. An agent's behavior is decided dynamically by a model, not fixed in code. That means there is no deterministic mapping between “what it can do now” and “what it will do later.” When it holds privileges beyond what the task requires, you are effectively relying on the model's judgment as your security boundary — and the model's judgment is precisely what prompt injection attacks target.

Why conventional IAM falls short

Enterprises already have mature identity and access management. Applying it directly to agents runs into three mismatches:

Unstable subjects. IAM assumes the behavioral pattern of a subject (user, service) is relatively fixed. An agent's behavior varies by task, by context, by model version. Describing it with a static role is inherently imprecise.

Wrong granularity. IAM typically authorizes by resource and operation (“may read S3 bucket X”). An agent's risk unit is capability (“can read arbitrary local files”, “can make outbound network requests”) — the same capability may span multiple tools and resources, while a single tool may carry several capabilities at once.

Different authorization timing. Conventional authorization is a one-time decision at onboarding. In agent ecosystems, tools are added and removed continuously and MCP servers update silently. The permission surface keeps shifting, so what is needed is continuous evaluation rather than a single approval.

Capability tags: standardizing “what it can do”

The workable approach inserts a layer of abstraction between tools and permissions: capability tags.

Instead of asking “what is this MCP server called”, ask “once enabled, what capabilities does the agent gain” — and standardize the answer as a tag set. Typical capability domains include:

• Filesystem: read arbitrary paths / read specified directories / write / delete
• Process execution: shell commands / subprocess creation
• Network: outbound requests / port listening / internal network access
• Credentials: read environment variables / access secret stores / reuse existing sessions
• Data operations: read / modify / delete persistent data
• External communication: send email / publish content / initiate payments

The value of this vocabulary is that it is comparable and policy-ready. You can state that “any tool carrying the shell-execution tag requires human approval” without debating each tool individually. You can also re-tag after a tool updates and let tag changes trigger re-evaluation — if the declared capabilities changed, the risk surface changed.

Three authorization principles

1. Authorize by task, not by tool.

Define which capabilities the agent's task actually requires, then select tools and credentials accordingly. The order matters: doing it the other way around — pick the tool, then see what permissions it wants — almost inevitably leads to over-privileging, because tool authors tend to request broad permissions to cover more scenarios.

2. Watch capability combinations.

An individual capability may be harmless while the combination is not. “Read local files” plus “make outbound requests” equals data exfiltration capability. “Read environment variables” plus “execute shell” equals credential theft plus lateral movement. Authorization review has to consider how the capability set interacts, not tick items off one by one.

This is exactly how many real incidents originate: every tool looks reasonable on its own, and together they open a complete attack chain.

3. Gate irreversible actions separately.

Deletion, payment, external sending, production configuration changes — what these share is that mistakes cannot be undone. They should be separated from routine permissions and require explicit confirmation or independent approval, regardless of how trusted the agent is.

Implementation: three stages

At intake: run a capability audit on every tool or MCP server, produce a tag set, and compare declaration against implementation (a tool that claims to only read your calendar but has file-write capability in its code — that inconsistency is itself a risk signal). Produce block / need_review / pass verdicts from this.

At runtime: isolate credentials per agent and per task, minimize scope, keep them independently revocable. Use an egress allowlist as a backstop — even if a tool is poisoned, the data cannot leave.

Continuously: log actual tool invocations and compare against the authorized scope. Capabilities unused over a long period should be revoked — the most overlooked and lowest-cost tightening available. Trigger re-evaluation when tool versions change.

From “can we use it” to “what can it do”

The central question in agent security is shifting from “is this tool malicious” to “once enabled, what capabilities requiring approval does the agent gain.” The first is a malware detection problem; the second is a capability auditing problem — and enterprise admission decisions need the answer to the second.

This is the methodological basis of SkillSec: decomposing agent ecosystem components (Skills, MCP servers) by capability domain and supporting verdicts with graded evidence, so permission decisions rest on what something can do rather than whether it looks suspicious.

Least privilege is not a new concept. It has simply become harder and more important in agent scenarios — because this time, the authorized subject decides for itself what to do.

---

Further reading: Enterprise MCP server admission checklist · Attack paths in AI agent supply chain poisoning · SkillSec: agent capability auditing