Who is accountable when an approved AI application keeps access after the original business need has changed?

Accountability should sit with the business owner of the integration, the identity or IAM team managing access, and the security team overseeing governance. Approval is not a one-time control. Organisations need clear ownership for review, revocation, and reauthorization so lingering access does not survive changes in purpose, staffing, or risk posture.

Why This Matters for Security Teams

When an approved AI application retains access after the business need changes, the failure is usually not the original approval. It is the absence of a durable ownership model for review, revocation, and reauthorization. That matters because access drift in NHIs and AI-linked credentials can turn a narrow business enablement into an open-ended control gap, especially when service accounts, API keys, or tokens outlive the workflow that justified them.

This is why NHI governance cannot stop at initial approval. The OWASP Non-Human Identity Top 10 treats credential lifecycle weaknesses as a primary risk area, and NHIMG research on Ultimate Guide to NHIs shows how quickly identity sprawl becomes an operational issue when ownership is unclear. The security team needs a revocation path, the IAM team needs control over the entitlement, and the business owner needs to confirm the use case still exists.

In practice, many security teams only discover lingering access after a workflow has changed, an employee has moved roles, or an incident review exposes a dormant integration still holding privilege.

How It Works in Practice

Accountability should be mapped to the lifecycle of the access, not just the moment of approval. The business owner is responsible for the business justification and for confirming when the purpose changes. The identity or IAM team is responsible for the mechanics of access provisioning, expiry, and revocation. The security team owns governance, exception handling, and evidence that access reviews are actually happening.

For AI applications and other NHIs, best practice is to treat approval as a time-bound authorization with periodic revalidation. That means every privileged token, API key, certificate, or delegated trust relationship should have an owner, a purpose, a TTL, and a defined review date. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports ongoing access review and least privilege, while NHIMG’s 52 NHI Breaches Analysis illustrates how unmanaged non-human access repeatedly becomes a breach enabler.

• Bind every approved AI integration to a named business owner and technical custodian.
• Set expiry on access by default, then renew only after documented business validation.
• Separate approval authority from revocation authority so no single team can ignore drift.
• Log the original purpose and the current purpose, then compare them at review time.
• Revoke access automatically when the workflow, vendor, or data handling model changes.

The practical control is not a one-time sign-off; it is an operating rhythm of review, evidence, and automated removal when the use case no longer exists. These controls tend to break down in large integration estates where service accounts are shared across multiple workflows because ownership becomes ambiguous and revocation is politically difficult.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance faster delivery against stronger revocation discipline. That tradeoff becomes more visible when AI applications are embedded in customer-facing workflows, because a single access path may support several business functions with different owners and different risk appetites.

There is no universal standard for this yet, but current guidance suggests that the accountable party should shift with the control point. If the access is provisioned through a platform team, that team is accountable for technical enforcement, but not for deciding whether the business purpose still exists. If the app is vendor-managed, the internal sponsor still owns the approval decision and the review cadence. For high-risk integrations, the security team may require step-up review, but it should not become the de facto business owner.

Edge cases also arise when an AI agent chains tools, inherits delegated scopes, or reuses a long-lived secret across multiple services. In those cases, access reviews must examine the whole trust chain, not just the visible application. The State of Secrets in AppSec is a useful reminder that fragmented secrets management makes this harder, especially when access lives in several systems at once. Where lifecycle evidence is weak, organisations should assume the approval has expired even if the credential has not.

Related resources from NHI Mgmt Group

• Who is accountable when an approved AI tool keeps access after it should have been offboarded?
• Who is accountable when an application keeps access after a user leaves the directory?
• Who is accountable when a service account or AI agent keeps access after offboarding?
• Who is accountable when a web application leaks sensitive files or bypasses access controls?