Who is accountable when agentic workflows use identity checks that were built for people?

Why This Matters for Security Teams

When identity checks are designed for people, agentic workflows can inherit controls that assume a human will pause, review, and stay within a narrow role. That assumption breaks as soon as an agent can chain tools, retry failed actions, or operate across systems without direct supervision. Accountability then becomes a governance problem, not a model capability problem. The organisation that deploys the agent must own scope, logging, and termination conditions, because a model cannot accept responsibility or remediate its own privilege misuse. Guidance from the NIST AI Risk Management Framework and NHIMG research on the Ultimate Guide to NHIs both point to the same operational reality: identity governance must follow the workload, not the user interface. In practice, many security teams encounter over-privileged agent behaviour only after a tool invocation or token leak has already expanded access, rather than through intentional design.

How It Works in Practice

Accountability needs to be assigned at three layers: the business owner who authorises the agent’s purpose, the security or IAM owner who defines control boundaries, and the engineering team that implements those controls. For agentic workflows, static RBAC alone is too coarse because the agent’s actions are goal-driven and context-sensitive. A better pattern is intent-based authorisation combined with runtime policy evaluation, where each request is checked against task context, risk signals, and environment state. That is the direction reflected in the OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework.

In practice, that means:

• Issue short-lived, just-in-time credentials per task instead of long-lived secrets.
• Bind agent identity to workload identity, such as OIDC-backed tokens or SPIFFE-style attestation, so the system can prove what the agent is.
• Log every tool call, token issuance, policy decision, and revocation event with an accountable human or team owner.
• Define explicit termination conditions so an agent cannot continue operating after task completion, anomaly detection, or ownership change.
• Use policy-as-code so approvals can be evaluated at request time rather than frozen into static role definitions.

NHIMG’s research shows why this matters: 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into service accounts, which makes unowned automation especially dangerous when agents are treated like users instead of workloads. The LLMjacking: How Attackers Hijack AI Using Compromised NHIs analysis also shows how quickly exposed credentials can be abused once they exist. These controls tend to break down in environments where agents have broad cross-domain tool access and no central policy engine because runtime decisions cannot be enforced consistently.

Common Variations and Edge Cases

Tighter agent controls often increase integration and review overhead, requiring organisations to balance autonomy against operational friction. There is no universal standard for this yet, so current guidance suggests matching accountability to the level of execution authority an agent actually has. A low-risk summarisation agent may need simple logging and task limits, while a financial or infrastructure agent needs formal approval chains, scoped secrets, and immediate revocation paths.

Edge cases appear when agents are nested inside orchestration layers or multi-agent pipelines. In those environments, responsibility can fragment unless one owner is designated for the whole workflow, not each sub-agent. Another common gap is shadow usage, where teams expose human-oriented identity checks to agents through shared accounts or copied tokens. That is a governance failure even if the tool technically works. NHI guidance in the OWASP NHI Top 10 and threat modelling from the MITRE ATLAS adversarial AI threat matrix both reinforce that autonomous systems need controls designed for machine speed, not human review cycles. The practical rule is simple: if no person or team can terminate, audit, and explain the agent’s access path, accountability has not actually been assigned.

Related resources from NHI Mgmt Group

• When should organizations use MCPs for AI identity management?
• How should security teams govern machine identity credentials in agentic AI environments?
• What breaks when authorization only checks identity in agentic workflows?
• How do organisations know if agentic identity workflows are safe enough to use?