Why do AI-assisted engineering workflows complicate identity governance?

Why This Matters for Security Teams

AI-assisted engineering workflows do not just speed up coding. They introduce a shared working surface where a human, an assistant, source control, CI/CD, package registries, and cloud APIs all touch the same change path. That complicates identity governance because the question is no longer only “who signed in?” but “which identity actually exercised authority at each step?” Current guidance suggests treating those workflows as delegated access chains, not simple user sessions, which is why least privilege and approval logging become harder to enforce consistently. The challenge is visible in NHI programs too: NHIMG research shows only 1.5 out of 10 organisations are highly confident in securing NHIs, and the confidence gap tends to widen when access is mediated by tools and automation rather than direct human actions, as discussed in the State of Non-Human Identity Security. NIST’s Cybersecurity Framework 2.0 remains useful here, but it does not by itself resolve the delegation problem. In practice, many security teams encounter unclear accountability only after an assistant has already generated, staged, or merged changes that were never intended to carry broad standing access.

How It Works in Practice

The core governance issue is that AI-assisted engineering often borrows human authority while operating through machine identities. A developer may approve a request, but the assistant may read repos, query tickets, propose code, open pull requests, invoke build systems, or call deployment APIs. That means the effective identity boundary shifts from the person to the workflow, and the controls need to follow that shift. The best practice is evolving toward context-aware authorization, where access is decided at request time based on task, environment, repository sensitivity, and approval state rather than a flat role assignment. Practitioners usually need three layers of control:

• Workload identity for the assistant and its tools, so the system proves what it is using cryptographic identity rather than shared secrets.
• JIT credentials and short-lived tokens, so access exists only for the specific task and is revoked on completion.
• Policy-as-code for runtime checks, so decisions can reflect the exact action being attempted instead of a prebuilt role matrix.

For identity primitives, many teams look to SPIFFE-style workload identity and OIDC-based federation for machine-to-machine trust, then pair that with strong approvals and audit trails. The governance lesson aligns with NHIMG’s Lifecycle Processes for Managing NHIs and its Regulatory and Audit Perspectives, because workflow identity must be provisioned, monitored, and retired just like any other non-human identity. These controls tend to break down when assistants are allowed to retain standing access across multiple repositories or environments, because the delegated context outlives the task that justified it.

Common Variations and Edge Cases

Tighter workflow control often increases engineering friction, requiring organisations to balance developer speed against auditability and blast-radius reduction. That tradeoff is especially visible in low-risk internal code assistance versus higher-risk paths such as production deployment, secret retrieval, or infrastructure changes. There is no universal standard for this yet, but current guidance suggests applying stricter checks where the assistant can influence runtime systems, release pipelines, or privileged configuration. A few edge cases matter:

• Read-only assistants still create identity risk if they can access sensitive context, because data exposure can occur before any code is changed.
• Multi-agent pipelines can obscure attribution when one agent drafts code and another submits or deploys it, so every step needs separate identity and logging.
• Shared service accounts are a poor fit for AI-assisted workflows because they erase actor-level accountability and make revocation blunt.
• Human approval does not equal human execution, so approval alone should not grant persistent credentials.

NHIMG’s Top 10 NHI Issues is a useful reminder that over-privilege and weak rotation remain recurring failure modes, even before AI enters the picture. For governance teams, the practical rule is to treat every assistant as a bounded workload with explicit scope, not as an extension of the developer’s own account. That becomes most difficult in fast-moving environments where teams optimize for shipping velocity first and discover identity drift only after access sprawl has already accumulated.

Related resources from NHI Mgmt Group

• Why do AI agents make non-human identity governance harder?
• What is the difference between human identity governance and AI agent governance?
• Should organisations let AI handle permission changes in identity workflows?
• How do AI-assisted coding workflows differ from ordinary developer automation?