Least Privilege for API Access

The principle

Least privilege holds that every component in a system should have only the permissions it actually needs to do its job, and only for as long as it genuinely needs them. It is a foundational idea in security precisely because it does not assume everything will go right. Instead, it assumes that credentials will sometimes leak and components will sometimes be compromised, and it works to limit the consequences when that inevitably happens.

For integrations with the Merion API, applying least privilege means that every token and every credential should be made as narrow as the task in front of it allows, never broader "just in case" some future need might arise. Breadth granted speculatively is breadth an attacker can exploit if the credential is ever exposed. The discipline of asking "what does this specific thing actually need?" for each token is the practical heart of the principle.

Least privilege in scopes

The most direct and common application of least privilege is in scope selection when requesting tokens. A job that only ever reads data should request read-only scopes and nothing further; a job that never deletes anything should never be granted a delete permission in the first place. Narrow scopes mean that even a leaked token can do correspondingly little harm, because a token is incapable of any action its scopes do not cover.

There is a persistent temptation to request broad scopes up front simply to avoid having to make a change later, but this trades real, lasting security for a small and one-off saving in effort. It is always safer to start narrow and add a specific scope when a genuine need for it actually materialises. We explore the scope mechanism itself in more detail in OAuth Scopes Explained.

Least privilege in credentials

The same principle extends naturally beyond scopes to credentials and service accounts. The healthy pattern is to issue a separate credential for each distinct integration, so that each one can be scoped, monitored, and revoked entirely independently of the others. The alternative — a single, all-powerful credential shared across many systems — turns any one compromise into a problem for everything at once.

Equally important is retiring credentials promptly when they are no longer needed, rather than letting them linger indefinitely. Dormant, over-privileged credentials that nobody is watching are a perennial favourite target for attackers, precisely because their misuse is unlikely to be noticed quickly. This particular failure mode, along with related ones, is discussed further in Common Auth Mistakes, which is worth reading alongside this guide.

Limiting blast radius

The payoff for all this discipline is a dramatically smaller blast radius whenever something does go wrong. If a narrowly scoped token leaks, the attacker who obtains it gains only that token's limited permissions, not the keys to the entire kingdom. Combined with the short token lifetimes discussed elsewhere in these guides, the exposure from any single leak is bounded tightly in both its reach and its duration.

It is worth stressing that least privilege is not a single setting you switch on once and forget. It is a habit applied consistently at every layer of a system — across scopes, credentials, token lifetimes, and periodic access reviews — and the layers reinforce one another. No individual measure is sufficient alone, but together they ensure that when an inevitable incident occurs, its damage stays small, local, and recoverable rather than spreading unchecked.