When a compromised service account runs unchecked, organizations can lose sensitive data, suffer costly downtime, and fail to demonstrate compliance with NIST requirements. The financial and reputational impact of an undetected machine‑initiated breach far exceeds the cost of implementing proper controls.
Most teams provision non‑human identities on AWS by attaching static IAM roles or long‑lived access keys to services, containers, or automation pipelines. Those credentials are often shared across multiple jobs, embedded in code repositories, or stored in configuration files without rotation. The result is a broad attack surface where a single leaked token can be used to access databases, Kubernetes clusters, or internal APIs.
Even when organizations adopt least‑privilege policies for machine identities, the request still travels directly to the target service. There is no checkpoint that records which command was run, no inline data masking to protect sensitive fields, and no workflow that forces a human to approve risky operations. In this state, audit logs are limited to IAM events, which do not capture the actual payload or intent of the request.
Why NIST demands continuous evidence of machine activity
NIST SP 800‑53 outlines a set of controls that apply to both human and non‑human actors. Controls such as AU‑2 (Audit Events), AU‑6 (Audit Review, Analysis, and Reporting), AC‑2 (Account Management), and IA‑2 (Identification and Authentication) require organizations to:
- Collect detailed logs of every access attempt, including the command or query issued.
- Retain those logs in a secure store for the duration mandated by the policy.
- Provide evidence that privileged actions were reviewed and, when necessary, approved by an authorized individual.
- Ensure that sensitive data returned by a system is protected from inadvertent exposure.
When machine identities are the primary actors, the same controls apply. Auditors expect to see not just that a role was assumed, but what the role actually did once it reached the service.
The enforcement gap in a pure IAM approach
IAM alone can enforce who is allowed to assume a role, but it cannot enforce what happens after the role is active. Without a data‑path enforcement layer, the following gaps remain:
- No command‑level audit: AWS CloudTrail records the AssumeRole call, but the subsequent SQL query, kubectl command, or SSH command is invisible.
- No inline masking: Sensitive fields such as credit‑card numbers or personal identifiers are returned to the caller unfiltered.
- No just‑in‑time approval: High‑risk operations (e.g., dropping a production database) execute immediately without a human check.
- No session replay: If an incident occurs, there is no way to reconstruct the exact sequence of commands issued by a machine identity.
These missing pieces prevent organizations from producing the continuous evidence required by NIST.
hoop.dev as the data‑path gateway
hoop.dev sits on the network edge between the identity provider and the target AWS resource. It proxies the connection, inspects traffic at the protocol layer, and applies guardrails before the request reaches the service. Because hoop.dev is the only point where the data flows, it can enforce every NIST control that depends on runtime visibility.
- Session recording: hoop.dev records each interaction, preserving the exact command text and response for later replay.
- Inline data masking: Sensitive fields are redacted in real time, ensuring that downstream logs never contain raw PII.
- Just‑in‑time approval: When a request matches a high‑risk pattern, hoop.dev routes it to an approver and blocks execution until the approval is granted.
- Command‑level audit: Every allowed or denied command is logged with the identity, timestamp, and outcome, satisfying AU‑2 and AU‑6.
- Policy‑driven access: Access rules are derived from OIDC claims, so only the intended non‑human identity can reach the gateway, satisfying AC‑2 and IA‑2.
Because the enforcement happens in the data path, removing hoop.dev would eliminate all of the above capabilities. The IAM role alone would no longer provide the audit depth or protection required by NIST.
How continuous evidence satisfies NIST controls
Below is a mapping of key NIST controls to the evidence that hoop.dev automatically generates:
- AU‑2 (Audit Events): Each proxied request is logged with full payload, creating a complete audit trail of what the machine identity actually did.
- AU‑6 (Audit Review, Analysis, and Reporting): Recorded sessions can be searched, filtered, and exported for analysis, enabling regular review cycles.
- AC‑2 (Account Management): hoop.dev enforces that only identities with the correct OIDC group membership can initiate a connection, and it revokes access instantly when the group membership changes.
- IA‑2 (Identification and Authentication): The gateway validates the OIDC token on every request, guaranteeing that the presented identity is authentic and unaltered.
- SI‑4 (Information System Monitoring): Real‑time alerts can be configured for denied commands or unusual patterns, providing immediate detection of suspicious activity.
- SC‑7 (Boundary Protection): By acting as a layer‑7 proxy, hoop.dev creates a logical boundary that isolates the target service from uncontrolled traffic.
All of this evidence is collected continuously, without requiring engineers to manually export logs after an incident. The result is a compliance‑ready audit trail that aligns with NIST’s expectation of ongoing, automated evidence collection.
Getting started with hoop.dev
To begin protecting your non‑human AWS identities, deploy the gateway using the quick‑start Docker Compose file, configure OIDC authentication, and register the AWS resources you need to protect. Detailed steps are available in the getting‑started guide and the broader feature documentation at hoop.dev/learn. The open‑source repository contains the full deployment manifests and example policies.
Once deployed, define policies that mask sensitive columns, require approval for destructive actions, and enable session replay. From that point forward, every machine‑initiated request will generate the continuous evidence needed for NIST compliance.
FAQ
Does hoop.dev replace AWS CloudTrail?
No. CloudTrail still records IAM events and API calls. hoop.dev complements it by capturing the actual payload of each proxied request, which CloudTrail does not provide.
Can I use hoop.dev with existing IAM roles?
Yes. The gateway stores the credential needed to talk to the target service, while the IAM role governs who may invoke the gateway. This separation allows you to keep existing role definitions.
How long are the session logs retained?
Retention is configurable in the deployment. Choose a period that matches your organization’s audit policy; the logs are stored in a protected location outside the target service.
Is there a cost to using hoop.dev?
hoop.dev is MIT‑licensed and open source. Operational costs are limited to the compute resources required to run the gateway and store logs.
Start protecting your machine identities and generate the continuous NIST evidence your auditors expect by deploying hoop.dev today.
Explore the open‑source repository for the full codebase and contribution guidelines.
