Who should be accountable when an AI agent or service account causes access drift?

Why This Matters for Security Teams

Access drift becomes a governance problem the moment a service account or AI agent keeps privileges that no longer match the business process it serves. The technical failure is often obvious only after a workload starts calling adjacent systems, reusing stale tokens, or being repurposed without a fresh review. That is why accountability must sit with the human owner who approved the identity, not with the identity itself.

NHI governance work repeatedly shows that compromise and misuse rarely stay neatly inside the original use case. NHIMG’s 52 NHI Breaches Analysis and the AI LLM hijack breach research both underscore the same pattern: once machine identities are over-entitled, attackers and automation alike can move faster than review cycles. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points toward human accountability, runtime oversight, and explicit ownership, not self-governing identities.

In practice, many security teams encounter access drift only after the agent has already accessed systems that were never part of its original approval.

How It Works in Practice

Operational accountability should map to the person or team that can answer three questions: why the identity exists, what business process it serves, and who can change its scope. For service accounts, that usually means the application owner or platform team. For AI agents, it is typically the product owner or workflow owner, because the agent’s access changes as tools, prompts, connectors, and permissions change.

That accountability has to be paired with controls that make drift visible. The practical model is:

• Assign one named human owner for every non-human identity.
• Bind the identity to a documented business purpose and approval record.
• Review effective permissions on a fixed cadence and after material workflow changes.
• Use just-in-time access, short-lived tokens, and workload identity where possible.
• Log changes to connectors, scopes, secrets, and delegated permissions as first-class audit events.

For autonomous systems, static RBAC is often too coarse because the agent’s intent can shift at runtime. That is why implementation guidance increasingly favors context-aware authorization, policy-as-code, and ephemeral credentials issued per task. NHI programs that follow this model reduce reliance on long-lived secrets and make it easier to revoke access when the business process changes. NHIMG’s Ultimate Guide to NHIs highlights how fragmented secret ownership and inconsistent lifecycle controls create exactly the conditions where drift persists unnoticed. For implementation alignment, the CSA MAESTRO agentic AI threat modeling framework and OWASP Non-Human Identity Top 10 both reinforce the need for explicit ownership, least privilege, and continuous review.

These controls tend to break down when one shared service identity is reused across many workflows because no single owner can reliably explain or revoke its full blast radius.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance clean ownership against the realities of shared platforms, outsourced operations, and fast-changing agent pipelines. That tradeoff matters most when a single identity supports multiple teams or when an AI agent can assemble new tool chains without a code change.

There is no universal standard for this yet, but current guidance suggests three edge cases need special handling. First, shared platform identities need an explicit steward and a written service boundary, or drift becomes everyone’s problem and no one’s responsibility. Second, autonomous agents that inherit permissions from upstream systems need the upstream owner to remain accountable for the delegated scope, even if the agent is operated by a different team. Third, emergency break-glass access should have a separate approver from the routine business owner, otherwise temporary access often becomes permanent in practice.

NHIMG research on Salesloft OAuth token breach shows how quickly delegated access can spread when scope is not continuously governed. For threat-informed oversight, the NIST AI Risk Management Framework remains useful for assigning responsibility, while the MITRE ATLAS adversarial AI threat matrix helps teams think through how attackers exploit over-entitled machine identities.

Where the answer gets messy is in platform teams that administer identities for many products, because accountability must still point to one accountable business owner per identity, even when the operational work is shared.

Related resources from NHI Mgmt Group

• Who is accountable when a service account or AI agent keeps access after offboarding?
• What is the difference between AI agent access and ordinary service account access?
• Who is accountable when an AI agent causes a clinical access problem?
• Who should own revocation for AI agent and service account access?