Because most NHIs are created, used, and remediated inside engineering workflows. Security can define the policy, but engineers understand the runtime impact, dependency chain, and safe timing for change. Shared responsibility reduces friction and lowers the risk of breaking production while improving control coverage.
Why This Matters for Security Teams
NHI programmes fail when they are treated as a security-only programme, because the identities themselves are created, changed, and retired inside delivery pipelines, application code, and infrastructure automation. Security can define the control objective, but engineering owns the runtime details that determine whether a change is safe. That matters for service accounts, API keys, certificates, and machine tokens, but it becomes even more important when teams are dealing with autonomous Non-Human Identities that can call tools, chain actions, and act on goals rather than fixed scripts.
Practitioner guidance is consistent on one point: governance only works when it is operationally usable. The NIST Cybersecurity Framework 2.0 emphasises governance, risk ownership, and continuous improvement, which maps directly to shared accountability between security and engineering. NHIMG research also shows why this matters: in the State of Non-Human Identity Security, only 1.5 out of 10 organisations are highly confident in securing NHIs, a sign that policy without implementation ownership leaves a gap.
In practice, many security teams encounter NHI failures only after an expired secret, over-privileged service account, or broken deployment has already hit production, rather than through intentional control design.
How It Works in Practice
The most effective model is shared responsibility with clear division of labour. Security defines the control outcomes, such as least privilege, rotation, logging, JIT access, and separation of duties. Engineering then translates those outcomes into deployment-safe workflows, CI/CD guardrails, and runtime controls that fit the service architecture. That is especially important for agentic systems, where static RBAC often fails because an AI agent is not following one pre-defined path. Its access needs can vary by task, tool, and context, so intent-based authorisation is becoming the practical alternative.
For autonomous workloads, current guidance suggests moving toward workload identity and short-lived credentials. Use cryptographic workload identity to prove what the agent is, then issue JIT credentials or ephemeral secrets only for the task at hand. Pair that with policy evaluation at request time so access decisions reflect current context, not yesterday’s role assignment. This is where engineering is essential: it understands retry behaviour, dependency chains, token TTL, and the blast radius of revocation during active jobs.
- Security sets the policy standard for ZSP, logging, and rotation.
- Engineering implements those controls in pipelines, orchestration, and application code.
- Both teams define rollback steps so revocation does not break production.
- Both teams validate that secrets do not persist in code, config, or CI/CD artefacts.
NHIMG research shows why this joint model matters: 71% of NHIs are not rotated within recommended time frames, and 96% of organisations store secrets outside secrets managers in vulnerable locations. For deeper background, see Top 10 NHI Issues and the 52 NHI Breaches Analysis. These controls tend to break down when ownership is split across platform, app, and security teams without a single engineering-led change path.
Common Variations and Edge Cases
Tighter control often increases delivery overhead, so organisations have to balance reduced risk against slower change velocity. That tradeoff is real, especially in high-churn environments where secrets rotate frequently, workloads scale dynamically, or agents operate across multiple tools and services. Best practice is evolving, but there is no universal standard for this yet; many teams are still deciding how far to push JIT access, how much automation to trust, and where manual approval remains necessary.
Some environments need different treatment. Legacy systems may not support short-lived tokens cleanly, so compensating controls like vault-mediated access, proxy authentication, or constrained PAM workflows may be the realistic bridge. Multi-cloud and hybrid estates often require separate engineering patterns for each runtime, which is why one policy document is not enough. For autonomous AI agents, the same issue becomes sharper: if the agent can initiate new tool calls mid-task, access policy has to be evaluated continuously, not just at login.
That is why engineering involvement is not a nice-to-have. It is the only way to make control design survive the realities of release cadence, dependency management, and failure recovery. Security still owns oversight, but engineering owns whether the safeguard actually fits the system. For implementation context, Cisco DevHub NHI breach is a useful reminder that identity failures can emerge through ordinary operational shortcuts, not just exotic attacks. These controls tend to break down in heavily automated platforms where revocation, token exchange, and rollback all happen at machine speed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Rotation and lifecycle control are central when engineering owns secret handling. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access aligns with shared security and engineering responsibility. |
| NIST AI RMF | GOVERN | Autonomous agent oversight needs accountable governance, not security review alone. |
Assign clear ownership for agent behaviour, approval, monitoring, and remediation before deployment.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- Why is proactive secret scanning important for NHI security?
- How should security teams make NHI best practices usable across the business?
- What is the difference between role-based access and API key governance for NHI security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
