AI security risks are now a software delivery problem

At a glance

What this is: AI security risks are now embedded in software delivery workflows, with Xygeni arguing that code, dependencies, secrets, pipelines, and agents all need SDLC-level controls.

Why it matters: DevSecOps teams need to treat AI-assisted development as a governance problem as much as a tooling problem, because the attack surface expands wherever AI can generate or modify software artefacts.

Context

AI security risks are no longer confined to model output or prompt safety. Once AI tools start generating code, suggesting dependencies, editing workflows, or handling secrets, the security problem moves into the software delivery chain itself and inherits the control gaps of the SDLC.

That shift matters for IAM, PAM, and NHI governance because AI assistants and agents can create, use, or expose credentials and access paths at machine speed. The article is essentially about governance failure modes in development workflows, which is typical of modern AI-assisted delivery rather than an edge case.

Key questions

Q: What breaks when AI-generated code is reviewed without security gates?

A: What breaks is the assumption that a clean-looking diff is a safe diff. AI-generated code can hide unsafe defaults, dependency issues, and weak validation that basic review misses. Without CI-enforced tests and security checks, the merge process becomes a distribution channel for defects rather than a control point.

Q: Why do AI-assisted development workflows increase secret exposure risk?

A: They increase exposure because developers move faster, paste more context into prompts, and review output for function before security. That combination makes secrets more likely to appear in code, logs, or old commits, and those secrets can remain valid long after discovery.

Q: How should security teams secure agentic AI systems that can call tools and make independent decisions?

A: Security teams should treat agentic AI as a runtime identity and policy problem, not just a prompt filtering problem. The control set should include least privilege, authenticated tool access, isolation for code execution, detailed logging, and policy checks before actions reach databases, files, or external tools. Without those controls, an agent can turn a helpful workflow into an unauthorized access path.

Q: What is the difference between AI model security and AI governance?

A: Model security focuses on protecting the model itself from attack or misuse. AI governance is broader and asks who can use the system, what it can access, how policy is applied, and what evidence exists after the interaction. In regulated environments, governance must include runtime enforcement and auditability, not just technical hardening.

Technical breakdown

AI-generated code vulnerabilities in the SDLC

AI coding assistants often produce syntactically valid code that still fails on authorization, input validation, or session handling. The risk is not that the model “creates malware” in the abstract, but that it normalises insecure patterns from public code and inserts them at the point where developers trust output most. In practice, the model can generate SQL injection paths, weak authentication logic, or unsafe deserialization that looks production-ready until tested. Security therefore has to evaluate generated code as untrusted input, not as a shortcut around review. Real controls need to sit inside IDE, commit, and CI checks, where the code first becomes part of the delivery chain.

Practical implication: Treat AI-generated code as untrusted until SAST, policy checks, and human review all pass.

Secrets exposure and machine credential leakage

AI-assisted workflows create more places for secrets to leak because developers paste context into prompts, accept generated code, and move rapidly between tools. That means tokens, API keys, and credentials can surface in prompt history, repository commits, CI logs, IaC files, or container artefacts. Once a secret lands in version control or build telemetry, the exposure window often outlives the original task. This is an NHI governance problem as much as a DevSecOps problem because machine credentials are being copied, reused, and preserved across systems that were never designed for ephemeral disclosure. Detection without revocation leaves the exposed secret usable.

Practical implication: Scan prompts, commits, history, and pipeline logs for secrets, then revoke exposed credentials automatically.

Agentic tool use and excessive agency

Agentic AI changes the control problem because the system does not just recommend actions, it can execute them. If an agent can call APIs, edit files, trigger builds, or open pull requests, then prompt injection or a bad instruction can become an operational security event. The central issue is excessive agency: permissions and tool access exceed the task’s legitimate scope. That makes the boundary between helper and actor much thinner than in conventional automation. Governance has to focus on tool permissions, execution scope, and observable behaviour, because once an agent can act autonomously, mistakes propagate faster than manual review can catch them.

Practical implication: Constrain agent permissions to task scope and monitor every tool call, workflow change, and API action.

Threat narrative

Attacker objective: The attacker’s objective is to turn AI-assisted delivery speed into a larger compromise surface, using code, secrets, and pipeline trust to gain durable access or alter shipped software.

1. Entry begins when AI-generated code, dependency suggestions, or external content enters the SDLC with insufficient review or validation.
2. Credential or secret access follows when prompts, generated files, logs, or pipeline artefacts expose machine credentials and other sensitive tokens.
3. Escalation occurs when an agent or workflow with excessive agency uses those credentials, tool permissions, or build access to modify code or deployment logic.
4. Impact is compromise of source integrity, credential reuse, malicious dependency installation, or unsafe deployment activity across the delivery chain.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security has become an SDLC governance problem, not just a model-risk problem. Once AI writes code, suggests dependencies, or touches pipelines, the control surface moves from policy statements to delivery workflows. The article shows that security failures now emerge where development speed meets weak validation, which means AppSec, DevSecOps, and identity governance can no longer be separated. Practitioners should manage AI risk at the point of code and credential issuance.

Secrets exposure is the clearest place where NHI governance and AI-assisted development overlap. The article’s secret-management discussion is really about machine credentials moving through prompts, commits, logs, and build artefacts without lifecycle control. That is an OWASP-NHI problem in practice because leakage, reuse, and delayed revocation are what turn convenience into compromise. Practitioners should treat exposed tokens as governance failures, not just hygiene issues.

Agentic AI introduces a blast-radius problem that traditional developer tooling was not designed to contain. When a system can edit files, call APIs, or change workflows, the issue is no longer whether the model is accurate enough. The issue is whether permissions, scope, and observability are tight enough to prevent accidental or malicious execution. Practitioners should govern agents as privileged software actors, not as chat interfaces.

AI-generated dependency risk is now part of software supply chain assurance. The article’s package and dependency examples show how hallucinated or malicious recommendations can become real artefacts in the build path. That connects AI delivery directly to supply-chain assurance, where provenance, policy enforcement, and package vetting matter more than developer intent. Practitioners should make dependency trust a gated control, not a recommendation.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs

What this signals

AI security now behaves like a delivery-chain control problem. The practical lesson for readers is that model policy alone will not reduce exposure if code generation, dependency choice, secrets handling, and pipeline automation remain weak. Teams should expect AI adoption to stress the same control points that already fail under ordinary DevSecOps pressure, only faster.

Secrets governance is the named concept that matters here: machine credentials now move through prompts, logs, commits, and build artefacts faster than most offboarding or revocation processes can track. That creates a lifecycle gap, not just a detection gap, and it is the kind of problem that needs controls at issuance, not just after exposure.

As AI features spread into developer tooling, the right response is to tighten control where decisions are made, not to add another review layer after the fact. Security leaders should watch for more incidents that start as convenience features and end as software supply-chain or credential events.

For practitioners

• Implement IDE-level security feedback for AI-generated code Surface SAST, secure coding rules, and authorization checks while developers are still reviewing AI output, before the code reaches commit or pull request state.
• Scan and revoke exposed machine credentials across the delivery chain Extend secrets detection beyond source files into prompts, repositories, CI logs, IaC, and containers, then trigger revocation as soon as a token or key is found.
• Gate dependency acceptance before build and deployment Block unpinned, suspicious, or AI-suggested packages until SCA, malware checks, and policy controls validate the dependency and its installation behaviour.
• Constrain agent actions to explicit task scope Limit shell access, API permissions, workflow modification rights, and file writes to the minimum required for the task, with logging on every tool invocation.
• Monitor workflow changes as security events Treat pull request automation, CI configuration edits, and deployment-script changes as high-signal events that require review when AI or agents are involved.

Key takeaways

• AI-assisted development changes the security problem from isolated model behaviour to the full software delivery chain.
• The strongest exposure points are code quality, dependency trust, secrets handling, and agent permissions, because those are the places AI can act on real systems.
• Security teams need controls inside the SDLC, not only model governance, if they want to keep AI adoption from increasing blast radius.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Secrets Exposure: Secrets exposure is the accidental or uncontrolled disclosure of credentials such as API keys, tokens, certificates, and service passwords. In NHI programs, it matters because a leaked secret often behaves like a live identity, creating immediate access risk until it is revoked or rotated.
• Software Delivery Pipeline: A software delivery pipeline is the chain of systems used to build, test, and deploy code into production. It includes repositories, automation workflows, build tools, and deployment services. Because these systems hold high trust, they become attractive targets when access controls are weak or poorly inventoried.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It helps practitioners connect identity governance to the operational realities that AI-assisted delivery creates.