Who should be accountable when an agent can act with and without a human present?

Why Accountability Changes When an Agent Acts Alone

When an agent can operate with or without a human present, accountability shifts from the moment of approval to the design of the policy itself. That is why agentic systems cannot be governed as if they were ordinary service accounts. The accountable owner must define what the agent may do unsupervised, what requires human confirmation, and what must never be delegated. NHI Management Group’s Ultimate Guide to NHIs shows why this matters: 97% of NHIs carry excessive privileges, and that pattern becomes more dangerous when an autonomous workflow is allowed to continue without oversight.

Industry guidance is converging on a simple principle: supervision changes the risk model, so the permission model must change too. A policy that treats supervised and unsupervised execution as equivalent creates blurred ownership, because no one can later explain whether a risky action was intended for human review or for autonomous execution. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward explicit governance for agent behaviour, not just identity issuance. In practice, many security teams encounter accountability failures only after an agent has already chained tools and expanded scope beyond what the original approver understood.

How Teams Assign Accountability in Practice

For autonomous agents, accountability should be anchored to the team that owns the policy model, the tool catalog, and the runtime guardrails. That team is responsible for defining the agent’s operating envelope, including which actions are permitted only when a human is present and which can proceed under zero-standing privilege. The operational goal is not to trust the agent more, but to constrain its blast radius with intent-based authorisation, short-lived credentials, and continuous policy evaluation.

A practical pattern looks like this:

• Use workload identity for the agent, so the system proves what it is at runtime rather than relying on a static shared secret. Standards such as SPIFFE support that model.
• Issue just-in-time credentials for a single task, then revoke them on completion. Long-lived secrets make accountability hard because they outlive the decision that justified them.
• Separate supervised and unsupervised execution paths in policy. A request that is acceptable with a human present may be rejected when the agent is alone.
• Evaluate policy at request time using policy-as-code and the full context of the action, rather than a fixed RBAC role that assumes stable behaviour.

That approach aligns with the threat patterns documented in OWASP NHI Top 10 and the agent risk themes in the NIST AI Risk Management Framework. It also fits the reality that agents can laterally move between tools, so the accountable team must own the policy changes, not just the initial provisioning event. These controls tend to break down in environments where one agent account is reused across multiple pipelines and product teams because the decision trail becomes too fragmented to assign responsibility cleanly.

Where the Model Gets Messy

Tighter separation between supervised and unsupervised access often increases operational overhead, requiring organisations to balance safety against delivery speed. That tradeoff becomes most visible in fast-moving environments where teams want agents to act independently during normal operations, but still need humans involved for higher-risk actions. There is no universal standard for this yet, so the best practice is evolving toward clear policy tiers rather than one blanket privilege set.

One common edge case is a shared platform team that runs the agent infrastructure while product teams define the tasks. In that model, the platform team may own the technical enforcement, but the product team still owns the policy intent for the actions it requested. Another edge case appears when the same agent can operate in both read-only and write-capable modes. If the policy does not distinguish those modes, the human-present and human-absent paths collapse into the same entitlement, which defeats the whole accountability model.

For that reason, current guidance from the CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework is to document who owns the policy, who approves exceptions, and which actions require runtime confirmation. NHI Management Group’s research on the AI LLM hijack breach is a reminder that once an agent is allowed to pivot across tools, accountability gaps become incident-response gaps very quickly.

Related resources from NHI Mgmt Group

• Who is accountable when an agent performs a sensitive action without adequate approval?
• What breaks when an AI agent can act inside a pipeline without human approval?
• Who is accountable when an AI agent leaks restricted information through paraphrase?
• Who is accountable when an AI workflow touches CUI without a distinct identity?