AI security risks are now a software delivery problem

At a glance

What this is: This is an analysis of how AI security risks now surface inside the SDLC, especially through generated code, dependency choices, secrets exposure, and agentic workflows.

Why it matters: It matters because DevSecOps and IAM teams need controls that govern tool use, secrets, and access boundaries across human, NHI, and agent-driven delivery paths.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 17 minutes and as quickly as 9 minutes

👉 Read Xygeni's analysis of AI security risks across the software delivery chain

Context

AI security risks are no longer confined to model behaviour or data privacy. In software delivery, they now show up when AI tools generate code, recommend dependencies, handle secrets, and trigger actions inside pipelines or connected services, which makes the SDLC part of the control plane.

For identity and access teams, the issue is not only code quality. AI-assisted workflows can create new NHI governance pressure around service accounts, API keys, tokens, and agent permissions, especially when automation is allowed to touch repositories, build systems, and cloud services without tight lifecycle control.

Key questions

Q: How should security teams govern AI experimentation without slowing delivery?

A: Use lane-based governance. Low-risk experiments belong in isolated sandboxes with minimal guardrails, while managed and critical workloads should inherit progressively stronger controls. The goal is to make experimentation safe by default, not to force every AI use case through production-grade approval gates before value is proven.

Q: Why do AI coding tools increase secrets risk?

A: AI coding tools increase secrets risk because they can accelerate the reuse of insecure patterns across repositories, test fixtures, and automation scripts. The issue is not the model inventing credentials, but the way generated code can spread bad defaults faster than human review can catch them.

Q: What breaks when AI agents are given broad standing access?

A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.

Q: Should organisations separate model governance from SDLC security?

A: No. Model governance matters, but the practical risk appears when AI touches code, dependencies, secrets, or pipelines. Those systems need their own guardrails because the attack path often starts in an engineering workflow and ends in production impact. Governance should join the model, the developer toolchain, and runtime controls.

Technical breakdown

AI-generated code as an attack surface

AI coding tools produce likely code patterns, not guaranteed secure implementations. That means they can generate vulnerable authentication logic, unsafe input handling, weak session controls, or missing authorization checks while still producing code that compiles and passes basic functional testing. The risk is not only bad output but also speed, because insecure patterns can spread quickly through pull requests and shared templates. This turns the IDE into a security control point, not just a productivity layer. Practical implication: shift secure coding feedback into the editor, then validate with SAST and policy checks before code reaches review.

Practical implication: move security feedback into the IDE and block insecure code before review.

Secrets exposure across prompts, logs, and generated files

AI-assisted development expands the places where secrets can leak. Developers may paste tokens into prompts for context, an AI model may reproduce credentials in generated code, or pipelines may print sensitive values into logs and artifacts. Once a secret enters Git history or build telemetry, its exposure window becomes much larger than the original mistake. This is a lifecycle problem, not a single-event error, because detection, revocation, and auditing must all work together. Practical implication: scan prompts, commits, logs, and artifacts, then automate revocation when a secret appears outside approved storage.

Practical implication: scan prompts, commits, logs, and artifacts, then revoke exposed secrets automatically.

Agentic tool use and excessive agency

Agentic AI becomes risky when the system can do more than suggest. If an agent can edit files, invoke APIs, trigger builds, or interact with cloud services, then a prompt injection or compromised connector can translate directly into unauthorized action. This is where excessive agency matters: permissions are no longer just about data access, but about operational reach. In identity terms, the agent behaves like an NHI with delegated authority, so permission scope and session boundaries become critical. Practical implication: confine agent permissions, log tool calls, and separate planning from execution wherever possible.

Practical implication: confine agent permissions and log every tool call and workflow change.

Threat narrative

Attacker objective: The attacker aims to turn AI-assisted development into a faster route to credential exposure, malicious code execution, or pipeline compromise.

1. Entry occurs when a malicious prompt, unsafe dependency, exposed secret, or injected instruction reaches an AI-assisted development workflow.
2. Escalation happens when the workflow accepts the model's output or the agent's tool action without enough policy, review, or access restriction.
3. Impact follows when insecure code, leaked credentials, or manipulated pipeline actions reach production systems or external services.

NHI Mgmt Group analysis

AI security debt is becoming SDLC debt: the real control failure is not that AI writes code, but that organisations let AI-generated output bypass the same policy gates they apply to human-written changes. That creates a faster version of long-standing AppSec weakness, where insecure patterns enter the estate at machine speed. Security leaders should treat AI-assisted development as a governance problem, not just a tooling problem.

Secrets governance is now a prompt-safety issue: when developers paste context into AI tools, the boundary between secure development and credential handling breaks down. Secrets are no longer only at risk in repositories and pipelines; they are also exposed through the interaction layer itself. Teams that do not govern prompt content, generated artifacts, and revocation workflows will keep chasing leaked credentials after the fact.

Agentic tool abuse: once an AI system can act on repositories, pipelines, or cloud services, it starts to resemble a privileged non-human identity that needs lifecycle controls, not just usage monitoring. The article's risk model lines up with NHI governance: approval scope, delegation boundaries, and revocation timing all matter. Practitioners should assume every tool-enabled agent needs explicit identity boundaries and task-scoped authority.

Supply chain risk is now recommendation-driven: AI can amplify dependency risk by suggesting vulnerable, hallucinated, or malicious packages with high confidence. That changes the control conversation from simple package allowlisting to policy enforcement at the point of suggestion and installation. The right governance model links dependency trust, provenance, and exploitability signals before code reaches the build stage.

Named concept, prompt-to-production exposure path: the article describes a control gap where a prompt, generated artifact, or agent action crosses directly into production-relevant change. That is the failure mode practitioners need to name, because it collapses the assumption that development tooling is lower risk than runtime systems. Teams should govern the path from prompt to production as one continuous attack surface.

What this signals

AI-assisted development is turning classic AppSec problems into governance problems because the control point has moved earlier in the workflow. The teams that succeed will treat prompts, generated code, and agent actions as governed inputs, not developer conveniences, and they will align that governance with the NIST AI Risk Management Framework.

Prompt-to-production exposure path: once a prompt can influence code, credentials, or deployment logic, the security boundary is no longer the repository. That creates a broader lifecycle obligation for IAM and PAM teams, especially where service accounts or API tokens are available to automation. The operational answer is to couple SDLC guardrails with identity-bound permissions and revocation visibility.

Developer experience and security operations now intersect more directly because the same AI workflow can create code, move secrets, and alter infrastructure. Organisations should expect more dependency on policy-as-code, secret telemetry, and agent auditing, and they should map those controls against the OWASP Top 10 for Agentic Applications 2026 where autonomous tool use is present.

For practitioners

• Move security checks into the IDE Give developers inline SAST, secure coding guidance, and policy feedback while accepting AI-generated code so insecure patterns are stopped before pull request submission.
• Treat prompts and generated files as secret-bearing inputs Scan prompts, commits, logs, artifacts, and container layers for credentials, then route any exposure event into automatic revocation and incident triage.
• Restrict AI agent permissions by task scope Assign agents only the minimum API and repository access needed for a single workflow, and require logging of every tool call, file edit, and external action.
• Enforce dependency policy before build time Block risky packages using SCA, malware detection, and reachability or exploitability signals before they can enter a CI/CD pipeline.
• Separate suggestion from execution for agentic workflows Require approval or human review for any agent action that changes code, workflow files, or deployment logic, especially when external input may have influenced the task.

Key takeaways

• AI security risk now sits inside the software delivery chain, not only at the model layer.
• Secrets, dependencies, and agent permissions are the main governance pressure points because they connect AI behaviour to real operational access.
• The most effective control model is SDLC-level policy enforcement, paired with identity-aware restrictions for any agent that can act on systems.

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.
• Prompt Path Exposure: A prompt path exposure happens when an AI system is coaxed into revealing or acting on information it should not have surfaced. The risk comes from the agent’s retrieval and response behaviour, which can turn normal access into an unauthorised disclosure channel when controls are too broad or poorly classified.
• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.
• 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.

What's in the full article

Xygeni's full blog post covers the operational detail this post intentionally leaves for the source:

• Examples of insecure AI-generated code patterns that AppSec teams should catch in review
• Specific secrets detection points across prompt history, commits, CI/CD logs, and container artefacts
• Pipeline and dependency guardrails that block risky AI-suggested packages before build and release
• Concrete controls for monitoring agent tool use and workflow changes in development environments

👉 Xygeni's full post covers code, secrets, dependency, and pipeline controls in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps security and identity practitioners align access control, lifecycle management, and governance across human and non-human estates.