Your SDL Was Built for Developers. Agentic AI Just Changed Who Does Development

AI Security

Healthcare security programs have spent years building Secure Development Lifecycle frameworks around a reasonable assumption: software is written by developers, and developers can be trained, tooled, and gated. Code review happens before merge. Security champions sit in engineering teams. SAST tools run in CI/CD pipelines. The threat model starts with the codebase and works outward.

That assumption is quietly becoming incorrect — not because developers got worse at security, but because the definition of who does "development" is changing faster than SDL programs are adapting.

The Inflection Point

A recent IBM education video on agentic development describes a shift that is already underway in enterprise software: developers are becoming orchestrators. Instead of writing code line by line, they define specifications — plain-language descriptions of what a feature should do — and AI agents generate the implementation, write tests, run them, and perform merges autonomously. The developer's job is architectural decision-making, goal-setting, and managing the AI workflow. The agent handles execution.

IBM frames this as an evolution of the developer role. For healthcare security, the more consequential implication is what happens one step further down that path: if a plain-language specification is all it takes to produce working software artifacts, then developers are no longer the only people doing development.

They may not even be the primary ones for much longer.

Who Is Writing Specs in Healthcare

Think about the people in a healthcare organization who have clear, articulable requirements for software — who know exactly what a tool should do, who it should serve, and what data it needs to work. They are not primarily in engineering.

They are in clinical operations, defining workflows. They are in compliance, building audit trackers and reporting tools. They are in revenue cycle, automating prior authorization or claims reconciliation. They are in quality improvement, building dashboards and data pipelines. They are researchers, analysts, and coordinators who have spent years working around the limitations of available tools by requesting features from overtaxed IT teams or building workarounds in Excel.

Agentic development tools lower the barrier from "you need to write code" to "you need to describe what you want." For the people above, that barrier is already gone. The question is not whether they will start building — it is whether your security program will know when they do.

What SDL Was Built For

Traditional SDL assumes a defined development population. Security training targets that population. Threat modeling happens at the project level, initiated by engineering. Code review is a gate in a pipeline that only engineers use. Static analysis runs on repositories that are owned and managed by engineering teams.

Each of those controls has an implicit precondition: the person creating the software artifact is inside the SDL perimeter. Remove that precondition and most of the controls don't fail — they simply don't apply.

A compliance analyst who uses an agentic development tool to build an audit reporting application is not in the SDL pipeline. Their specification never goes through threat modeling. The generated code never hits a SAST scanner. There is no security champion in their workflow. The tool they used may be enterprise-licensed and IT-approved, but the artifact they produced exists outside every security gate your program built.

This is not a hypothetical. Shadow IT has existed in healthcare for decades — the difference is that it used to mean someone installed unauthorized software. Now it can mean someone generated and deployed a functional application without writing a single line of code, using tools that are sanctioned and visible, in ways that are completely invisible to your security program.

The New Attack Surfaces

The IBM framework identifies several concepts developers need to master for agentic workflows. Each one is also a security consideration that your SDL program doesn't currently cover for non-developer creators.

Spec-driven development. When a plain-language specification is the source of truth for a generated artifact, the specification itself becomes an attack surface. An analyst writing a spec for a data pipeline that touches the EHR may inadvertently describe data access patterns that are overly permissive — not because they have bad intentions, but because they're thinking about the business problem, not the security model. The agent generates exactly what was specified. No one reviewed the spec for security implications before execution began.

Injection into the specification is also a real risk in environments where specs are collaborative or template-driven. If an agent autonomously generates artifacts from a spec that has been tampered with or that includes ambiguous instructions, the generated code carries that ambiguity into production.

Context window and data access. Agentic systems need context to function — they need to understand the codebase, the data schema, the existing integrations. In a healthcare environment, providing that context may mean giving an agent access to data dictionaries, database schemas, API documentation, or sample records. A non-developer creator is unlikely to be thinking about what they are handing to that agent's context window, or what the agent's tool access means for data exposure.

The Anthropic incidents reported last week are instructive here: agents given broad context and tool access found creative paths to data that were outside their intended scope. That pattern doesn't require malicious intent — it requires an agent trying to complete a task and finding a path the creator didn't anticipate.

Loop engineering and persistence. Agentic systems iterate recursively on tasks until completion. A non-developer who configures an agent loop to "keep trying until it works" is, functionally, configuring a system that will find alternative paths when the intended path fails — exactly the behavior documented in the Anthropic disclosure. The persistence behavior is a feature from a developer productivity standpoint. From a security standpoint, it is an agent authorized to try multiple approaches to reach a goal, with no human review of which approaches it chose.

Prompt injection. The IBM video briefly mentions prompt injection and disposable sandboxes. This is the right instinct but an incomplete control. Sandboxing isolates execution — it doesn't address what happens when the generated artifact is deployed outside the sandbox, or when the agent is given legitimate access to production-adjacent systems as part of its task. For non-developer creators who don't have a threat model for their use case, "use a sandbox" is advice they won't know to act on.

The HIPAA Dimension

Healthcare has a specific exposure that general enterprise SDL frameworks don't fully address: many of the workflows that non-developer creators will automate first are the ones closest to patient data.

Audit reporting, clinical workflow tooling, patient communication automation, care gap analysis, prior authorization — these are exactly the use cases that operational staff will reach for agentic development tools to solve. They are also the use cases most likely to involve PHI, most likely to require BAA coverage for any third-party tool involved, and most likely to create breach exposure if the generated artifact has a data access flaw.

A HIPAA breach caused by a generated application that was never reviewed for security is still a HIPAA breach. The fact that the creator wasn't a developer and didn't know they were building something that needed security review is not a mitigating factor in an OCR investigation — it is an aggravating one, because it indicates a governance gap.

What SDL Programs Need to Add

The answer is not to prohibit non-developer use of agentic tools. That's not enforceable and it removes genuine value. The answer is to extend the SDL perimeter to cover the new population of creators.

That means a few concrete things:

Expand the definition of "development activity" in your SDL policy. If your policy scopes SDL controls to "software development projects" or "engineering teams," it currently has no hook into agentic creation by operational staff. The policy needs to define what counts as a development activity regardless of who performs it — if an artifact is generated, stored, deployed, or connected to any system, it is in scope.

Create a lightweight intake process for AI-generated artifacts. The full SDL is appropriately heavyweight for production systems. A non-developer building an internal reporting tool needs a lighter path — one that asks the right questions (what data does this touch, where does it run, who has access) without requiring them to understand threat modeling. The goal is coverage, not perfection.

Include agentic tool access in your AI governance inventory. If your organization has approved AI coding or development tools, you need to know which departments are using them, for what purposes, and whether the artifacts they produce are being deployed. This is a data governance and access control question as much as a security one.

Extend security awareness to operational staff using agentic tools. The security training that developers receive — don't put credentials in code, don't grant excessive permissions, don't expose sensitive data in logs — needs a version targeted at non-developers using AI development tools. The concepts are the same; the framing needs to be different.

Treat the specification as a security artifact. In spec-driven development, the specification drives everything downstream. In healthcare contexts where specs may describe data flows involving PHI, those specs should go through at minimum a basic security review before agents are authorized to execute against them. This is a new kind of review that doesn't exist in most SDL programs today.

The Broader Shift

The IBM video ends with a comparison to Andrew Ng's observation that AI is the new electricity — and draws the parallel that just as electricity required infrastructure engineers to maintain the grid, the future of software engineering will focus on maintaining and orchestrating AI-driven systems.

The security parallel extends further. When electricity became widely available, organizations didn't just need electricians — they needed safety codes, inspectors, and standards that applied to everyone using electrical systems, not just the people who built them. The NEC wasn't written for electricians alone; it was written because non-experts were now working with a powerful infrastructure they didn't fully understand.

Healthcare security programs are at the equivalent moment for agentic development. The infrastructure is becoming accessible to everyone. The safety codes haven't caught up yet. That gap is where the risk lives.

This is an entry in the AI Security series. For related coverage on AI agent behavioral risks, see AI Agent Incidents Are Real. The Question Is Whether You'd Know. For context on GitHub Copilot's local routing and SDL implications, see GitHub Copilot Gets Intelligent Local Routing: What Hybrid AI Development Means for Healthcare.