How should security teams govern AI native engineering environments with mixed human and machine identities?

Why This Matters for Security Teams

AI native engineering environments combine people, service accounts, pipelines, and autonomous agents, so identity governance cannot stop at a quarterly review. The risk is not just excessive permissions, but the speed at which short-lived credentials, tool tokens, and machine-issued access can appear, be used, and vanish. Current guidance increasingly favors continuous discovery and runtime verification, because static RBAC snapshots do not capture goal-driven behaviour or tool chaining.

This is especially visible in incidents involving exposed credentials and agentic workflows. NHIMG research on the LLMjacking threat vector shows how quickly exposed cloud access can be abused, while the Top 10 NHI Issues highlights how missing lifecycle controls remain a persistent root cause. For control design, security teams should anchor their operating model in NIST Cybersecurity Framework 2.0 and the NIST AI governance guidance, then translate those principles into identity-centric controls. In practice, many security teams discover over-privileged machine access only after an agent has already chained tools and reached data it was never intended to touch.

How It Works in Practice

Security teams should treat every workload, agent, and human operator as a distinct identity with its own trust boundary. For human users, that means role design, session controls, and reviewable entitlements. For agents and machine workflows, the better pattern is workload identity plus just-in-time credential issuance, so the system proves what the entity is before issuing a short-lived token. That is where intent-based authorisation becomes important: the policy decision is made at request time, using context such as task, data sensitivity, environment, and approved tool chain.

Operationally, this looks like three layers working together. First, discovery maps all identities, including MCP-connected tools, CI/CD runners, ephemeral containers, and service accounts. Second, policy enforcement limits standing privilege and issues secrets only for the duration of the task. Third, logging and attestation create an evidence trail so that a later review can reconstruct who or what acted, with which token, and under what policy. That approach is consistent with NIST Cybersecurity Framework 2.0 and with the lifecycle and audit practices described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. It also aligns with the reality that a compromised AI workflow can produce human-like but machine-speed abuse, similar to what NHIMG describes in the DeepSeek breach analysis.

• Use workload identity for services and agents, not shared credentials.
• Issue ephemeral secrets with tight TTLs and automatic revocation on task completion.
• Evaluate policy at runtime, not only through pre-defined access groups.
• Correlate agent prompts, tool calls, and identity events in one audit stream.

These controls tend to break down in highly distributed environments with unmanaged tool sprawl, because the identity graph changes faster than inventory and review processes can keep up.

Common Variations and Edge Cases

Tighter runtime authorisation often increases operational overhead, so teams must balance friction against the blast-radius reduction they gain. There is no universal standard for this yet, especially for multi-agent systems and MCP-enabled tool chains, so current guidance suggests starting with the highest-risk workflows rather than trying to retrofit everything at once.

One common exception is legacy automation that cannot easily adopt workload identity. In those cases, shorten secret lifetime, isolate the account, and wrap it in compensating controls such as network segmentation, PAM, and aggressive alerting. Another edge case is vendor-hosted AI services, where teams may have visibility into outputs but limited visibility into upstream identity handling. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here, because auditability often becomes the deciding factor when controls are shared across business and platform teams. For implementation maturity, the JetBrains GitHub plugin token exposure case is a reminder that developer tooling can turn into an identity risk surface very quickly.

In agentic environments, NIST Cybersecurity Framework 2.0, NIST AI risk guidance, OWASP-AGENTIC, and CSA-MAESTRO are best used together: one for identity control, one for AI governance, and two for the failure modes unique to autonomous behaviour.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?