Identity, Logging, and Human-in-the-Loop: The Governance Floor

A system can have perfect runtime boundaries and still be impossible to govern. Suppose an AI agent, tightly scoped and well-guarded, does something harmful within its permitted scope — a legitimate-but-wrong action. Three questions immediately follow, and a well-guarded system with no governance floor can answer none of them. Who did it — which agent, acting for whom? What exactly happened, in enough detail to understand and reverse it? And who was accountable for allowing a consequential action to proceed? These are the questions the governance floor answers, through three controls: verifiable identity, structured logging, and a human-in-the-loop gate on irreversible actions. They do not constrain what the system does — that is the runtime boundaries' job — they make what it does attributable, observable, and accountable. This is the governance complement to the runtime floor, and it is just as non-negotiable, because a system you cannot attribute, cannot observe, and cannot halt at the consequential moment is a system you cannot operate safely, no matter how well its runtime surfaces are guarded.

Three questions the runtime floor cannot answer

The runtime boundaries answer what a system is allowed to do; the governance floor answers three questions that arise after it acts. The first is attribution: who performed an action — which specific agent, under whose authority, acting for which principal? Without an answer, you cannot assign responsibility, cannot revoke the right thing, and cannot reason about a compromise. The second is observability: what actually happened — a record detailed enough to detect that something went wrong and to reconstruct the sequence afterward? Without it, an incident is invisible while it happens and unreconstructable after. The third is accountability for consequence: for the actions that cannot be undone, was there a point at which a responsible human agreed? Without such a point, a system can take an irreversible step entirely on its own authority, and no one chose to let it.

These three questions map onto three controls with no overlap: identity answers who, logging answers what happened, and the human gate answers who was accountable for the consequential. Together they are the governance floor — the minimum that makes a runtime-secured system operable rather than merely constrained. The distinction from the runtime boundaries is worth holding: the boundaries are preventive, stopping actions before they happen; the governance controls are about attribution, evidence, and consequence, ensuring that whatever does happen is owned, seen, and — for the irreversible — chosen. A system needs both, because prevention is never perfect, and when a boundary is bypassed or a scoped action turns out to be wrong, the governance floor is what lets you find out, understand, and answer for it.

Identity: making every action attributable

The identity control requires that every agent and every consequential action carries a verifiable identity bound to a bounded set of privileges. Verifiable means the identity can be checked cryptographically rather than merely claimed, so an action can be traced to the specific agent that took it and the principal on whose behalf it acted. Bounded means that identity carries only the privileges the agent's task requires — the least-privilege principle applied to authority itself, so the identity both attributes an action and limits what that action could have been. The two properties reinforce each other: attribution without bounded privilege tells you who did something but not that it was within their remit, and bounded privilege without attribution limits actions but cannot tell you who took them. The baseline requires both.

The security value of identity is that it is the precondition for everything reactive. You cannot revoke an agent's authority if you cannot identify it; you cannot investigate a compromise if actions are anonymous; you cannot contain a misbehaving agent if you cannot tell which one it is. Identity is the anchor that makes the entire response and containment apparatus possible, which is why the NIST Cybersecurity Framework places identity and access management at the core of its protect function, and why the zero-trust guidance in NIST SP 800-207 treats every action as needing an authenticated, bounded principal. The practical form is a verifiable workload identity for every agent and a bounded credential for every action, so that the answer to who acted is never unknown — because a system in which actions are anonymous is a system in which nothing can be held responsible and nothing can be cleanly stopped.

Logging: detect and reconstruct

The logging control requires that a system records its actions in a form that supports two distinct purposes: detecting that something is wrong while it is happening, and reconstructing what happened after the fact. These are different requirements. Detection needs logs that are timely and structured enough to feed monitoring — anomalous tool calls, policy violations, unexpected patterns surfaced quickly. Reconstruction needs logs that are complete and tamper-evident enough that, after an incident, you can walk the full sequence of what the system did and establish ground truth. A system that logs for one purpose but not the other has a governance gap: it may catch an incident but not be able to explain it, or explain it in hindsight but never catch it live. The baseline requires logging adequate for both.

The reason logging is non-negotiable is starker than it first appears: an unlogged system is undefendable after the fact. When something goes wrong, the log is the only source of truth about what actually occurred, and its absence means the incident is not merely undetected but permanently unknowable — you cannot fix what you cannot see, cannot reverse what you cannot trace, and cannot learn from what you cannot reconstruct. This is why the NIST Cybersecurity Framework's detect and respond functions, and the NIST AI RMF's measure function, all depend on the same substrate: observability. The practical form is structured, attributable, tamper-evident logging of every consequential action, tied to the identity that took it. Logging and identity thus compose directly — a log without attribution tells you something happened but not who did it, and an identity without logging tells you who can act but not what they did. Together they make the system's behavior both attributable and visible, which is the precondition for the investigation and containment a security program needs.

Human-in-the-loop: the gate on the irreversible

The human-in-the-loop control requires a defined point at which a responsible human must approve before the system takes a consequential or irreversible action. Its purpose is narrow and precise: to ensure that no unrecoverable step happens entirely on the system's own authority. This is not a demand that a human approve everything — that would reintroduce the bottleneck that makes automation pointless and train the human to rubber-stamp. It is a demand that the specific class of actions whose consequences cannot be undone — deleting data, moving money, sending an irreversible external communication, taking a production system down — pass through a human who is accountable for allowing them. The NIST AI RMF's govern function calls for exactly this: meaningful human oversight, placed where it matters rather than everywhere.

The design discipline is drawing the line correctly, and the reversibility principle draws it: reversible actions can proceed on the system's authority, subject to logging and later review; irreversible actions require a human in the loop. This keeps the human gate rare enough to be meaningful — a human who is asked to approve only the genuinely consequential can actually attend to each request, rather than clicking through a flood. Placed well, the gate is the accountability control: for every action that could cause unrecoverable harm, there is a person who chose to allow it, whose identity is logged alongside the action. Placed badly — on everything, or on nothing — it either becomes rubber-stamping or leaves the system able to take an irreversible step with no one accountable. The gate's value is entirely in where it sits, and the baseline requires only that it sits on the irreversible, which is the minimum that keeps a human answerable for the consequences that cannot be taken back.

How the three compose

The governance controls are not independent; they enable one another, and their composition is what makes a system operable. Identity is the foundation: logging is only useful if each logged action is attributed to a principal, and the human gate is only accountable if the approving human's identity is recorded. Logging is the connective tissue: it captures what identity attributes and records the human gate's decisions, producing the evidence trail on which investigation and containment run. And the human gate is the backstop: for the actions where attribution and observability after the fact are not enough — because the harm cannot be undone — it inserts a responsible human before the fact. Remove any one and the other two are diminished: logging without identity records anonymous events, identity without logging attributes actions no one recorded, and a human gate with neither has no evidence of what was approved or by whom.

Composed, the three answer the full set of governance questions the runtime floor cannot. Who acted — identity. What happened — logging. Who is accountable for the irreversible — the human gate, recorded via the first two. This is why they belong together in the baseline as a unit: each closes a distinct governance gap, and together they turn a system that merely does constrained things into one whose actions are owned, seen, and — for the consequential — chosen. The runtime floor and the governance floor are the two halves of the baseline: the runtime boundaries prevent, the governance controls account, and a system needs both because prevention without accountability is unauditable and accountability without prevention is reactive-only. The whole baseline is the pairing, and the governance floor is the half that lets you operate, investigate, and answer for the system after it acts.

Limits and honest caveats

The governance floor is necessary but carries its own honest limits. Identity attributes actions to a principal, but a compromised principal acts under a valid identity — attribution tells you which agent, not that the agent was acting as itself; identity must therefore be paired with the behavioral and verification controls that detect a hijacked-but-authenticated agent. Logging records what happened, but only what it was built to record, and only if the logs themselves are protected — a log an attacker can tamper with or a consequential action nobody thought to log is a governance gap that looks like coverage. And the human gate is only as good as the human's genuine attention and the correctness of the reversible/irreversible line: a gate on the wrong actions, or one a fatigued human clicks through, provides the form of accountability without the substance.

There is also a scope boundary to state plainly. These three are the governance floor, not the whole of governance — a mature program adds risk management, policy, audit, and the organizational controls that standards like ISO/IEC 42001 define, which make the technical controls stick over time. The floor is the minimum that makes a system operable and accountable; the fuller governance program builds on it. And, as with every baseline control, presence is necessary but quality decides value: attributable-in-principle identity that is never checked, logs no one monitors, and a gate no one staffs are checkboxes, not controls. The governance floor's promise is bounded and honest — it makes a runtime-secured system attributable, observable, and accountable for the irreversible, which is exactly the minimum required to operate it safely, and no more.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

governance_floor:
  identity:
    every_agent: verifiable_workload_identity
    every_action: bounded_credential
  logging:
    scope: all_consequential_actions
    attributed_to: action_identity
    tamper_evident: true
    purposes: [live_detection, reconstruction]
  human_gate:
    applies_to: irreversible_actions_only
    record: approver_identity + action
    reversible_actions: proceed_with_logging

Glossary

Governance floor

The minimum governance controls — identity, logging, human gate — that make a runtime-secured AI system attributable, observable, and accountable.

Verifiable identity

An identity that can be checked cryptographically rather than merely claimed, so an action traces to a specific agent and principal.

Bounded authority

Least privilege applied to identity, so a principal carries only the rights its task requires.

Attribution

The ability to trace an action to who performed it and on whose behalf.

Reconstruction

Rebuilding the full sequence of a system's actions after an incident from complete, tamper-evident logs.

Observability

The property that a system's behavior can be seen well enough to detect problems live and reconstruct them afterward.

Human-in-the-loop gate

A defined point where a responsible human must approve before a consequential or irreversible action proceeds.

Meaningful oversight

Human review a person can actually perform at the required rate, as opposed to nominal rubber-stamping.

References

1. NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
2. NIST Cybersecurity Framework (CSF) 2.0
3. NIST SP 800-207, Zero Trust Architecture (2020)
4. NIST SP 800-53 Rev. 5, Security and Privacy Controls (Audit and Accountability, Access Control)
5. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
6. OWASP Top 10 for LLM Applications (2025)
7. ISO/IEC 42001, AI Management System (2023)