Pharma’s next security problem isn’t the code. It’s what the AI agent can touch.
Artificial intelligence is rapidly transforming how software is built across healthcare and life sciences (HCLS). From patient engagement apps to clinical trial management platforms, development teams are increasingly turning to AI coding assistants to write, review, and refine software faster than ever before.
For pharmaceutical and biotech organisations, the appeal is clear. Digital platforms supporting clinical research, regulatory data management, and real-world evidence (RWE) analytics are growing more complex each year. AI-powered development tools promise to accelerate delivery while helping teams keep pace with increasing data volumes and evolving regulatory requirements.
AI is also creating new opportunities to modernise the legacy systems that still underpin much of the industry’s infrastructure. Organisations can use AI to refactor older applications, translate legacy languages and architectures, and accelerate migrations to newer platforms. But modernisation does not eliminate security risk. A legacy application being refactored with AI may surface vulnerabilities that were never identified in the original code, while the AI system can introduce new ones along the way. Modernised code is not secure simply because it has been rewritten with modern tools.
As AI becomes embedded throughout development, innovation must be matched by equally sophisticated approaches to software security, particularly for organisations responsible for protecting protected health information (PHI) and sensitive research data.
The rise of AI-assisted development in pharma
AI coding assistants powered by large language models (LLMs) are becoming an increasingly common part of developer toolchains. These systems can generate code, identify bugs, propose fixes, and suggest architectural improvements within seconds. In healthcare and life sciences, they are already influencing systems such as:
- Clinical trial management platforms
- Electronic data capture systems
- Digital therapeutics applications
- Real-world evidence and analytics platforms
- Patient engagement and telehealth tools
For organisations running large-scale research programs, the ability to accelerate software development can deliver tangible benefits. Faster development cycles can mean quicker deployment of trial infrastructure, more agile analytics platforms for real-world evidence, and improved patient-facing digital services.
But faster code generation does not necessarily mean secure code. The Weather Report, a peer-reviewed study conducted by researcher Ilya Kabanov and commissioned by Checkmarx, found that frontier AI models generate functional code 83–95% of the time, but only 24–36% of that code is both functional and secure. Even with AI-assisted security techniques applied, the proportion reached only 47–56%. The findings illustrate a fundamental challenge: AI can produce working software without consistently producing secure software.
For pharma organisations, that gap matters. A vulnerability in software supporting clinical research, patient services, or sensitive business processes can have consequences far beyond an ordinary application defect.
Why protecting sensitive data is becoming more complex
Healthcare and life sciences organisations already operate within strict requirements for protecting patient and research data. In the United States, the Health Insurance Portability and Accountability Act (HIPAA) establishes requirements around PHI, while pharmaceutical companies face additional obligations when handling clinical trial data, patient registries, and research collaborations across jurisdictions, and that regulatory floor is rising quickly.
The EU AI Act’s penalty structure is now enforceable, with fines for the most serious violations reaching €35 million or 7% of global annual turnover, whichever is higher, a ceiling that exceeds the maximum fine under the General Data Protection Regulation (GDPR). California has taken a narrower but directly relevant approach: AB 3030 now requires health facilities, clinics, and physician offices to disclose to patients whenever generative AI was used to produce communications about their clinical information, unless a licensed provider has reviewed the content first.
The technical challenge underneath these rules is also getting harder to solve. Removing names and other direct identifiers from a dataset was once considered sufficient de-identification. It increasingly is not. AI models are effective enough at cross-referencing anonymised clinical or trial data against other public information that re-identifying individual patients is a realistic risk, rather than a theoretical one; a dynamic sometimes called the ‘mosaic effect’. And sharing data with AI vendors carries its own obligations: under HIPAA, giving an external AI system access to PHI generally requires a signed Business Associate Agreement first. Without one, even a partial or inadvertent disclosure can constitute a real compliance violation.
The challenge becomes more significant still as AI moves beyond assistance toward more autonomous development. This shift is beginning to reshape the traditional software development lifecycle into what can be thought of as an AI-driven Development Lifecycle (AI-DLC), where human developers and AI agents work together inside development environments, repositories, and other software-building systems.
An agent that can work across a repository, modify multiple files, run tests, invoke tools, or interact with other systems has a broader operational footprint than a conventional code-completion assistant. Least-privilege access, monitoring, and auditability consequently become increasingly important components of AI development governance. For pharma, that governance needs to account for more than confidentiality: software supporting research and healthcare processes must also maintain reliability, integrity, and traceability.
AI introduces new software supply-chain risks
The security challenge extends beyond the code an AI system writes. AI coding assistants regularly recommend open-source packages to help developers implement functionality more quickly. LLMs can also hallucinate package names that do not actually exist, and attackers have learned to register packages under some of these names and seed them with malicious code.
In that scenario, the vulnerability is not necessarily written into the application’s own code. It can enter through a dependency that a developer accepts because it appears to be a legitimate recommendation. For an organisation handling clinical trial data or proprietary research, a compromised dependency can expose the very information that application security controls are designed to protect.
This illustrates why securing AI-assisted development requires visibility beyond the application itself. Security teams need to understand not only what code AI systems generate, but also which agents and models are being used, what components and dependencies they introduce, which development tools and services they can reach, and how those systems interact across the software supply chain. As AI agents gain the autonomy to select packages, call tools, and execute development tasks on their own, securing the output without understanding the surrounding agentic environment leaves a significant blind spot.
Security must operate at AI speed
The rise of AI-assisted and increasingly agentic development is forcing organisations to rethink where and how security fits into the software lifecycle. As developers shift from writing every line themselves toward directing, reviewing, and maintaining code produced with AI agents, the traditional model of security as a downstream checkpoint becomes harder to sustain.
Historically, security testing often occurred later in development, during staging or final release checks. That approach is increasingly inadequate when developers and AI agents can generate and iterate on code continuously. In an AI-driven Development Lifecycle, security needs to operate as a persistent part of the development process, rather than an intermediate or final gate.
AI-native development compresses the development cycle. More code can be produced, modified, and tested in less time, creating the possibility that security review becomes a bottleneck or that vulnerabilities accumulate faster than teams can remediate them.
In response, organisations are beginning to adopt more agentic security models, in which AI participates directly in identifying, prioritising, and remediating vulnerabilities as code is written, rather than simply generating findings for humans to triage later. This is one side of the equation: using AI for security so defensive analysis can keep pace with AI-driven software creation.
The objective is not to slow AI-assisted development down. It is to provide security feedback at the same speed at which software is being created and changed, including while prompts are being translated into code and before risky changes move deeper into the development process.
Security analysis should therefore be available where developers and AI agents are already working, including development environments, repositories, pull requests, and CI/CD pipelines, rather than being treated primarily as a final gate before deployment. The earlier a vulnerability, unsafe dependency, exposed secret, or policy violation can be identified, the less likely it is to propagate through an increasingly automated workflow.
This approach also creates an opportunity to use AI defensively. Security analysis and remediation can increasingly be automated alongside code generation, allowing vulnerabilities to be identified, explained, prioritised, and addressed within the same development workflow. At the same time, organisations must secure the AI systems themselves by maintaining visibility into the agents, models, tools, data, and permissions involved in building software.
The result is a continuous security feedback loop, rather than a sequence of disconnected security gates. In an agentic model, AppSec becomes part of the development process itself, providing prevention, visibility, governance, and remediation as humans and AI systems work together.
Adopting AI development tools while maintaining compliance
Pharmaceutical companies do not need to choose between AI-driven development and responsible software security. They need governance that allows the two to operate together as development becomes more agentic. That means governing not only the code that emerges, but also the agents, models, tools, data flows, and permissions involved in producing it. Several practices can help establish that foundation.
Establish clear policies and guardrails for AI tool usage. Organisations should define rules outlining how developers and AI agents can use coding systems, what types of data can be shared with external models, which tools and models meet organisational requirements, and what level of access autonomous systems are permitted to have. Policies should also account for emerging components such as AI-enabled development environments and Model Context Protocol (MCP) servers when they are introduced into the workflow.
Prevent sensitive data exposure
Developers should avoid including PHI, clinical data, or proprietary research information in prompts to external AI systems. Technical controls can complement developer policies by detecting and blocking sensitive data before it reaches AI services.
Integrate security into development workflows. Security capabilities embedded within development environments, repositories, pull requests, and CI/CD pipelines can analyse applications, open-source dependencies, infrastructure configuration, and secrets. They should also scrutinise package recommendations and changes made by AI coding systems, rather than treating agent-generated output as inherently trustworthy. The goal is to prevent or surface risk close to its source, while there is still context to correct it quickly.
Maintain transparency and auditability. As regulatory frameworks like the EU AI Act and state-level disclosure laws raise the bar for what organisations must demonstrate, audit trails covering how AI systems are used, which agents and models participate in development, what they can access, what actions they take, and what security checks their output undergoes become essential to compliance, not just good practice.
Apply least-privilege access to AI systems. AI agents should receive only the permissions required for their assigned tasks, with access to source repositories, credentials, development tools, and production systems appropriately restricted and monitored. As agents gain the ability to invoke tools and act across multiple systems, controlling what an agent can touch becomes as important as reviewing the code it produces.
Innovation and security must move together
AI-assisted development is becoming a permanent part of modern software engineering. For HCLS organisations, the question is no longer whether these tools will be adopted, but how they can be integrated safely, whether they are being used to build new capabilities or modernise software that has been running for years.
Digital innovation is essential to advancing healthcare, powering everything from decentralised clinical trials to real-world evidence platforms that inform treatment decisions. AI-assisted development has the potential to accelerate these efforts significantly. But the security model must evolve alongside the development model.
The challenge is no longer simply preventing developers from making mistakes with AI coding assistants. It is creating a software development environment in which humans and AI agents can produce and modify code rapidly while security, privacy, data integrity, and governance remain embedded throughout the process. That is the central security challenge of the emerging AI-driven Development Lifecycle: securing both what AI creates and the environment in which agents are allowed to act. For pharma, the objective should not be to slow the adoption of AI-native development. It should be to make secure development an inherent part of it.
As the industry moves from AI-assisted coding towards increasingly AI-native and agentic software engineering, organisations will need to design explicitly for builders and agents working together. Those that embed prevention, visibility, least-privilege access, auditability, and continuous security into that transition will be better positioned to capture the benefits of faster development without compromising the trust of patients, research partners, or regulators.
About the author
Eran Kinsbruner is vice president of product marketing at Checkmarx, where he leads product marketing strategy for the company's application security portfolio. A seasoned enterprise SaaS marketing executive, Kinsbruner is a recognised thought leader, board advisor to stealth technology companies, researcher, inventor, and best-selling author of four books. He brings deep expertise in B2B SaaS, AI, observability, DevOps, and software quality, with a proven track record of developing and executing go-to-market strategies that strengthen product positioning, elevate thought leadership, increase brand awareness, and drive business growth. Throughout his career, Kinsbruner has successfully led cross-functional teams to deliver competitive, high-value products that accelerate sales and market adoption.
