All posts

Non-human identity: what it means for your blast radius

Steal a human's password and you get one tired person who notices when their laptop acts strange. Steal a non-human identity and you get a credential that runs 24 hours a day, holds broad standing access, and raises no alarm when it does something new. That asymmetry is why non-human identity changes the blast radius math. The blast radius of a non-human identity is the full set of systems its credential can reach, multiplied by the fact that nothing about its behavior looks unusual. Machines d

Free White Paper

Non-Human Identity Management + Blast Radius Reduction: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

Steal a human's password and you get one tired person who notices when their laptop acts strange. Steal a non-human identity and you get a credential that runs 24 hours a day, holds broad standing access, and raises no alarm when it does something new. That asymmetry is why non-human identity changes the blast radius math.

The blast radius of a non-human identity is the full set of systems its credential can reach, multiplied by the fact that nothing about its behavior looks unusual. Machines do strange things at 4am for a living.

Why machine credentials enlarge the blast radius

Three traits stack up:

  • Standing access. The token works now, in an hour, and next month. There is no session that ends, so a compromise persists until someone rotates the key.
  • Broad scope. Service accounts accumulate permissions because trimming them risks an outage nobody wants to own. Each extra grant is more blast radius.
  • Lateral reach. One compromised pipeline credential often unlocks several systems, so the blast radius is not one database, it is the path the credential walks.

The contrast that matters: a human breach is loud and bounded. A non-human identity breach is quiet and wide.

Two levers that actually shrink it

You reduce blast radius by reducing two things: how much a credential can reach, and how long it can reach it.

  1. Scope. A non-human identity should reach exactly the systems its job requires and nothing more. Default-deny, grant the specific connection.
  2. Time. Access that exists only during the window the workload runs cannot be used at 3am three weeks later. Just-in-time access turns a standing credential into a brief one.

There is a third lever that is easy to skip: visibility into reach. You cannot shrink a blast radius you have not measured. If you do not know which systems a service account can actually touch, every estimate of its blast radius is a guess, and guesses trend optimistic. A command-level record of what each non-human identity reached turns the blast radius from a worst-case assumption into a known quantity you can act on.

Continue reading? Get the full guide.

Non-Human Identity Management + Blast Radius Reduction: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Enforce scope and time on the connection

Both levers fail if they depend on the workload policing itself. The architectural requirement is to enforce scope and lifetime on the access path, outside the process holding the credential. That is what a gateway does.

hoop.dev is an open-source access gateway between identities and infrastructure. A non-human identity reaches a database or cluster through it, the grant is scoped to that connection and can be time-boxed, and every command is recorded. If the credential leaks, it does not carry standing access to everything; it carries a scoped, recorded, often expired path. The blast radius collapses from "everything the key could touch" to "the specific connection, during the window it was allowed." See how scoping and just-in-time grants are configured in the getting-started guide.

A concrete before and after

Before: a CI runner holds a long-lived database password with write access to every schema. Leak it and an attacker has persistent write to production. Blast radius: the whole database, indefinitely.

After: the runner authenticates through the gateway, gets read access to one schema for the length of its job, and every query is recorded under its principal. Leak the runner's own credential and the attacker still hits the gateway's scope and time limits, and leaves a trail. Blast radius: one schema, one window, fully logged. The identity-aware model behind this is described on the hoop.dev site.

FAQ

Does rotating keys solve this?

Rotation helps but does not bound the blast radius. A key valid between rotations still reaches everything in scope. Scoping and time-boxing the access path bound it; rotation just resets the clock.

What about secrets managers?

A secrets manager stores and rotates the credential. It does not constrain what the credential reaches once retrieved. Pair it with a gateway that scopes and records the connection.

How do I measure a non-human identity's current blast radius?

List the connections it can reach and the operations each allows, then compare that against what it actually used over a full cycle. The gap between permitted and used is recoverable blast radius you can remove without breaking the workload.

To see how a gateway shrinks the blast radius of every non-human identity, read the open-source code and architecture on GitHub.

Open source

Save the open-source gateway for agent data access

Hoop is MIT-licensed infrastructure for controlling how AI agents reach production data. Star hoophq/hoop so you can inspect it, deploy it, or share it when your team starts governing agent access.

Star and save the repo →More posts