# Principle of least privilege

Canonical page: /glossary/least-privilege

API keys & secrets glossary, Mistakes & leaks. Principle of Least Privilege: The One Habit Worth Keeping

**Short answer:** The principle of least privilege means giving any credential, whether a key, a token, or an account, only the specific access it needs to do its job, and nothing beyond that. It is one of the oldest ideas in security, and one of the most consistently useful.

## Why it matters

In practice, this means preferring a scoped key over a full-access one, a read-only token over a read-write one, and a project-specific credential over an account-wide one, every time the option exists.

## In Claude Keychain

Claude Keychain does not enforce scope itself, that happens with the provider issuing the key, but by making it effortless to store several narrow keys, it removes the main excuse for using one broad key everywhere out of convenience.

## Common questions

**Is least privilege only relevant for large teams?**

No, it applies just as much to a solo developer with a handful of API keys, since a leak's impact depends on scope, not team size.

**What is the cost of following least privilege?**

Mostly a little extra setup, creating a scoped key instead of reusing an existing broad one, which is a small trade for limiting what a leak can do.

## Related

[API key scope](/glossary/api-key-scope), [Credential stuffing](/glossary/credential-stuffing), [API key rotation](/glossary/api-key-rotation)