All posts

NIST for AI agents: controlling access for audit-ready operations

NIST does not ask whether your AI agent is well-behaved. It asks whether you can show that access to a system was authorized, least-privilege, and recorded. The access-control family in NIST 800-53 and the audit family turn into concrete questions: which identity acted, what was it allowed to do, and where is the record. For an AI agent that opens connections to production on its own, those questions are hard to answer after the fact, because the agent is usually the only witness to what it did.

Free White Paper

AI Audit Trails + Audit-Ready Documentation: The Complete Guide

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

Free. No spam. Unsubscribe anytime.

NIST does not ask whether your AI agent is well-behaved. It asks whether you can show that access to a system was authorized, least-privilege, and recorded. The access-control family in NIST 800-53 and the audit family turn into concrete questions: which identity acted, what was it allowed to do, and where is the record. For an AI agent that opens connections to production on its own, those questions are hard to answer after the fact, because the agent is usually the only witness to what it did.

This post works through what a NIST-aligned program actually needs from an agent's access, and why the records that satisfy it cannot live inside the agent.

What NIST asks for in practice

Strip the relevant NIST 800-53 controls down to what they demand of an agent and three show up repeatedly. AC-2 wants account management: every identity, including non-human ones, accounted for. AC-6 wants least privilege: access no broader than the task. AU-2 and AU-12 want audit events: a record of what was accessed, generated by the system, not the actor. Each of these is a demonstrable record, and each is one an agent struggles to produce about itself.

An agent cannot be its own witness

The common approach is to log inside the agent framework. That record sits inside the boundary NIST is asking you to audit. An agent with a steered prompt or a bug can write a misleading record or none at all, and AU-12 wants the audit event generated where the actor cannot suppress it. The control has to sit on the access path between the agent and the system, not in the agent's own code.

Put the controls where the agent cannot reach them

The architectural requirement is that authorization and recording happen outside the process the agent controls. hoop.dev is built to that shape. It is an open-source Layer 7 access gateway that proxies an agent's connections to infrastructure such as databases, Kubernetes, and SSH, and it enforces the NIST control families on the connection itself.

Continue reading? Get the full guide.

AI Audit Trails + Audit-Ready Documentation: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

On that single path, the agent authenticates as a named identity, satisfying AC-2. Access is scoped just-in-time to the task, satisfying AC-6. Every session is recorded at the command level outside the agent, satisfying AU-2 and AU-12. Inline masking keeps sensitive fields out of the agent's view. See how hoop.dev governs and records each connection for the mechanics.

Consider an agent triaging a production incident. It needs to read one table in the orders database for thirty minutes. Through hoop.dev it gets exactly that: a scoped, time-bound grant tied to its own identity, every query it runs captured in the session record, and customer email fields masked in the returned rows. When the window closes, the access ends on its own with no credential left behind. The AC-6 least-privilege story and the AU-12 audit story are satisfied by the same grant, not assembled afterward.

From control to evidence package

When an assessment maps your controls to the AC and AU families, the records line up because they came from one place. The per-identity logs answer AC-2, the scoped grants answer AC-6, and the session recordings answer the audit family. hoop.dev does not hold a NIST certification, because NIST 800-53 is a framework you align to, not a badge a tool carries. It generates the evidence for NIST that your program presents. To start, connect a system through hoop.dev, or read the model at hoop.dev.

FAQ

Is hoop.dev NIST certified?

There is no NIST certification for a tool to hold, and it would not matter if there were, because hoop.dev is self-hosted. It runs inside your own infrastructure and never stores your data on a hoop.dev-operated service, so it does not become a system NIST has to assess separately. hoop.dev generates the access evidence your NIST 800-53 AC and AU controls rely on.

Which NIST controls does this map to?

Most directly AC-2 account management, AC-6 least privilege, and AU-2 and AU-12 for audit events, because hoop.dev attributes, scopes, and records each connection an agent makes.

hoop.dev is open source, so you can inspect exactly how access is governed and recorded at the hoop.dev repository 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