Who is accountable when an orphaned AI agent keeps accessing live data?

Why This Matters for Security Teams

An orphaned AI agent is not just a cleanup problem. If it still has live data access, it remains an active identity with business impact, audit exposure, and breach potential. The real failure is often ownership drift: the team that built the agent may no longer run it, while the platform team may not know what the agent is authorised to do. NHIMG research on AI Agents: The New Attack Surface report found that 80% of organisations say their AI agents have already acted beyond intended scope, which is a clear sign that accountability cannot stop at the code owner.

For security teams, the issue is governance, not just IAM hygiene. An agent with stale permissions can continue to read records, chain tools, or expose secrets long after the original business need has ended. That is why current guidance suggests treating each agent as a governed workload with a named owner, a retirement condition, and a recurring recertification point. The NIST AI Risk Management Framework reinforces the need for accountability and ongoing oversight, while NHIMG’s Ultimate Guide to NHIs frames non-human identities as assets that must be owned, reviewed, and retired like any other production control. In practice, many security teams discover orphaned agents only after access reviews, incident response, or audit findings expose them.

How It Works in Practice

Accountability should be assigned to the business or technical owner who approved the agent’s purpose, data scope, and runtime authority. That owner is responsible for defining what the agent can access, why it exists, when it must be recertified, and what event triggers retirement. Security teams then enforce the control plane around that decision. The right model is closer to workload governance than human user management, which is why OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 both emphasise identity lifecycle, privilege control, and abuse paths that persist after deployment.

Operationally, a sound program uses:

• Named ownership in CMDB, ticketing, or cloud tags, with a real person accountable for sign-off.
• JIT or short-lived credentials so the agent does not keep standing access just because it is still deployed.
• Recertification tied to business events such as product sunset, model change, or data classification change.
• Automated revocation when the agent is idle, deprecated, or fails policy checks.
• Logging that shows which data sets were touched, by which agent identity, and under which approval.

The key point is that orphaned does not mean harmless. If the workload identity remains valid, the agent is still authorised until somebody explicitly withdraws that authority. Best practice is evolving toward intent-based control decisions at runtime, because static role assignments do not describe what an autonomous agent may try next. Guidance from the NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework both support continuous evaluation rather than one-time approval. These controls tend to break down when agents are embedded in multiple pipelines with shared secrets, because no single team sees the full access path.

Common Variations and Edge Cases

Tighter ownership and retirement controls often increase administrative overhead, requiring organisations to balance faster agent deployment against stronger accountability. That tradeoff matters most in high-churn environments where agents are cloned, delegated, or embedded in orchestration layers. There is no universal standard for exactly how often recertification must occur, but current guidance suggests aligning it to risk, data sensitivity, and whether the agent can independently call tools or move laterally.

Some edge cases deserve special handling. A research sandbox agent may not need the same review cadence as an agent that can query customer records. A vendor-managed agent may introduce ambiguity if the contract owner is not the operational owner. A dormant agent can still be dangerous if its token, certificate, or API key remains valid. NHIMG’s LLMjacking: How Attackers Hijack AI Using Compromised NHIs and Moltbook AI agent keys breach show why long-lived secrets and exposed identities quickly become attacker entry points. The safe operating assumption is simple: if no owner can approve continued access, the agent should be treated as ungoverned until proven otherwise.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent acts after the user is offline?
• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?