NHI and Agentic Risk: Least Privilege Meets Least Agency
Over-scoped identities turn harmless tools into high-impact actions. The agent is rarely the root problem.
This is the second post in the series. Focus here: over-scoped identities turn harmless tools into high-impact actions.
The OWASP overlap is direct. NHI5 (overprivileged NHI) maps to ASI02 (tool misuse) and ASI03 (identity and privilege abuse). The agent is rarely the root problem — the permissions are.
How It Happens
A service account gets broad access “for now.” There’s no clear owner to remove it later. Tool integrations inherit scopes from the identity that first made them work, and those scopes become the default.
The failure modes are ordinary:
- “Read-only” tools aren’t actually read-only because a read call can trigger downstream mutations.
- Tool chaining quietly expands privileges by crossing systems with different trust models.
- Privilege inheritance between agents blurs boundaries — a restricted agent can still act through a more privileged one.
Example
A support agent has a “read-only” CRM tool for pulling order history. The backing service account can also issue refunds because it was provisioned quickly and never revisited. A prompt injection or misaligned plan doesn’t need a new exploit — it just calls the refund path that already exists. The incident looks like agent misuse, but it’s really over-privileged identity scope.
What to Do About It
Least privilege still works, but it has to be enforced at the tool level:
- Per-tool profiles that make scope visible and limit what an agent can do, even when a prompt tries to expand it.
- Explicit scope boundaries in tool definitions that make reviews possible.
- Audit trails showing which identity authorized which action.
Least privilege is the right answer. Least agency is how you keep it intact once agents enter the system.