Sit across from someone assessing you against a NIST framework and the conversation is a sequence of pointed questions. Who is this account? What can it reach? Show me the access was authorized. Show me the log. NIST for AI coding agents is best understood by working backward from those questions, because an AI coding agent that writes and runs code will be the subject of every one of them the moment it can touch real infrastructure.
NIST publications like SP 800-53 and the Cybersecurity Framework do not single out AI agents. They define control families, identity and access management, audit and accountability, least privilege, that apply to any principal. The agent is a non-human principal with a lot of reach, so the assessor's questions get sharper, not different.
The questions, and why the agent complicates them
Map the assessor's questions to the NIST control families they come from:
- Identification and authentication (IA): who is this principal and how was it authenticated? An agent on a shared key has no real answer.
- Access control (AC): was access least privilege and authorized? A standing service credential is neither.
- Audit and accountability (AU): where is the record, and is it protected from the principal it describes? An agent's own logs are not.
The pattern repeats: the agent is fine as a principal, but the usual way teams wire it up, shared credential, broad standing access, self-logging, fails every control family on the first question.
The architectural answer NIST points to
NIST's audit family is explicit that audit information must be protected from unauthorized modification, including by privileged users acting within their authority. Extend that to a software principal and the conclusion is the same: the audit record of the agent's access cannot live inside the agent. It has to be generated at a boundary the agent does not control.
Put an access gateway in front of the infrastructure the agent reaches, and the assessor's questions get clean answers. hoop.dev authenticates each agent session against your identity provider, grants scoped just-in-time access instead of standing privilege, and records every command outside the agent process. To keep the scope honest: hoop.dev governs the infrastructure connection the agent opens. It does not inspect the model's prompt or output. The control surface is the database, cluster, and service access, which is exactly where the AC, IA, and AU questions point.
Answering each question with a record
- IA: "Each agent session authenticates through OIDC or SAML as a named service identity." The session log is the proof.
- AC: "Access is just-in-time and scoped to the task; the agent holds no standing production rights." The grant record shows scope and duration.
- AU: "Every command is recorded at the gateway, outside the agent, so the principal cannot alter the trail." The session recording is the artifact.
- Data protection: "Sensitive fields are masked in results on connections that support it, before they reach the agent."
hoop.dev generates the evidence teams use to map controls to NIST families. It does not certify anything against NIST, and you should not claim a system "is NIST compliant"; NIST is a control catalog you implement and assess, not a badge a product confers.
A concrete check
An assessor asks to see the last week of an agent's access to a production cluster. You export the gateway sessions: each one shows the authenticated identity, the time-bounded grant, and the exact kubectl commands run, with no gap where the agent could have edited the record. That export answers IA, AC, and AU in one artifact, which is the point of moving the boundary off the agent.
FAQ
Which NIST controls apply to an AI coding agent?
The same identity, access control, and audit families that apply to any principal with system access. The agent is a non-human principal, so the controls scope to it directly.
Can hoop.dev make us NIST compliant?
No. hoop.dev generates the access evidence you map to NIST control families. Implementation and assessment remain your program's responsibility.
Does hoop.dev examine the agent's reasoning?
No. It governs the connections the agent makes to infrastructure, not the model's prompt or output.
The records an assessor wants have to come from outside the actor. See the gateway model on the hoop.dev getting started guide, and read the access and audit code at github.com/hoophq/hoop.
