Many assume that NIST only addresses human users, but the standard explicitly covers service accounts, CI‑CD bots, and any automated identity that accesses infrastructure.
Non‑human identities are the workhorses of modern pipelines. They run nightly builds, trigger deployments, scrape metrics, and push logs. Yet most organizations treat them like static passwords: a long‑lived API key checked into source control, a service account credential stored on a VM, or a hard‑coded token in a CI script.
The result is a sprawling attack surface where a compromised bot can move laterally, exfiltrate data, or issue privileged commands without a single audit record.
Because teams never rotate the credentials automatically and the access path bypasses any runtime guard, they cannot demonstrate to auditors that they enforce least‑privilege, real‑time approval, or data‑masking for these identities.
NIST requires organizations to provision, authorize, and monitor each service account as a full identity. The standard calls for:
- Granular, role‑based permissions that limit each automated identity to the exact resources it needs.
- Just‑in‑time (JIT) access that is granted only when a specific workflow requests it.
- Audit records that capture who (or what) performed each action, when, and what data was returned.
- Real‑time controls that can block or mask data that violates policy.
Meeting these requirements means moving from “credential‑in‑the‑code” to a model where every request is inspected, approved, and recorded at the moment it traverses the network.
Current practice and its gaps
In a typical environment, a CI runner authenticates directly to a database using a hard‑coded username and password. The runner issues SQL statements, and the database logs the session under the service account name. What is missing?
- There is no point‑in‑time approval before a destructive query runs.
- The database returns sensitive columns in clear text to the runner.
- You cannot correlate the database’s native audit log with the CI job that initiated the request.
- If someone leaks the credential, the attacker gains unrestricted access until you manually rotate the secret.
These gaps directly conflict with NIST controls such as AC‑2 (Account Management), AU‑6 (Audit Review, Analysis, and Reporting), and SC‑7 (Boundary Protection). Without a dedicated enforcement point, the organization cannot produce the evidence auditors expect.
Why a data‑path gateway is required
The first two pillars, setup and identity, are necessary but not sufficient. Provisioning a service account and assigning it a role tells the system *who* can act, but it does not guarantee *how* the action is performed. Enforcement must happen where the request actually flows, not in an external IAM database that the service itself can bypass.
Placing controls in the data path ensures that:
- Every command or query passes through a single, immutable inspection point.
- Policy decisions are made based on the live request, not on static ACLs alone.
- Audit data is captured centrally, independent of the target system’s native logs.
In short, without a gateway that sits between the non‑human identity and the target resource, the organization cannot satisfy the NIST evidence requirements.
How hoop.dev fulfills the NIST controls
hoop.dev runs as a network‑resident agent and forces every request from a non‑human identity through its gateway. Because hoop.dev serves as the sole enforcement point, it delivers the outcomes NIST demands.
- Just‑in‑time approval: When a CI job attempts a privileged operation, hoop.dev pauses the request and routes it to a human approver. hoop.dev records the approval and links it to the session.
- Inline data masking: hoop.dev strips or redacts regulated fields from responses before they reach the automated client, preventing accidental leakage.
- Command‑level audit: hoop.dev logs each statement, the identity that issued it, the time, and the outcome. hoop.dev stores the logs outside the target system, giving auditors a single source of truth.
- Session recording and replay: hoop.dev captures every interactive session, whether a kubectl exec or an SSH command, enabling post‑incident forensic analysis.
- Policy‑driven blocking: hoop.dev denies dangerous commands (e.g., DROP DATABASE) automatically based on policy rules.
The setup phase, creating OIDC clients, defining service‑account groups, and assigning least‑privilege roles, determines who may start a request. hoop.dev then enforces the policy at the gateway, ensuring that the NIST evidence chain is complete.
For teams ready to adopt this model, the getting‑started guide walks through deploying the gateway and registering a service account. The learn section provides deeper coverage of policy definition, approval workflows, and masking configurations.
FAQ
Does hoop.dev replace existing IAM solutions?
No. hoop.dev complements IAM by handling the enforcement point. Identity providers still issue tokens and define roles; hoop.dev consumes those tokens and applies runtime controls.
Can hoop.dev generate the audit evidence required for a NIST audit?
Yes. Because every request, approval, and data transformation is recorded by hoop.dev, auditors can retrieve a complete audit trail that can be reviewed to satisfy NIST requirements for audit and accountability.
Is hoop.dev suitable for high‑throughput CI pipelines?
hoop.dev is designed to handle production traffic for databases, Kubernetes, and SSH. Its architecture scales horizontally, and the gateway can be deployed close to the target resource to minimize latency.
Explore the source code and contribute on GitHub.
