Who is accountable when an unmanaged AI agent or service account creates exposure?

Accountability should sit with the owner of the identity and the team that approved its access, not with security alone. If the identity has no owner, that is a governance failure. Organisations need explicit lifecycle ownership, review and deprovisioning responsibilities for every non-human identity and AI-driven workflow.

Why This Matters for Security Teams

Accountability becomes operational the moment an unmanaged ai agent or service account can authenticate, request data, or chain tools without a clear owner. That is not a tooling problem first; it is an identity governance failure. The risk is amplified because autonomous workloads do not behave like users. They can act outside expected patterns, as documented in AI Agents: The New Attack Surface report and reflected in emerging guidance such as the OWASP Agentic AI Top 10.

When access is not tied to an explicit owner, approvals become vague, reviews stall, and deprovisioning is skipped because no team feels responsible. Security may detect the exposure, but security cannot be the permanent business owner of every unmanaged identity. The question is who accepted the risk, who maintains the workflow, and who can revoke it quickly when behaviour changes. In practice, many security teams encounter the missing owner only after an AI agent has already accessed something sensitive or a dormant service account has been abused.

How It Works in Practice

The accountable party should be the identity owner and the approving business or engineering team, with security providing control design, oversight, and evidence. For unmanaged AI agents, that usually means the product owner, platform owner, or workflow owner who introduced the agent into production. For service accounts, it is the application or infrastructure team that requested the credential and the manager who approved the access scope. This aligns with the operating model described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where lifecycle ownership is mandatory rather than optional.

Practically, organisations need a named owner, an approver, and a revoker for every non-human identity. That means:

• Binding each agent or service account to a system record with business owner, technical owner, and expiry date.
• Requiring just-in-time approval for elevated access rather than granting standing entitlements.
• Using workload identity and short-lived credentials so access is tied to task execution, not permanence.
• Reviewing agent activity against intended scope, especially when tool use or data access changes.
• Escalating unresolved ownership gaps as governance defects, not simply as security exceptions.

This model fits current guidance from the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasise governance, traceability, and monitored decision-making. It also becomes easier to enforce when policy decisions are checked at runtime instead of relying on static role assignments. These controls tend to break down in large hybrid environments where identities are created automatically by pipelines, because no single team remains in the loop long enough to accept ongoing responsibility.

Common Variations and Edge Cases

Tighter accountability often increases approval overhead, requiring organisations to balance speed of delivery against the cost of governance. That tradeoff is especially visible when AI agents are spawned dynamically by CI/CD, chatops, or workflow automation. Best practice is evolving, but current guidance suggests the owner should follow the workload, not the other way around. If a service account is shared across multiple apps, ownership should be assigned to the platform that provisions and monitors it, while each consuming team remains responsible for its own use.

There are two common edge cases. First, third-party managed agents may have a vendor operator, but that does not remove internal accountability for what data the agent can touch or which systems it can call. Second, legacy service accounts may have no obvious business sponsor. In those cases, the identity should be treated as an orphaned asset and either re-owned or removed. The reporting in AI Agents: The New Attack Surface report shows how often agent activity exceeds intended scope, which is why OWASP Agentic AI Top 10 and the NIST Cybersecurity Framework 2.0 both reinforce clear ownership, continuous monitoring, and rapid containment.

Where this guidance breaks down is in environments that allow self-provisioned agents with no registry, no review cadence, and no offboarding path. In that setting, accountability becomes theoretical until the incident response team has to reconstruct it after exposure has already happened.

Related resources from NHI Mgmt Group

• Who is accountable when a service account or AI agent keeps access after offboarding?
• Who is accountable when a service account or AI agent is over-privileged?
• Who should be accountable when an AI agent or service account causes access drift?
• Who is accountable when a compromised service account or AI agent moves laterally?