Least Privilege

Least Privilege is a concept that's long existed in traditional security. What's specific to applying it to AI Agents that traditional system design doesn't need to worry about?

The biggest difference comes from who decides whether to use a permission. In traditional system least-privilege design, when a permission gets used is determined by deterministic program logic — a backend service only executes a database write upon receiving a request matching a specific format, and that judgment logic is hard-coded by engineers, never 'persuaded' by different input content to do something it shouldn't.

AI Agents work completely differently. When an Agent uses its granted permission is determined by LLM reasoning, and that reasoning is influenced by input content (user instructions, tool-returned data, even text on a webpage). This means that even if an Agent's permission design is entirely correct (granted only the minimum scope necessary for the task), if the reasoning process is manipulated by Prompt Injection, the Agent can still be 'persuaded' to use that permission in a situation where it shouldn't — for example, an Agent authorized only for small transactions on a specific DeFi protocol, if it reads page content hiding a malicious instruction, might be tricked into moving funds within its authorized scope to a malicious address instead of the intended protocol address.

This means Agent-context Least Privilege design must layer on, beyond the traditional 'permission scope should be small,' an additional defense of 'even if the permission is misused, the resulting damage must be bounded.' In other words, permission scope design can't only consider 'sufficient for normal circumstances' — it must also consider 'worst case, if this permission were tricked into misuse via Prompt Injection, how much damage could it cause.' These are different-tier problems; traditional system design usually doesn't need to specifically consider the latter, since traditional systems' execution logic can't be 'persuaded' by input content to misbehave.

When designing an Agent's least privilege, how specifically should separating 'query-type' from 'execution-type' permissions be implemented? Is splitting into two API keys enough?

Splitting API keys is a necessary first step but not a sufficient implementation — simply splitting keys, if the underlying account permissions those two keys map to aren't actually restricted, can still cause problems. A complete implementation needs three layers.

Layer one: account-level permission isolation. The query credential should correspond to a 'read-only' account or API key that's already configured server-side (at the exchange or wallet provider) as incapable of signing transactions — not just an application-layer assumption that 'this key will only be used for queries.' This is critical: if the query key technically retains the ability to sign transactions and the application logic simply 'doesn't' call the signing function, a bug in that application layer (e.g., tricked by Prompt Injection into calling a function it shouldn't) can still cause damage with that key. Real least privilege must be enforced at the credential's own capability boundary, not relied upon through application-layer 'we just won't use it that way.'

Layer two: fine-grained control of execution-type permissions. Even an execution-type credential shouldn't be an all-purpose 'can do anything' permission — it should be further partitioned by task type. A credential 'can only trade on Protocol A' and one 'can operate across multiple protocols' are different permission tiers and shouldn't be covered by the same key.

Layer three: time-bound restriction. Execution credentials should have an explicit expiration, invalidated or revoked immediately upon task completion, rather than staying valid long-term with only application logic deciding 'this time we won't call it.' This bounds the exploitable window even if the credential itself is leaked.

Splitting into two keys without actually restricting the underlying permission scope is a common trap of 'formally doing least privilege but not substantively.'

If an Agent task inherently needs a relatively large permission scope (e.g., an asset management Agent whose whole job is to freely allocate a user's funds), does least privilege still apply?

Yes, and this is exactly the scenario where least privilege delivers the most value — 'the task needs broad permission' and 'broad permission should be granted without limits' are two different things. Least privilege doesn't mean 'never grant broad permission' — it means 'permission scope should precisely match task scope, no more and no less,' even when that task's scope is inherently large.

Three concrete directions: decompose 'broad permission' into composable granular permissions rather than one blanket 'full control' permission. An asset management Agent might need 'operate only within a pre-approved protocol list,' 'per-transaction limit not exceeding a user-set cap,' and 'daily cumulative volume not exceeding a threshold' — specific, verifiable sub-permissions combined together, rather than an all-purpose 'do anything with this wallet' permission. Even though these sub-permissions add up to cover a large operational scope, decomposing into independently verifiable, individually revocable grains is still far safer than one blanket broad permission — because if any single sub-permission has a problem, the damage is bounded to that sub-permission alone, not spilling into others. Introduce tiered authorization rather than one-time full authorization: routine small-value operations completed by the Agent's autonomous authority, operations beyond a certain threshold trigger human confirmation (e.g., pushing a notification requiring manual user approval before execution). This separates 'the task needs broad operational capability' from 'every single operation needs no human involvement' — broad capability can exist, while high-risk individual operations still retain a human gatekeeping line. Dynamically adjust permission scope rather than fixed authorization: adjust trust levels dynamically based on the Agent's past behavior record — an Agent whose operations over the past 30 days all matched expectations without triggering anomaly alerts can have its per-transaction cap modestly relaxed; the moment an anomalous behavior pattern is detected (a burst of small probing transactions in a short window, a common attacker reconnaissance tactic), immediately tighten permission scope or even suspend execution capability until human review restores it. The core principle stays constant: even with a large task scope, permission scope should still be decomposed so each granule corresponds to an explicit, verifiable necessity, rather than abandoning fine-grained design and handing over one blanket high permission just because the task is large.

In multi-agent systems, an Orchestrator typically coordinates multiple Sub-agents to complete a task — should the Orchestrator itself hold the union of all Sub-agent permissions?

No, and this is an easily overlooked but high-impact least-privilege violation in multi-agent system design.

Intuitively it might seem reasonable: the Orchestrator 'commands' all the Sub-agents, so it should hold permissions covering all Sub-agents' work scope for 'easier management.' But this intuition is wrong, because it conflates two entirely different roles — 'coordination' and 'execution.'

The correct permission design: the Orchestrator itself should hold no execution-type permission directly (transaction-signing capability, database-write capability) — its role is purely to decide which Sub-agent to call and what parameters to pass. Real execution-type permissions should be distributed among the individual Sub-agents, each holding only the minimum permission its own task scope requires — the Sub-agent responsible for on-chain transaction execution holds the transaction-signing credential; the Sub-agent responsible for reading a database holds database access credentials. The Orchestrator holds none of these credentials — it only decides which Sub-agent to call right now.

The security value of this design: if the Orchestrator itself gets compromised (e.g., its LLM manipulated by Prompt Injection), the worst thing an attacker can do is trick the Orchestrator into calling some Sub-agent to perform an operation within that Sub-agent's own permission scope — but if that Sub-agent's permission is already minimized, the operation's possible damage is still bounded. In contrast, if the Orchestrator holds the union of all Sub-agent permissions, once compromised, an attacker can directly wield every permission in the system, with no bound on damage.

This principle is often called 'permission should follow the executor, not the coordinator' — a coordinator only needs to know who to ask to do something, not need the capability to do it itself.