Accountability sits with the organisation that allowed authority to flow without revalidation. If the identity proof is stale, delegated, or implicit, then the governance failure is architectural, not operational. Frameworks such as Zero Trust and NHI governance both point to the same issue: trust must be continuously asserted, not assumed.
Why This Matters for Security Teams
When an AI agent or workflow executes privileged actions under a forged identity, the issue is not just fraud. It is a control failure in how authority was issued, refreshed, and bounded. Static IAM assumptions are brittle because autonomous systems do not behave like predictable human users. They chain tools, change plans mid-task, and can carry stolen or stale credentials far beyond the original context. That is why current guidance increasingly treats agent identity as a runtime governance problem, not a one-time provisioning task, as reflected in the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework.
NHIMG research shows the blast radius is already real: 80% of organisations report AI agents have performed actions beyond their intended scope, and 23% have revealed access credentials. The same pattern appears in NHI environments when secrets are long-lived, poorly scoped, or indirectly inherited from surrounding systems. The security team is accountable for the architecture that allowed the forged identity to be trusted in the first place. In practice, many security teams encounter the incident only after the agent has already moved laterally, rather than through intentional validation of its authority.
How It Works in Practice
Accountability starts with the entity that owns the workload, the policy, and the trust boundary. For autonomous agents, that usually means the organisation operating the agent, plus the control owners who approved its access model. A forged identity becomes dangerous when the system accepts it without revalidating whether the request matches the agent’s current task, context, and privilege scope. This is why static role assignment is increasingly inadequate. Best practice is evolving toward intent-based or context-aware authorisation, where each action is evaluated at runtime instead of being inherited from a broad role.
Operationally, that means combining workload identity with short-lived credentials. A valid pattern is to issue ephemeral credentials per task, bind them to the agent’s workload identity, and revoke them automatically when the task ends. Standards such as SPIFFE and SPIRE help express what the workload is in cryptographic terms, while policy engines can decide what it may do in that moment. That approach aligns with the governance themes in Ultimate Guide to NHIs and the implementation direction in CSA MAESTRO agentic AI threat modeling framework.
- Use workload identity for the agent, not a shared service account.
- Issue just-in-time credentials with narrow scope and short TTL.
- Evaluate policy at request time with full task context.
- Revoke authority when the task changes, fails, or completes.
That model also improves attribution. If a forged identity triggers privileged actions, logs should show which workload presented the proof, which policy approved the request, and which control failed to detect the mismatch. These controls tend to break down when agents inherit privileges from orchestration layers because the platform obscures the true actor behind a shared automation boundary.
Common Variations and Edge Cases
Tighter identity controls often increase operational overhead, requiring organisations to balance reduced blast radius against deployment complexity. That tradeoff becomes sharper in multi-agent systems, CI/CD pipelines, and delegated automation where one agent invokes another. Current guidance suggests treating each hop as a separate trust decision, but there is no universal standard for this yet. Some environments can enforce a clean workload identity boundary; others still depend on legacy API keys, shared vault paths, or proxy-issued tokens that blur accountability.
Edge cases also emerge when the forged identity is not fully fake but merely over-privileged. In those situations, blame is not limited to the operator of the agent. Governance also extends to the identity team, platform team, and application owners who approved excessive standing access. NHIMG’s Top 10 NHI Issues and AI Agents: The New Attack Surface report both show that visibility gaps and broad entitlements are the conditions that let forged or misused identities persist long enough to matter.
For this reason, accountability should be assigned through control ownership, not just incident response. The organisation is accountable when it allowed authority to flow without revalidation. Individual operators may execute the system, but they do not own the trust model that made the forged identity acceptable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Forged identities and agent misuse map to agentic authz failures. |
| CSA MAESTRO | TRD-2 | MAESTRO covers trust boundaries and delegated agent action control. |
| NIST AI RMF | GOVERN | AI RMF GOVERN addresses accountability for autonomous system decisions. |
Revalidate agent authority at runtime and bind every tool call to current task context.
