Who should be accountable when a shadow AI agent keeps broad access after its original owner changes roles?

Why This Matters for Security Teams

When a shadow AI agent keeps broad access after its owner changes roles, the real problem is not just stale entitlements. It is an orphaned autonomous workload that can still act, chain tools, and reach data long after human accountability has shifted. That is why governance has to follow the agent, not the employee. Current guidance on agentic risk from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward explicit accountability, runtime oversight, and continuous review rather than passive trust.

NHIMG research shows why this matters operationally: in the AI Agents: The New Attack Surface report, only 52% of companies can track and audit the data their AI agents access, while 80% report agents have already acted beyond intended scope. That combination creates a practical blind spot when ownership changes, because no one feels empowered to revoke access, reassess purpose, or confirm whether the agent still needs those privileges. In practice, many security teams discover this only after the agent has already touched sensitive systems during a routine role change.

How It Works in Practice

Accountability should be assigned to a named business owner and a named technical owner for each agent, with IAM, security, and platform teams enforcing that ownership in the control plane. The owner is responsible for purpose, scope, and review cadence; the technical owner is responsible for the agent’s workload identity, secrets, logs, and lifecycle events. This is especially important for autonomous systems because static, role-based access does not describe what the agent is trying to do at runtime.

For agents, best practice is evolving toward context-aware authorisation and just-in-time access. That means the agent proves its workload identity through cryptographic credentials, such as SPIFFE/SPIRE or OIDC-backed workload tokens, and receives short-lived secrets only for the task in hand. Policy engines then evaluate each request in real time, using policy-as-code, rather than relying on a broad standing role that was granted months earlier. If the owner changes roles, the agent should trigger an ownership review, a purpose revalidation, and a renewal decision before access continues.

• Map every agent to a human owner, a service owner, and a system record that cannot be left blank.
• Revalidate access whenever the owner changes role, team, or employment status.
• Prefer ephemeral credentials and short TTLs over static API keys or long-lived tokens.
• Log agent actions, tool calls, and data access so governance can prove who approved what.
• Use runtime policy checks for sensitive actions instead of pre-approved broad roles.

NHIMG’s OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework both reinforce the same operational pattern: the control point is not the human’s old role, but the agent’s current task and trust boundary. These controls tend to break down when agents inherit broad service accounts across legacy automation platforms because ownership, telemetry, and revocation are fragmented across teams.

Common Variations and Edge Cases

Tighter agent governance often increases operational overhead, requiring organisations to balance fast automation against the need for clear accountability. That tradeoff becomes sharper when agents are embedded in business workflows, because forcing every access change through manual review can slow delivery. The practical answer is not to ignore ownership, but to tier the controls by risk and privilege.

There is no universal standard for this yet, but current guidance suggests three common patterns. First, high-impact agents should have named owners, short-lived access, and mandatory review on role change. Second, low-risk internal helpers can be managed with lighter review cycles if their tool access is narrow and observable. Third, shared or cross-functional agents need explicit escalation paths so no one assumes another team is handling revocation.

Edge cases matter. A departed employee’s agent may still be running on a CI/CD system, a support workflow, or a data analysis pipeline, even though the person no longer has access. Or the agent may be “owned” by a team that has restructured, leaving no one with authority to approve continued use. In those cases, the safest interim action is to suspend broad access, preserve logs, and reissue the workload identity only after a new accountable owner is assigned.

That operating model aligns with the OWASP Non-Human Identity Top 10 and NIST’s broader identity and risk governance principles. It is also where shadow agents become most dangerous: when they look like ordinary automation, but no one can prove who is responsible for their permissions.

Related resources from NHI Mgmt Group

• Who is accountable when a service account or AI agent keeps access after offboarding?
• Who is accountable when an approved AI application keeps access after the original business need has changed?
• Who is accountable for governing AI agent access and policy decisions in ecommerce?
• What should teams do when an AI agent keeps access after a project ends?