A CI pipeline runs nightly to refresh a reporting schema in a PostgreSQL instance. The job uses a service account token that was granted full read‑write access months ago. When a new table is added, the pipeline writes data without any human review, and the security team has no record of which job performed the change. Weeks later, an auditor asks for proof that only authorized automation touched the database, but the logs show only generic system events. The organization struggles to prove compliance with NIST requirements for machine‑originated activity.
Non‑human identities, service accounts, CI jobs, bots, and AI agents, are essential for modern infrastructure, yet they often bypass the same controls that protect human users. NIST SP 800‑53 and the Cybersecurity Framework expect continuous, verifiable evidence that every access request, command, and data movement is authorized, recorded, and auditable. The challenge is to collect that evidence without rewriting every automation script or exposing secrets to the processes that need them.
Why NIST evidence must be continuous for machine identities
NIST defines several control families that directly affect automated access:
- AU‑3: Content of audit records must include user or process identifiers, timestamps, and the nature of the event.
- AC‑2: Account management requires that privileged accounts be provisioned with least‑privilege and reviewed regularly.
- IA‑4: Identifier authentication must be tied to an identity that can be uniquely traced.
- CM‑7: Change control must enforce approvals for configuration changes, even when performed by scripts.
When a service account connects directly to PostgreSQL, the database sees only a static credential. It cannot distinguish whether a human or a script issued a query, nor can it enforce just in time (JIT) approvals. Consequently, audit logs lack the context required for NIST compliance, and any deviation from policy goes unnoticed.
How hoop.dev provides the data‑path enforcement needed for NIST
hoop.dev acts as a Layer 7 gateway that sits between the identity provider and the PostgreSQL server. The gateway is the only place where traffic can be inspected, masked, approved, or recorded. Because the gateway holds the database credential, the downstream service never sees the secret; the service account only presents an OIDC token that hoop.dev validates.
When a non‑human identity initiates a connection, hoop.dev performs the following NIST‑aligned actions:
- Session recording: hoop.dev records every query and response, creating a replay that satisfies AU‑3.
- Inline data masking: Sensitive columns (e.g., SSN, credit‑card numbers) are masked in real time, reducing exposure while still providing useful results to the automation.
- Just in time approval: If a query matches a high‑risk pattern, such as a DROP TABLE or a bulk INSERT, hoop.dev routes the request to a designated approver before execution, meeting CM‑7.
- Command level audit: Each statement is logged with the originating service account, the OIDC subject, and the exact timestamp, fulfilling IA‑4 and AC‑2 traceability requirements.
All of these outcomes are possible only because hoop.dev resides in the data path. The identity provider alone cannot enforce command‑level policies, and the database cannot verify that a request has been approved.