Who should be accountable for NHI governance when applications, pipelines, and AI agents all use credentials?

Accountability should sit with the security and identity function, but enforcement must be shared with application, platform, and cloud owners. Each system that creates or uses a non-human identity needs an owner, an access policy, and a revocation process. Clear accountability prevents credentials from becoming permanent exceptions that nobody can safely retire.

Why This Matters for Security Teams

When applications, pipelines, and AI agents all use credentials, the real risk is not just sprawl. It is ambiguity. If no single function owns NHI governance, secrets linger after teams change, pipelines keep inherited permissions, and agents accumulate access that nobody can confidently review. That creates a condition where revocation becomes optional in practice, even when policy says otherwise.

NHIMG research on the The State of Non-Human Identity Security shows why this matters: only 1.5 out of 10 organisations are highly confident in securing NHIs, while 45% cite lack of credential rotation as the top cause of NHI-related attacks. Security teams are often asked to “own” the problem, but without application and platform accountability, they can only set standards, not remove exposure. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point to shared control ownership, not shared ambiguity.

In practice, many security teams encounter irreversible credential sprawl only after a pipeline compromise, an agent misuse event, or a failed audit has already exposed the gap.

How It Works in Practice

Accountability should be assigned at three layers: a central security and identity function defines policy, each system owner accepts operational responsibility, and platform teams enforce the technical controls that make revocation, rotation, and logging real. This is the practical model behind NHI governance. It aligns with the control intent in the Top 10 NHI Issues and the implementation guidance in the Guide to the Secret Sprawl Challenge, where the recurring failure is not just weak secrets hygiene but unclear ownership of the lifecycle.

In mature environments, that ownership is translated into concrete obligations:

• Application owners approve why a credential exists and what task it supports.
• Platform or cloud owners implement issuance, TTL limits, storage, and revocation hooks.
• Security and identity teams define minimum policy, exception handling, and review cadence.
• AI agent owners validate tool scope, runtime context, and whether the agent should receive JIT access at all.

For agentic systems, the model should move beyond static role assignment and toward runtime authorisation. The NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework both support the idea that autonomous workloads need context-aware guardrails, not just pre-approved entitlements. Where possible, use workload identity, short-lived tokens, and automated revocation rather than shared secrets. These controls tend to break down when teams rely on long-lived service accounts in highly distributed CI/CD and multi-agent environments because ownership becomes fragmented across too many operational handoffs.

Common Variations and Edge Cases

Tighter credential governance often increases delivery overhead, requiring organisations to balance speed against the cost of review, revocation, and exception management. That tradeoff is especially visible in DevOps pipelines and agentic AI systems, where teams may prefer static credentials for convenience, even though current guidance suggests ephemeral access is safer.

There is no universal standard for accountability mapping yet, but a useful rule is that the team closest to the business outcome owns the risk, while the security function owns the policy. For example, a data platform team should own secrets used by its jobs; an AI product team should own the agent’s tool access; and a cloud team should own the technical controls that make revocation possible. Central security should not be the only approver, because that creates a bottleneck without creating real accountability.

This becomes more complex when third-party integrations, OAuth-connected tools, or multi-agent orchestrators are involved. NHIMG’s OWASP Agentic Applications Top 10 and the Analysis of Claude Code Security both reinforce that autonomous systems can chain tools and expand scope faster than human review cycles can keep up. For that reason, governance should be assigned to named owners, but enforced through policy-as-code and continuous monitoring rather than quarterly attestations alone.

Related resources from NHI Mgmt Group

• How should security teams use enterprise password management to reduce credential sprawl across applications, devices, and AI agents?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• How should security teams use IAST and RASP in NHI governance?