Because the account can authorise real execution, not just access content. When an AI system can read repositories, modify code, and open pull requests, the identity protecting it becomes part of the software supply chain. That changes the risk from data exposure to code and workflow compromise.
Why This Matters for Security Teams
AI-assisted development workflows are not just another SaaS workload. They can read source code, generate patches, create pull requests, invoke CI/CD jobs, and sometimes reach signing or deployment tools. That means the identity behind the workflow is part of the software supply chain, not merely a user account with read access. NIST guidance on least privilege and system accounts in NIST SP 800-53 Rev 5 Security and Privacy Controls supports that distinction.
The practical risk is that one over-permissioned token can turn a helpful coding assistant into an execution path for code tampering, secret extraction, or unauthorized workflow changes. NHIMG research on Ultimate Guide to NHIs shows why this matters at scale: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges. AI-assisted development adds speed and reach to the same identity problem.
In practice, many security teams encounter the failure only after an assistant has already pushed unsafe code, triggered an unwanted build, or exposed a token through automated tooling.
How It Works in Practice
Normal SaaS identity controls assume a human user with stable intent and predictable access patterns. AI-assisted development breaks that model because the agent can chain actions dynamically, choose tools on the fly, and continue operating after the original human request is gone. The emerging pattern is to treat the assistant as a workload identity with explicit runtime authorization, not as a standing user account.
That usually means combining short-lived credentials, policy evaluation at request time, and scoped access to repositories and pipelines. Current guidance suggests three layers:
- Use workload identity for the agent itself, so the system proves what it is before it receives access.
- Issue just-in-time credentials per task, with short TTLs and automatic revocation after the workflow completes.
- Evaluate permissions dynamically based on context, such as repository, branch, ticket, environment, and requested action.
This is why identity controls need to be stronger than in standard SaaS apps. A human SaaS user may only view or edit data. An AI developer tool may also commit code, open pull requests, call package registries, or promote artifacts downstream. If a static token is reused across tasks, the blast radius includes source control, build systems, and deployment paths. NHIMG’s Top 10 NHI Issues and the 52 NHI Breaches Analysis both show how quickly overprivileged machine identities become incident paths when they are not tightly governed.
Best practice is evolving toward policy-as-code and fine-grained approvals for high-risk actions, especially where an agent can touch secrets, production branches, or signing keys. These controls tend to break down when a workflow uses shared runner credentials across multiple repositories because one compromise inherits too much ambient authority.
Common Variations and Edge Cases
Tighter identity control often increases workflow friction, requiring organisations to balance developer speed against the risk of unintended execution. That tradeoff is especially visible in local development assistants, autonomous code review agents, and multi-agent CI pipelines.
There is no universal standard for this yet, but current guidance suggests different controls for different trust levels. A low-risk assistant that only suggests code may need read-only repository access, while an agent that opens pull requests or triggers builds should use stronger approval gates, short-lived credentials, and branch-specific policy checks. For production-adjacent workflows, many teams also separate the identity used for code analysis from the identity used for deployment.
Two edge cases matter most. First, if an assistant shares credentials with human developers or build runners, attribution becomes weak and revocation becomes unreliable. Second, if the agent can call external tools or SaaS APIs, the identity problem extends beyond the repo into third-party integrations. The Salesloft OAuth token breach is a useful reminder that a single token can expose many downstream systems. In environments with highly automated pipelines and broad connector sprawl, these controls often break down because the agent’s access path is distributed across too many systems to govern consistently.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic workflows need runtime auth and bounded tool use. |
| CSA MAESTRO | AI-03 | Covers agent identity, orchestration, and control-plane risk. |
| NIST AI RMF | AI RMF addresses governance for autonomous system behaviour. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived secrets and rotation are central to NHI protection. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management apply to build identities. |
Separate agent identity from human identity and govern each tool invocation with policy checks.
