Because they extend access beyond a single human user into tools that can read context, draft changes, and shape operational decisions. Even when the system is not autonomous, it can still widen the delegated access surface and weaken accountability if approval paths are unclear.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent-driven tool use expands delegated access and approval ambiguity. |
| CSA MAESTRO | M1 | MAESTRO addresses identity, authorization, and audit for agentic workflows. |
| NIST AI RMF | AI RMF governance is relevant to accountability in AI-assisted engineering. |
Assign owners, document approvals, and monitor assistant behavior across the workflow lifecycle.
