Penetration Testing and Secure Code Review for AI-Enabled Life-Sciences Systems
Authorized, scoped and insured engagements against systems you own. An AI-enabled system changes what has to be tested. A regulated environment changes how testing may be conducted. We define both before anyone touches anything.
Before a provider can test anything, the buyer and the provider have to mean the same thing by the words in the contract. In this market they usually do not. Resolving that is not preliminary work that delays the engagement; it is the part of the engagement that determines whether the result is defensible afterwards.
The terminology problem
CREST says the phrase has no clear definition
The strongest available evidence that buyers are confused comes from the accreditation body itself. CREST has been accrediting penetration testing companies since 2006 and, by the end of 2021, had assessed more than 300 organisations delivering penetration testing globally. Its Defensible Penetration Test guidance states that the phrase "lacks clear definition, and is often misunderstood", and that "there is significant definitional misalignment between buyers and service providers directed to the definition of penetration test".
The same document observes that for many individuals, "security auditing, penetration testing, vulnerability analysis, ethical hacking and red teaming all mean the same thing". They do not. A vulnerability scan enumerates known issues against known signatures. A vulnerability assessment interprets those results and adds coverage. A penetration test attempts to establish real, chained access. A red team exercise tests detection and response against an objective, usually without the defenders knowing. A bug bounty is a continuous, uncontrolled version of the third. A secure code review reads the implementation rather than probing the deployment. Each answers a different question and none substitutes for another.
The UK National Cyber Security Centre adds the sharpest correction to a common buyer assumption: a penetration test "should not be viewed as a primary vulnerability identification method". Its own definition is "attempting to breach some or all of that system’s security, using the same tools and techniques as an adversary might". A test is an assurance activity. If you are relying on an annual engagement to discover what is wrong with your estate, the engagement is being asked to do a job that continuous scanning and asset management should already be doing, and it will do that job badly and expensively.
NIST’s glossary makes the distinguishing point about what a test adds over a scan: testers look for "combinations of vulnerabilities on a single system or multiple systems" that can be used to gain more access than any single vulnerability would allow. Chaining is the deliverable. A list of individually medium-severity findings that compose into full administrative access over a validated system is a completely different piece of information from the same list presented as nine unrelated mediums, and only the first version changes what an executive decides.
Vulnerability scan
Automated enumeration against known signatures. Cheap, repeatable, and the correct thing to run between engagements rather than instead of them.
Penetration test
Human-led attempt to establish and chain real access within an agreed boundary, producing exploitable paths and business impact rather than a list.
Red team exercise
Objective-driven adversary simulation that also tests detection and response. Different success criteria, different stakeholders, different cost.
Secure code review
Reading the implementation for the defect classes that no runtime probe can reliably reach, especially authorization and cryptographic logic.
If two quotes for "a penetration test" differ by a factor of four, the difference is almost always in the test specification, not in the testers.
AI security services overview— How testing fits alongside exposure review, vendor assessment and questionnaire readiness.
Requirements baseline
OWASP ASVS 5.0.0 is what "secure enough" means in a contract
A test needs something to test against. The Application Security Verification Standard is the requirements baseline: version 5.0.0 was released on 30 May 2025 at Global AppSec EU in Barcelona and contains around 350 requirements divided into 17 chapters, tiered into three cumulative levels. Level 1 contains roughly 20 percent of the requirements and is described as "the minimum requirements to consider when securing an application". Level 2 brings the cumulative total to about 70 percent and is where, in OWASP’s words, "most applications should be striving". Level 3 is the remaining 30 percent, for applications demonstrating the highest levels of security.
The practical value of naming a level in a statement of work is that it converts an argument into a checklist. "Secure enough" is unresolvable. "ASVS 5.0.0 Level 2, with the exceptions listed in appendix B and the rationale for each" is a document a quality organisation, a customer’s security team and a development lead can all read and disagree with specifically. For most life-sciences applications handling internal or partner data, Level 2 is the correct target; a system carrying patient-identifiable data or driving a regulated decision is the case for Level 3 on the affected chapters rather than across the whole application.
ASVS answers what must be true. It does not tell a tester how to establish it. That is the Web Security Testing Guide, and its version currency is a small but reliable indicator of whether a provider reads primary sources: WSTG is still at version 4.2, dated 3 December 2020. Version 5.0 appears in the project’s release planning but has not shipped. Anyone advertising testing against "the latest OWASP testing guide, version 5" is describing a document that does not exist.
WSTG’s contribution is stable scenario identifiers in the form WSTG-CATEGORY-NUMBER, so that coverage can be audited rather than asserted. Version 4.2 added GraphQL API testing as WSTG-APIT-01, server-side request forgery as WSTG-INPV-19 and session hijacking as WSTG-SESS-09, merged several older scenarios and rewrote the reporting section. For mobile scope the equivalents are the Mobile Application Security Verification Standard and the Mobile Application Security Testing Guide, with the MASWE weakness list alongside them.
ASVS 5.0.0 Level 1
Around 20 percent of the standard. A floor, not a target, and rarely the right answer for an application that touches regulated data.
ASVS 5.0.0 Level 2
Cumulatively around 70 percent. OWASP’s stated target for most applications, and the usual contractual level for life-sciences software.
WSTG 4.2 coverage
Stable scenario IDs that let a client audit what was tested rather than accept a narrative that testing was thorough.
MASVS and MASTG
The mobile equivalents, relevant whenever a field application, patient-facing app or device companion is in scope.
Related evidence and next steps
OWASP ASVS project page— Confirms 5.0.0 as the current stable version and its May 2025 release.
Four process standards, and when each one is the right frame
Coverage standards say what to test. Process standards say how an engagement is run, documented and defended afterwards. They are not competitors and a mature statement of work usually cites two of them for different purposes.
NIST Special Publication 800-115, the Technical Guide to Information Security Testing and Assessment, dates from September 2008 and supersedes SP 800-42. Its age is irrelevant to its two durable contributions: a four-stage penetration testing methodology of Planning, Discovery, Attack and Reporting with an explicit loop from Attack back to additional Discovery, and Appendix B, still the best free rules-of-engagement template in existence. It is also the reference a United States regulated buyer will accept without argument, which matters more than novelty.
The Penetration Testing Execution Standard organises the engagement into seven sections: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting. Its distinguishing value is that pre-engagement and reporting are first-class phases rather than administrative wrapping. Its weakness is currency: the documentation still self-describes as a version 1.0. Use it for the engagement narrative and the reporting skeleton, not as a claim of active maintenance.
OSSTMM 3, published by ISECOM in 2010, is measurement-oriented. Its ambition was to replace "general best practices, anecdotal evidence, or superstitions" with verified facts, and its two useful exports are the rav attack-surface metric and the Security Test Audit Report, a factual one-page statement of what was and was not tested. Its scope is broader than networks, covering "physical locations, human interactions, and all forms of communications such as wireless, wired, analog, and digital". There is no published version 4, and we say so rather than implying currency.
CREST contributes provider-side assurance rather than a methodology. Its Defensible Penetration Test specification, first announced in August 2022 with guidance dated June 2023, defines a minimum set of expectations and names three conditions for commercial defensibility: the provider has appropriate policies, procedures, practices and methodologies; the individuals have appropriate levels of skills, experience and competency; and the work proceeds against "a defined and agreed test specification". CREST OVS aligns application testing to ASVS and MASVS, and the STAR and STAR-FS schemes cover intelligence-led testing alongside regulator-run programmes.
One compliance driver is worth naming carefully. PCI DSS v4.0.1 requires a documented penetration testing methodology based on an industry-accepted approach, with the commonly cited set being NIST SP 800-115, OWASP, PTES and OSSTMM, plus internal and external testing at least every twelve months, remediation and retest, and segmentation testing. The standard itself sits behind the PCI Security Standards Council document library, so we have not reproduced its clause text here and neither should anyone else who has not read it.
Web or API application
WSTG 4.2 for demonstrable coverage, ASVS 5.0.0 Level 2 as the requirements baseline written into the contract.
US regulated or PCI-facing buyer
NIST SP 800-115 as the governance spine, PTES for phase detail and the reporting structure.
Comparability across years
OSSTMM 3 for the rav metric and the discipline of stating untested scope in every report.
Assurance about the provider
CREST accreditation and the CDPT specification, which is about the firm and the test specification rather than the technique.
AI red teaming is not AI application penetration testing
These two phrases are used interchangeably in almost every vendor deck in this market, and they describe different work with different objects, different success criteria and different people accountable for the fix. Getting the distinction right in a first conversation saves a client from buying the wrong thing.
AI red teaming examines the model and its behaviour: whether it can be induced to act in ways it should not, how robust refusals are, which harm categories reproduce and at what rate. Its governing references are the NIST Generative AI Profile of the AI Risk Management Framework, the NIST adversarial machine learning taxonomy, OWASP’s GenAI Red Teaming Guide and MITRE ATLAS. Its deliverable is coverage of a harm taxonomy with attack-success rates, and the fix usually belongs to the model provider, the fine-tuner or whoever owns the system prompt and guardrails.
AI application penetration testing examines the deployed system: the application, its APIs, the tool layer, the retrieval pipeline, identity and entitlements, the cloud account and the data stores. The question is whether an attacker can cause unauthorized access, unauthorized action, data loss or unbounded cost through this deployment. The deliverable is a concrete exploitable path with a business impact, a remediation, and a retest. The fix belongs to application and platform engineering.
The reason the terms collapse is that OWASP itself scopes GenAI red teaming across four areas: "model evaluation, implementation testing, infrastructure assessment, and runtime behavior analysis". In that framing, red teaming is the superset and application testing is one component of it. Microsoft’s AI Red Team, reporting on more than 100 generative AI products, puts the practical corrective in two of its lessons: "AI red teaming is not safety benchmarking", and "LLMs amplify existing security risks and introduce new ones". The second sentence is the honest one-line reason a client usually needs both, in sequence, rather than one badged as the other.
Our position is stated plainly because it costs us work sometimes. We perform AI application penetration testing and secure code review of AI-enabled systems, and we incorporate adversarial model probing such as prompt injection, jailbreak and tool abuse where it produces a security finding in the deployed system. We do not sell model safety evaluation as penetration testing. If model evaluation is what a client actually needs, that is what we say.
Findings with CVSS v4.0, reproduction, impact, remediation and a retest attestation
Who owns the fix
Model provider, fine-tuner, or the owner of the system prompt and guardrails
Application and platform engineering, and whoever owns cloud identity
What it does not tell you
Whether your deployment leaks data, over-grants tool permissions or misconfigures identity
Whether the model itself is safe for a use it was never scoped against
How an authorized engagement is governed, and how it ends
Everything a penetration tester does would be unlawful without permission, and everything a penetration tester produces is a written, indexed guide to compromising the client. Governance is not overhead on this service. It is most of what distinguishes a professional engagement from an expensive risk.
Authorization
The authorization letter is the control; case law is the backstop
In the United States the controlling statute is the Computer Fraud and Abuse Act, 18 U.S.C. section 1030, which reaches anyone who "intentionally accesses a computer without authorization or exceeds authorized access". Two developments define the modern position, and both are frequently misread as making written authorization less important. They do the opposite.
In Van Buren v. United States, No. 19-783, argued 30 November 2020 and decided 3 June 2021, the Supreme Court held that an individual exceeds authorized access when they access a computer with authorization but then obtain information located in particular areas of the computer, such as files, folders or databases, that are off-limits to them. Commentators call this the gates-up-or-down reading. The operational consequence is precise: the boundary that matters is the technical access boundary, not the tester’s purpose. That is exactly why an authorization letter must enumerate systems and areas rather than merely state intent.
On 19 May 2022 the Department of Justice established as formal policy that it would not charge good-faith security research, defined as "accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public", with the reviewing attorney instructed that they "should decline prosecution". DOJ also stated it would not bring exceeds-authorized-access cases on the theory that authorization was limited by contract or company policy, subject to a carve-out for contracts that entirely prohibit access to particular files, databases, folders or accounts.
Three caveats belong on any page that mentions this, and their absence is a reliable tell. The DOJ position is a charging policy: it binds federal prosecutors and has no effect on civil CFAA liability or on state laws. It is policy rather than statute, and it is revocable. And nothing in it substitutes for written authorization from the asset owner. The professional posture is that the authorization letter is the control, and Van Buren and the DOJ policy are the backstop rather than the plan. None of this is legal advice, and NIST is explicit that counsel belongs in the process, recommending that legal advisors "always be involved for intrusive tests such as penetration testing", including on indemnity or limitation of liability clauses and on non-disclosure agreements binding the assessors.
Every IntuitionLabs engagement proceeds only under a signed authorization letter that scopes exactly what may be touched, against systems the client owns or is explicitly authorized by the owner to test. The letter names the in-scope assets, the exclude list, the window, the permitted activity classes, the halt criteria and the signatories with actual authority. There is no informal start, no verbal expansion of scope mid-test, and no testing of an asset whose owner has not authorized it.
A contract that says "do not touch system X" and an access boundary that lets you touch it are two different protections. Scope both.
An ROE that requires a phone call before every action is not an ROE
NIST’s working definition is the one to adopt: rules of engagement are "detailed guidelines and constraints regarding the execution of information security testing", established before the start of a test, giving "the test team authority to conduct defined activities without the need for additional permissions". That last clause is the whole point. The document exists so that a tester can act decisively inside a boundary that was agreed while everyone was calm.
The SP 800-115 Appendix B template remains the reference skeleton, and its section list is a good specification in itself. The introduction states purpose, scope in terms of "test boundaries in terms of actions and expected outcomes", assumptions, limitations, risks and mitigations. Logistics names personnel on both sides with a points-of-contact table that includes the incident response team, the schedule including hours of day, and the test equipment, including "the method of differentiating between the organization’s systems and the systems conducting the testing" plus the list of authorized tools.
The communication section is where most weak engagements fail. NIST requires that "criteria for halting the information security testing should be provided", that the ROE state what the test team does if a procedure negatively affects the network, and that it cover the case where "an adversary attacks the organization while testing is underway". It also requires "a process for reinstating the test team and resuming testing". A real attack landing in the middle of an authorized test is the scenario that produces the worst incident-response decisions in the industry, and it is answerable in advance in a paragraph.
The target section defines authorized and unauthorized identifiers, and NIST names the artefact explicitly: "any system not authorized for testing, this is referred to as the exclude list". The execution section defines allowable and unallowable activities plus the methodology, and, where physical testing is in scope, requires "a form, with appropriate signatures and contact information, generated for the test team to show to law enforcement or onsite security personnel". That the get-out-of-jail letter appears in a NIST appendix is the best available answer to anyone who thinks it is theatrics.
On timing, NIST is more measured than most vendors: it suggests it "may be prudent to conduct technical testing of an operational site during evening hours rather than during peak business periods", and on frequency it says that "penetration testing of an organization’s network and systems on an annual basis may be sufficient", with organisations conducting less labour-intensive testing regularly in between. That is scanning between tests, not more tests.
Production or a qualified mirror is a risk decision, not a preference
NIST states the risk without hedging: penetration testing "poses a high risk to the organization’s networks and systems because it uses real exploits and attacks against production systems and data", and it recommends that testing "can be designed to stop when the tester reaches a point when an additional action will cause damage". Both halves matter. The risk is real, and it is manageable by design rather than by hope.
Production is the only environment where a finding is unambiguously real. Same data classification, same integrations, same web application firewall and rate limits, same identity provider, same third-party dependencies. Staging findings frequently fail to reproduce in production, and production-only findings are routinely missed by a staging-only engagement. Anyone who tells you a staging test is equivalent is describing a cheaper engagement, not a comparable one.
The mitigations that keep production testing defensible are concrete and belong in the rules of engagement rather than in a tester’s judgement: non-destructive test classes only, seeded test accounts and test tenants, a documented halt condition, agreed time-of-day windows, rate limits agreed in advance, no exfiltration of real records so that access is proven rather than data taken, and an explicit decision on whether the security operations team is deconflicted or deliberately not deconflicted, which is a purple-team choice with its own value.
In a regulated environment the compromise that actually works is a split by state-change risk: a qualified mirror for anything state-changing, plus a strictly bounded production pass for reconnaissance, configuration, authentication and authorization logic and non-destructive validation. This is our recommended operating model and industry practice, not a regulatory requirement, and we present it that way to a quality organisation rather than dressing it as a rule.
Runs in production
Reconnaissance, transport and header configuration, authentication flows on seeded accounts, authorization matrix analysis, session handling, information disclosure.
Runs in a qualified mirror
Anything that writes, uploads, alters configuration, or attempts exploitation with a state change, including destructive proof of a chained path.
Agreed before the test
Halt criteria, rate limits, testing windows, deconfliction with the security operations team, and the exact evidence a finding may capture.
Never used as evidence
Real batch records, real subject data, real patient identifiers. A redacted proof-of-access artefact demonstrates the same finding.
Third-party boundaries
Cloud provider policies differ materially, and one of them changes the engagement
Scoping has to establish, per asset, who owns it, who operates it and which provider policy governs it. Software a client merely subscribes to is not the client’s to authorize. This is where inexperienced providers create genuine legal exposure, and the three major clouds are not interchangeable on the point.
AWS permits security assessment against a defined list of services without prior approval, currently including EC2 instances, WAF, NAT gateways and Elastic Load Balancers, RDS, CloudFront, Aurora, API Gateway, AppSync, Lambda and Lambda Edge functions, Lightsail resources, Elastic Beanstalk environments, Elastic Container Service, Fargate, OpenSearch Service, FSx, Transit Gateway and Amazon Bedrock AgentCore. That last entry matters for anyone testing agentic systems: AWS has explicitly brought an agentic AI runtime into the permitted list. Prohibited activities include DNS zone walking, DNS hijacking and pharming via Route 53, denial of service in real or simulated form, port, protocol and request flooding, S3 bucket takeover and subdomain takeover. Command-and-control testing needs advance approval, and red, blue or purple team exercises, volumetric testing, simulated phishing and malware testing require a Simulated Events form "at least two (2) weeks in advance of the start date".
Microsoft does not require pre-approval and constrains by ownership instead: "all encouraged testing activities must be performed within your own tenant or assets for which you have explicit authorization". Prohibited items include attempting to access, scan or test a tenant, system logs or databases you do not own, denial of service, credential theft, phishing, and, critically, "post-compromise or post-exploit actions, such as enumerating internal networks/files, dumping secrets, executing additional code, performing lateral movement, or pivoting". Read that again in the context of scoping: Microsoft’s rules of engagement restrict post-exploitation even inside your own tenant. A full-chain Azure engagement therefore cannot look like a full-chain AWS engagement, and a provider who quotes both the same way has not read the policy.
Google Cloud requires no prior contact at all: "if you plan to evaluate the security of your Cloud Platform infrastructure with penetration testing, you are not required to contact us", subject to the Acceptable Use Policy and Terms of Service and to confining tests to your own projects without affecting other customers. Vulnerabilities discovered in Google’s own services go to the Vulnerability Reward Program rather than into your report as a finding against you.
For any multi-tenant dependency that is not covered by one of these positions, the rule is simple and we apply it without exception: obtain the provider’s written position, or exclude the asset. A SaaS platform your client pays for is owned by its vendor, and vendor security is a different exercise with a different deliverable.
The engagement creates the most dangerous document in your estate
A penetration test produces a written, indexed list of how to compromise the client, plus whatever screenshots, credentials and extracts prove it. NIST SP 800-115 devotes a full section to data collection, storage, transmission and destruction, and points to SP 800-88 for sanitization with four categories: disposal, clearing, purging and destruction.
The definitions are worth knowing because they are contractual terms in a serious engagement. Clearing "must keep information from being retrieved by data, disk, or file recovery utilities". Purging "protects information confidentiality against a laboratory attack". Destruction is "physical obliteration of media". A contract that says evidence will be "securely deleted" without naming which of those it means has not said anything.
The practical terms that follow are encryption at rest and in transit for all evidence, named custodians on both sides, a defined retention period running from report delivery and retest rather than from the test itself, a certificate of destruction, and a hard rule that real production records are never retained as evidence. Where a finding requires proof of access to sensitive data, the artefact is a redacted proof-of-access, not the record. In a life-sciences environment this is not a nicety: retaining a subject record or a batch record as a screenshot inside a consultant’s report creates a data-protection problem that outlasts the finding.
Encryption and custody
Evidence encrypted at rest and in transit, named custodians on both sides, and an access log for the report itself.
Retention clock
Retention runs from report delivery and completed retest, not from the last day of testing, and is stated in the contract.
Destruction standard
Clearing, purging or destruction named explicitly per SP 800-88, with a certificate issued at the end of the retention period.
No real records
Proof of access is demonstrated with redacted artefacts. Real subject, patient or batch data is never taken or retained.
Closing the engagement
Reporting, scoring, and why a closed ticket is not a fixed finding
PTES defines the base report structure as two major sections addressing different audiences, and its executive summary components are the ones worth naming: background, overall posture, and risk ranking with the scoring mechanism agreed during pre-engagement rather than chosen after the results are known.
Two PTES rules separate a report from a document. The first is on scope drift: "if objectives were changed during the course of the testing then all changes must be listed in this section of the report", with the letter of amendment included in the appendix. The second is the distinction between systemic and symptomatic issues, and its worked example is the single best line in the standard: a systemic issue is lacking an effective patch management process, whereas a symptomatic issue is finding one missing patch on one host. A report that lists only symptoms is a scanner dump with prose around it.
Scoring uses CVSS v4.0, current since November 2023, which is composed of four metric groups: Base, Threat, Environmental and Supplemental, where supplemental metrics "do not modify the final score, and are used as additional insight". Version 4.0 added an Attack Requirements metric capturing deployment conditions, expanded User Interaction from binary to None, Passive and Active, and separated Subsequent System impact metrics so that impact beyond the vulnerable system is visible. FIRST characterises the release conservatively as clarifying and improving the existing standard, which is a more honest framing than most vendor migration notes.
The caveat that matters is a heading in FIRST’s own user guide: "CVSS Base Score (CVSS-B) Measures Severity, not Risk". The same guide states that the CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE nomenclature "should be used wherever a numerical CVSS value is displayed or communicated", and notes that assessment providers such as the National Vulnerability Database typically publish base scores only. A report that hands a client raw CVSS-B and calls it risk has skipped the only part of the job that required a human. Ours gives CVSS-B for comparability, an environment-adjusted rating with the reasoning shown, and a business impact statement in the client’s own terms.
There is a public example that makes the point better than any argument. EchoLeak, CVE-2025-32711, is recorded in the National Vulnerability Database as an "Ai command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network", published 11 June 2025. Microsoft, as the CNA, scored it CVSS 3.1 at 9.3 critical, with scope changed. NVD scored the same vulnerability 7.5 high, with scope unchanged. Same defect, same standard, two authoritative feeds, a 1.8-point gap and a different remediation queue at most organisations. A client who outsources severity judgement to a single feed has outsourced a decision that depends on their environment to a party that does not know it.
A finding is not closed because a ticket was closed. The retest is scoped to the specific finding and its variants rather than being a re-run of the engagement, and it produces a retest attestation stating, per finding, the original identifier, the remediation the client claims, what the tester re-executed, and the verdict: fixed, partially fixed, not fixed, or risk accepted with a named acceptor. NCSC states the accountability boundary that belongs in every report’s front matter: "risk assessment and decisions on the application of fixes are your responsibility", and the client should evaluate alternatives beyond those the testers propose.
One habit is borrowed directly from OSSTMM and it is the cheapest credibility upgrade available: the Security Test Audit Report requires stating "the types of controls discovered, and what you did not test". Every report we issue contains an explicit scope-exclusions and untested-surface section. It is the section clients quote back to us most often, because it is the one that tells them what they still do not know.
Six sections from the NIST SP 800-115 Appendix B template that decide whether an engagement is defensible. Every one of them is agreed and signed before testing begins.
01
Scope and boundaries
Purpose, the tested organisation, the testing party, and test boundaries expressed "in terms of actions and expected outcomes" rather than as a list of hostnames. Assumptions, limitations, risks and their mitigations are stated, not implied.
02
The exclude list
Authorized and unauthorized addresses and identifiers, including what NIST calls the exclude list: any system not authorized for testing. Third-party and multi-tenant assets without a written provider position go here by default.
03
Halt criteria
The conditions under which testing stops, what the team does if a procedure negatively affects the network, and the documented process for reinstating the test team and resuming work once the condition clears.
04
Real attack during the test
What happens if an actual adversary attacks while testing is underway. The client incident-response call tree appears in quick-reference form so that nobody has to work out attribution under pressure.
05
Tester attribution
The method of differentiating the organisation’s systems from the systems conducting the test, plus the list of authorized tools. Your responders must be able to identify our traffic within seconds, not hours.
06
Signed authorization
Named signatories with actual authority, the testing window, and, where physical testing is in scope, the signed form the team can show to law enforcement or onsite security. No signature, no testing.
Secure code review, and the code you did not write
A penetration test probes the deployment. A secure code review reads the implementation. They find different defects, and the case for the second is made most convincingly by OWASP’s own account of what automated tools cannot do.
Tooling honestly described
What SAST, DAST, IAST and SCA genuinely catch
OWASP’s community page on source code analysis tools is unusually candid, and it is the cleanest available justification for paying a human to read code. It states that "current SAST tools are limited. They can automatically identify only a relatively small percentage of application security flaws", that they produce "high numbers of false positives", and that they are "frequently unable to find configuration issues, since they are not represented in the code".
What static analysis does well is real and worth buying: injection-class and memory-class defects with a syntactic signature, named on the same OWASP page as buffer overflows and SQL injection flaws, found at scale, repeatedly, in continuous integration, with file and line precision a developer can act on immediately. Selection criteria worth writing into a scope document are language support, OWASP Benchmark score, whether the tool needs a successful build, IDE and CI integration, and SARIF output so results are portable between tools.
What the same page lists as static analysis weaknesses is the more interesting half: "authentication problems", "access control issues" and "insecure use of cryptography". Those three categories are where the highest-severity findings in a business application usually live. A tool that cannot see them is not defective; it is being asked a question its representation of the program cannot answer.
Dynamic analysis tools, which OWASP defines as "automated tools that scan web applications, normally from the outside, to look for security vulnerabilities such as Cross-site scripting, SQL Injection, Command Injection, Path Traversal and insecure server configuration", catch what is actually reachable and actually exploitable at runtime, including configuration and deployment defects invisible to static analysis, with no source access required. They miss anything behind an authentication flow they cannot navigate, anything requiring multi-step business logic, and anything in code paths the crawl never reaches, and they cannot point at a line of code.
Interactive testing instruments the running application and observes data flow while functional or dynamic traffic exercises it, which suppresses much of the false-positive load and gives runtime findings a code location. Its limitation is coverage: it only sees code the exercising traffic executes, so results are only as complete as the test suite driving them. We flag this description as practitioner knowledge rather than a citation, because OWASP has no equivalent community page for it. Software composition analysis inventories third-party components and matches them to known vulnerabilities and licences, which catches known issues in declared dependencies and nothing else.
Static analysis
Strong on syntactic injection and memory classes at CI scale. Weak on authentication, access control, cryptographic misuse and configuration, per OWASP.
Dynamic analysis
Strong on what is reachable and exploitable at runtime, including deployment defects. Blind behind complex authentication and multi-step logic.
Interactive testing
Reduces false positives and locates findings in code, but sees only what the driving test suite actually executes.
Composition analysis
Known CVEs in declared dependencies. Cannot see your own defects, unknown flaws upstream, or a package that did not exist until an attacker registered it.
What only a person finds, and why it is the deliverable
OWASP’s Code Review Guide states the position without hedging: "while security scanners are improving every day the need for manual security code reviews still needs to have a prominent place in organizations’ SDLC". The categories a human pass targets map almost exactly onto the categories the tool vendors concede.
Authorization logic is first, and it is the most common source of critical findings in enterprise applications: which user may perform which operation against which object, and whether that decision is made in one place or reimplemented inconsistently across twelve endpoints. Business-logic abuse follows, where each step is individually permitted and the sequence produces an outcome nobody intended. Then cryptographic misuse in context, which is rarely a weak algorithm and usually a correct algorithm used with the wrong key lifecycle, the wrong mode, or a nonce that repeats.
Multi-tenancy boundary errors, trust decisions across service boundaries, and secret and key lifecycle round out the classic set. In AI-enabled applications a new category joins them and it is now frequently the highest-impact one: what a tool call is permitted to do, on whose behalf, and whether that decision is enforced by code or delegated to a model’s judgement. That question cannot be answered by scanning a repository, because the defect is a design decision rather than a pattern.
A review is scoped by risk rather than by line count. We read the authentication and session implementation, the authorization enforcement points, the data access layer, the tool and integration layer in an AI application, the secret handling, the input and output boundaries, and the deployment configuration that the code depends on. Everything else gets tool coverage and a sampling pass. Telling a client we read every line of a large codebase would be a claim neither of us could verify.
Design-time
Threat modeling: four questions, STRIDE, and the anti-patterns
The Threat Modeling Manifesto, published in 2020 by a group of practitioners, defines threat modeling as "analyzing representations of a system to highlight concerns about security and privacy characteristics", and anchors it in four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job.
The Manifesto’s values describe the failure modes of bad consultancy more precisely than any critique of it could: "a culture of finding and fixing design issues over checkbox compliance", "people and collaboration over processes, methodologies, and tools", "a journey of understanding over a security or privacy snapshot", "doing threat modeling over talking about it", and "continuous refinement over a single delivery". Its named anti-patterns are equally useful in a procurement conversation. The Hero Threat Modeler anti-pattern states that "threat modeling does not depend on one’s innate ability or unique mindset; everyone can and should do it". Admiration for the Problem, Tendency to Overfocus and Perfect Representation complete the set.
STRIDE remains the standard elicitation taxonomy and is documented authoritatively by Microsoft as "a core element of the Microsoft Security Development Lifecycle": spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. Microsoft’s own framing, that the tool was designed with non-security experts in mind, supports the argument that threat modeling should be a recurring team activity rather than a consultant artefact delivered once and filed.
For AI systems specifically, Microsoft publishes separate developer threat modeling guidance for machine learning systems and a taxonomy of machine learning failure modes, and the 2026 OWASP LLM Top 10 ships an appendix covering LLM application architecture and threat modeling. The right output of a threat modeling engagement is a team that can run the next one without us, plus a model that gets updated when the architecture changes rather than when the next audit is scheduled.
AI policy and governance— Where a threat model becomes an operating rule rather than a document.
Secure SDLC and supply chain
SSDF, SLSA, in-toto and the bill of materials
NIST SP 800-218, the Secure Software Development Framework version 1.1 from February 2022, states the underlying problem exactly: "few software development life cycle (SDLC) models explicitly address software security in detail, so secure software development practices usually need to be added to each SDLC model". It is deliberately model-agnostic, and its second stated purpose is procurement, so that "software purchasers and consumers can also use it to foster communications with suppliers in acquisition processes".
For AI work the companion document is NIST SP 800-218A, the Secure Software Development Practices for Generative AI and Dual-Use Foundation Models community profile, published July 2024. It "augments the secure software development practices and tasks defined in Secure Software Development Framework (SSDF) version 1.1" with practices specific to AI model development, and it is designed to be used alongside 800-218 rather than instead of it. When a life-sciences client asks which recognised secure-development framework applies to their AI work, that pair is the answer.
SLSA, the Supply-chain Levels for Software Artifacts specification now at version 1.2, is "a set of incrementally adoptable guidelines for supply chain security, established by industry consensus", organised into tracks and levels. The Build track runs from Level 1, provenance showing how the package was built, to Level 2, signed provenance generated by a hosted build platform, to Level 3, a hardened build platform, targeting mistakes, tampering after the build and tampering during the build respectively. SLSA positions itself explicitly as "a way to measure your efforts toward compliance with the Secure Software Development Framework (SSDF)", which is the sentence that connects it to NIST for a regulated buyer.
SLSA also makes the strongest argument in the whole supply-chain area for why scanning is insufficient on its own: "even after fuzzing or vulnerability scanning is completed, changes to code can happen", and "any weaknesses in the supply chain undermine confidence in whether the code that you run is actually the code that you scanned". The complementary attestation framework is in-toto, a CNCF graduated project "designed to ensure the integrity of a software product from initiation to end-user installation", making it transparent what steps were performed, by whom, and in what order.
On bill-of-materials formats, SPDX is an international open standard as ISO/IEC 5962:2021, which is the safer citation when a procurement team wants a standards reference. CycloneDX is at version 1.7, released 21 October 2025 and published 10 December 2025, standardised as ECMA-424 and developed by OWASP with Ecma International. Its dependency graph represents both direct and transitive relationships, and its components can represent "software, hardware devices, machine learning models, source code, and configurations", which means it can carry an AI bill of materials rather than requiring a separate format. CISA is the operational policy home, describing an SBOM as "a nested inventory, a list of ingredients that make up software components", maintaining the VEX attestation work and publishing minimum-elements guidance including a specific document on software bills of materials for AI.
ISO/IEC 27001:2022, third edition, published October 2022, is the information security management standard most life-sciences buyers hold or demand, and two of its Annex A controls bear on this service line: 8.29 on security testing in development and acceptance, and 8.8 on management of technical vulnerabilities. The control text is paywalled and we have not read it in full, so we do not reproduce or paraphrase it as if we had; explanatory secondary sources describe 8.29 as a merger of the two 2013 controls covering system security testing and acceptance testing.
ISO/IEC 27001:2022— Edition and scope. Control text is paywalled and is not quoted here.
AI-generated code
What the research measures, and how careful you have to be with it
The measurement chain here is unusually good, and it is worth presenting with its limitations because the limitations are what make it credible. The origin study is Pearce, Ahmad, Tan, Dolan-Gavitt and Karri, "Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions", from August 2021. Working against the 2021 MITRE CWE Top 25, the authors report: "in total, we produce 89 different scenarios for Copilot to complete, producing 1,689 programs. Of these, we found approximately 40 percent to be vulnerable."
The human-factors study is Perry, Srivastava, Kumar and Boneh, "Do Users Write More Insecure Code with AI Assistants?", presented at ACM CCS 2023. Forty-seven participants completed five security-related programming tasks across Python, JavaScript and C using an OpenAI model of the period. Two findings matter. Participants with access to an assistant "wrote significantly less secure code than those without access to an assistant". And they "were also more likely to believe they wrote secure code, suggesting that such tools may lead users to be overconfident about security flaws in their code". Sample size is small at forty-seven and the model is several generations old; both facts belong next to the result.
The longitudinal series is Veracode’s GenAI Code Security Report, and it requires an explicit disclosure. Veracode sells static analysis and grades the generated code with its own static analysis tool, a methodology that will systematically favour the defect classes its product detects and cannot count the classes it misses. Read as a self-consistent trend line rather than an absolute rate, the series is still the most useful thing in the area. Its 2025 edition reported that 45 percent of code samples failed security tests across more than 100 large language models, with cross-site scripting undefended in 86 percent of relevant samples. Its Spring 2026 update, after a further generation of frontier models, reports that "security pass rates remain stubbornly stuck at approximately 55 percent", while syntax correctness now exceeds 95 percent, and that model size has "only a very small effect on security performance".
The divergence is the finding. Syntax pass rates climbed from roughly 50 to 95 percent between 2023 and the 2026 measurement, and security pass rates stayed essentially flat. That pattern is hard to fake, it is corroborated in direction by the two academic studies above, and it has a clean practical implication: the improvement in model output that everyone can observe is an improvement in the dimension that is easy to evaluate, not in the dimension that requires an adversary to evaluate.
Pearce et al., 2021
1,689 generated programs across 89 scenarios drawn from the MITRE CWE Top 25; approximately 40 percent assessed as vulnerable.
Perry et al., CCS 2023
Forty-seven participants, five tasks, three languages. Less secure code with an assistant, plus measurable overconfidence about it.
Veracode longitudinal series
Security pass rates around 55 percent against syntax above 95 percent. Vendor research, graded with the vendor’s own static analysis tool.
What it does not say
None of this measures your codebase. It establishes a prior that makes review of AI-assisted code a reasonable default, not a verdict on your team.
Your AI policy governs the code your people write, and nothing else
This is the argument most competing pages miss, and it is the reason a life-sciences buyer with a strict internal AI policy still needs code review and supply-chain work. A policy governs one path. Three others reach your product without passing through it.
The first is package hallucination, and the measurement is strong. Spracklen, Wijewickrama, Sakib, Maiti, Viswanath and Jadliwala presented "We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs" at USENIX Security 2025. Using sixteen popular code-generating models and two prompt datasets, they generated 576,000 code samples in two programming languages and found that "the average percentage of hallucinated packages is at least 5.2 percent for commercial models and 21.7 percent for open-source models, including a staggering 205,474 unique examples of hallucinated package names". The attack, now called slopsquatting, is simply to register one of those names. Software composition analysis cannot help, because by the time the dependency is installed it genuinely exists. The authors also implemented mitigations that "significantly reduce the number of package hallucinations while maintaining code quality", so this is a tractable problem rather than a scare.
The second path is your dependency tree. It is written by other people, and those people use assistants at a rate you neither set nor observe. Every measurement in the previous chapter therefore applies to your transitive graph at whatever adoption rate upstream maintainers have reached. This is precisely the gap SLSA articulates when it says weaknesses in the supply chain undermine confidence that the code you run is the code you scanned.
The third path is vendored software and models. Models, weights, adapters, prompt libraries and MCP servers are dependencies with no equivalent of a CVE feed, which is why the 2026 OWASP LLM Top 10 keeps Supply Chain at LLM04 and the Agentic Top 10 adds ASI04 for agentic supply chain vulnerabilities. CycloneDX 1.7’s ability to represent machine learning models as components, and CISA’s AI bill-of-materials minimum-elements work, are the current inventory answers.
The conclusion is uncomfortable but simple. An organisation’s AI policy governs the first path only. The other three are governed by bill-of-materials completeness, dependency provenance through SLSA and in-toto, registry hygiene against slopsquatting, and human review of what a dependency actually does. None of those are AI-policy questions, and none of them get solved by tightening the policy.
A strict internal AI policy is necessary and it is not sufficient. It has no authority over the maintainers of your dependencies.
In a classic web application the trust boundary sits at the request. In an AI-enabled system it has to be drawn around every content source the model reads, because retrieved documents, tool responses and persistent memory are now instruction-carrying channels. That single change reorders a methodology: the question stops being whether a filter can be bypassed and becomes what a bypassed model can reach, act on and spend.
Retrieved content, tool output, images, audio and intermediate reasoning are all inputs that can alter behaviour, so each becomes a channel to test rather than a data source to trust.
Authorization delegated to a model is a privilege-escalation test with a new front end: can the agent act outside the entitlements of the user who invoked it?
Availability failures become financial. Cost per request is now a security measurement, not a finance one.
Findings carry attempt counts and success rates, because a binary confirmed or not-confirmed verdict misrepresents a probabilistic system. A result that reproduces three times in ten is still a result, and reporting it as unconfirmed is a reporting failure rather than a testing one.
What an AI feature does not change
The deployed system is still a web application. Authentication, session management, tenancy isolation, secret handling, server-side request forgery from the tool layer, injection in output sinks and cloud identity configuration are still where the highest-severity findings usually live. Teams that reframe an AI project as an entirely new discipline routinely skip the coverage that would have caught the finding that actually mattered.
WSTG 4.2 scenario coverage and an ASVS 5.0.0 level target still define the baseline for the deployed application.
Cloud identity and entitlement review still finds the escalation path that no prompt ever needed to trigger.
Secret handling in the tool layer is ordinary appsec work with unusually high blast radius when an agent holds the credentials.
Output handling remains on the OWASP LLM list at LLM10 precisely because it is classic injection with a newly trusted source.
The correct scope is not a substitution. It is standard application coverage plus AI-specific coverage, priced and reported as two layers of one engagement.
Who performs the work, and under what authority
Testing is led by a named security architect on the IntuitionLabs expert bank rather than by an anonymous pool, and the named tester appears in the engagement documents before work begins. Every engagement runs under a signed authorization letter that scopes exactly what may be touched, against systems the client owns or is explicitly authorized by the owner to test. Professional liability and cyber insurance are in force.
An independent consultant with seventeen years in information security, named to you in the engagement documents.
A decade on the central security team of a major enterprise infrastructure vendor, serving every business unit: design and architecture review, security requirements review, source code review, penetration testing and vulnerability response.
Several years of prior client-facing security consultancy, leading mobile penetration testing for Android and iOS.
A postgraduate degree in computer science with a security specialisation, multiple US patents in security engineering, and a peer-reviewed publication record.
A named specialist on the IntuitionLabs expert bank, not an IntuitionLabs employee.
Code that IntuitionLabs wrote is reviewed by someone who did not write it. That separation is stated in the engagement scope rather than assumed.
Testing an AI-enabled application
The frameworks in this area changed twice in the last twelve months, and most published content in the market predates both changes. Naming the current lists correctly is not pedantry; it is the difference between testing against the 2025 threat model and the 2026 one.
Current frameworks
The OWASP LLM Top 10 changed on 4 August 2026
The OWASP Top 10 for Large Language Model Applications 2026 was released on 4 August 2026 by the OWASP GenAI Security Project and supersedes the widely circulated 2025 list. If a provider is still quoting LLM06 Excessive Agency or LLM07 System Prompt Leakage, they are describing last year’s document.
The current identifiers are LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Excessive Agency, LLM04 Supply Chain, LLM05 Data and Model Poisoning, LLM06 Unbounded Consumption, LLM07 Misinformation, LLM08 Hidden Context Exposure, LLM09 Vector and Embedding Weaknesses and LLM10 Improper Output Handling. Excessive Agency made the biggest climb, from sixth to third. Unbounded Consumption rose four places from tenth to sixth. Hidden Context Exposure is the renamed System Prompt Leakage entry. Improper Output Handling fell the furthest, from fifth to tenth, which says more about relative frequency than about the class becoming safe.
The methodology behind the ranking is worth citing because it is unusually transparent. The list "combines community judgment with analysis of real-world incidents", with the community vote carrying three-quarters of the weight and the remaining quarter drawn from 7,714 real incidents in public vulnerability databases and an AI-harm database. The 2026 edition also maps its risks to NIST, MITRE ATLAS, CWE and the OWASP Top 10 for Agentic Applications, which makes it usable as a cross-reference rather than as a standalone list.
The Agentic list is the second recent change and it is the one most content in this space predates entirely. The OWASP Top 10 for Agentic Applications was published on 9 December 2025 with more than a hundred industry contributors: ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities, ASI05 Unexpected Code Execution, ASI06 Memory and Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation and ASI10 Rogue Agents. Its predecessor and companion is the Agentic AI Threats and Mitigations guide, version 1.0, dated 17 February 2025.
The test object is blast radius, not the guardrail
The most important sentence for anyone buying this service is OWASP’s own, from the 2026 prompt injection entry: "prompt injection is intrinsic to current generative AI" and "no reliable prevention mechanism exists today". Read that as a procurement instruction rather than as a warning.
OWASP’s 2026 definition is broader than most people’s mental model. A prompt injection vulnerability occurs when input to a large language model, "whether direct user input, retrieved content, tool output, image, audio, or video content, intermediate reasoning, or persistent memory, alters the model’s behavior in ways the application developer did not intend". Direct injection is a user supplying the input. Indirect injection is the model ingesting external content from "web pages, documents, emails, tool responses, RAG passages, images, or MCP servers" that acts as an instruction without the user’s knowledge or visibility. The seminal academic treatment is Greshake and colleagues, published February 2023, which showed that processing retrieved prompts can manipulate an application’s functionality and "control how and if other APIs are called".
The architectural consequence is what a penetration test should be verifying. OWASP’s guidance is that systems should assume "the model’s instruction boundary will eventually be bypassed" and constrain what a compromised model can do and reach. So the test object is the blast radius, not the guardrail. A provider who sells "we will prove your prompt filter cannot be bypassed" is selling a test they will always win and a client will always lose, because a filter that survives one tester for one week has not been shown to survive anything.
The market has already supplied the confirming evidence. When Zenity Labs disclosed the AgentFlayer chains on 6 August 2025, affecting connectors and agent platforms across several major vendors, the reported outcome was that "multiple vendors declined to address the vulnerabilities, citing them as intended functionality." That response is not evasive; in several cases it is accurate. An assistant that reads a document and acts on what it says is doing the thing it was built to do. Which is exactly why a test that only asks "is this a bug in the product" returns nothing useful, and a test that asks "what can this reach, and what would it cost us" returns findings the client can act on without waiting for a vendor patch that is never coming.
In practice this means the engagement measures containment. What can the model reach with the credentials it holds? Which tools are registered and which of them change state? Whose entitlements apply when a tool executes? What happens to the output, and which downstream sink trusts it? How much can a single request cost, and what stops the tenth thousand? Those questions have answers that stay true after the next model update. "The filter held" does not.
A guardrail is a control worth having and a poor thing to test. Test what survives the guardrail failing, because OWASP says it will.
Excessive agency, tool abuse, and authorization delegated to a model
LLM03:2026 frames agency as something a developer grants: "the ability to call functions or interface with other systems via tools to undertake actions in response to a prompt". The vulnerability is damaging action arising from "unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction". That last clause is the one to notice. The defect exists whether the trigger is an attacker or an ordinary hallucination.
OWASP names three root causes: excessive functionality, excessive permissions and excessive autonomy, the last defined as an application or tool that "fails to independently verify and approve high-impact actions". The prescribed controls are conveniently also the testable assertions. Limit the tools an agent may call "to only the minimum necessary". "Execute tools in user’s context." Require user approval for consequential operations. And enforce authorization "through logic rather than relying on the LLM’s judgment".
That final control describes the finding that recurs most in real assessments: an authorization decision delegated to a probabilistic component. It is an insecure direct object reference or a privilege escalation with a conversational front end, and it is testable in the ordinary way. Can the agent read a record the invoking user cannot? Can it write to a system the invoking user has no role in? Does the tool run with a service identity that is broader than any human user, and if so, what constrains it?
Related agentic techniques now appear as first-class entries in MITRE ATLAS, which is the adversarial knowledge base for AI systems and currently documents 16 tactics, 178 techniques, 37 mitigations and 68 case studies, filtered by platform across Predictive AI, Generative AI, Agentic AI and Enterprise. Techniques such as AI Agent Tool Poisoning, AI Agent Context Poisoning, AI Agent Tool Credential Harvesting and Exfiltration via AI Inference API give a test plan concrete, referenceable identifiers rather than adjectives.
There is a related measurement problem that a test has to account for, because it changes what evidence means. Pen Test Partners, publishing in May 2025 on Copilot for SharePoint, reported that agent-mediated reads do not appear where auditors look: "we will not show up in the standard 'accessed by' or 'recent files' logs shown by SharePoint." If your assurance that an assistant has not touched a sensitive library rests on that surface, the assurance is worth less than it appears. Under HIPAA, 45 CFR 164.312(b) requires audit controls that "record and examine activity in information systems that contain or use electronic protected health information", so a gap of this kind is a finding in its own right rather than a footnote, and the report should name the log surface that does record the activity.
One observation from our own work, stated no larger than it is: at a clinical-stage biotech client, during a first engagement, connected AI reached employee-information files in Box through existing user permissions. Nothing was bypassed. The assistant simply inherited what the user could already open, and nobody had looked at the aggregate of that until someone asked the question directly.
Excessive functionality
Tools registered because they were available rather than because the workflow needs them. Every registered tool is attack surface.
Excessive permissions
A service identity broader than any human user, usually created to make an integration work during a pilot and never narrowed.
Excessive autonomy
High-impact actions executed without independent verification or human approval, in OWASP’s words a failure to verify and approve.
Delegated authorization
Entitlement decisions made by the model rather than enforced in code. The most common critical finding in agentic deployments.
Related evidence and next steps
MITRE ATLAS— Tactics, techniques and case studies for AI systems, now filtered by Predictive, Generative and Agentic AI.
Retrieval poisoning, output handling, and denial of wallet
Three classes deserve specific attention in a life-sciences deployment because the assets involved are unusual: a retrieval corpus of regulatory documents and standard operating procedures, output that flows into regulated records, and inference budgets that are new enough not to have owners.
On retrieval poisoning the canonical primary source is PoisonedRAG, by Zou, Geng, Wang and Jia, published February 2024 and described by its authors as "the first knowledge corruption attack to RAG". The headline measurement is the one to plan against: the method "could achieve a 90 percent attack success rate when injecting five malicious texts for each target question into a knowledge database with millions of texts", and the authors evaluated several defenses and found "they are insufficient". Translate that into a life-sciences setting and the risk is concrete: five crafted documents in a million-document index of SOPs, submissions and literature. The test question is not whether your corpus can be poisoned but who can write into it, through which ingestion path, with what review.
Improper output handling sits at LLM10:2026 and is the bridge between AI testing and classic application security. Model output flowing unescaped into a browser, a shell, a SQL statement, a template or a downstream API is the same defect class every tester already knows, with the twist that the untrusted input now arrives from a component the developer decided to trust. Every existing skill applies; only the source has changed.
Unbounded consumption, LLM06:2026, is the class with no analogue in classic web testing. OWASP defines it as occurring when an application "allows excessive and uncontrolled inferences, enabling attackers to disrupt service availability, inflict unsustainable financial costs, or steal intellectual property through model cloning", and it names Denial of Wallet explicitly, where attackers exploit the cost-per-use model of cloud AI services "leading to unsustainable financial burdens on the provider and risking financial ruin". The defining property is cost asymmetry: attackers "trigger disproportionately expensive computation at negligible cost to themselves".
The controls OWASP names are the ones a test can verify. Non-overridable budget ceilings "per API key, user, team, and cloud account" that halt inference when exceeded. Token-aware rate limiting on tokens per minute, tokens per day and estimated cost per request. Pre-flight cost estimation that rejects a request before inference rather than after. And agent circuit breakers: "step limits, recursion depth limits, time limits, and per-run cost ceilings on all agent executions". A deployment with none of these is one recursive agent loop away from a finance incident, and that loop does not require an attacker.
Related evidence and next steps
PoisonedRAG (Zou et al., 2024)— 90 percent attack success rate from five injected texts, with evaluated defenses found insufficient.
Governed information layer— Who can write into a retrieval corpus, and through which reviewed ingestion path.
Method
Six structural differences that change how the test is run
Taken together, the changes above are not a longer checklist. They alter the methodology, the reporting format and the remediation advice, and a provider who has not adjusted all three is running a web application test with an AI section appended.
The system is non-deterministic, so a finding may reproduce three times in ten. Reporting must state attempt counts and success rates rather than a binary verdict, which on its own breaks the standard CVSS-plus-reproduction-steps format. There is no patch for the top-ranked vulnerability, so remediation guidance has to be architectural: privilege reduction, human in the loop, output containment, and segmentation of trusted from untrusted context, not "sanitise the input".
The trust boundary has moved into the data, which is why ATLAS now enumerates context and tool poisoning as techniques rather than as scenarios. Identity and authorization are partly delegated to a stochastic component, which converts a governance concern into an ordinary escalation test. Availability failures are financial rather than operational, so cost per request becomes a security measurement. And the supply chain now includes models, weights, datasets, adapters and MCP servers, which is why an AI bill of materials is part of the deliverable rather than an optional extra.
What does not change is the majority of the work. The deployed system is still a web application, and the highest-severity finding in an AI engagement is frequently an ordinary one: a misconfigured cloud role, a tenancy boundary that leaks, a secret in a build artefact, a request forgery reachable from the tool layer. The right scope is WSTG and ASVS coverage of the deployed system plus LLM and agentic coverage, priced and reported as two layers of a single engagement rather than as a substitution.
AI Acceleration Program— The programme that puts governed AI workflows into a department, with testing as one control among several.
Life sciences: testing a validated system without invalidating validation
A penetration test against a validated GxP system is, by construction, an attempt to defeat two of its regulatory controls. 21 CFR 11.10(d) requires "Limiting system access to authorized individuals." and 11.10(g) requires "Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand." Those are security requirements, and they are exactly what a test probes.The tension is real. An active test writes to the same audit trail that 11.10(e) requires be "secure, computer-generated, time-stamped" and non-obscuring of previously recorded information, and the EU GMP Annex 11 in force since 30 June 2011 requires at clause 12.1 that "Physical and/or logical controls should be in place to restrict access to computerised system to authorised persons.", at 12.3 that "Creation, change, and cancellation of access authorisations should be recorded.", and at clause 9 that audit trails be "available and convertible to a generally intelligible form and regularly reviewed". Turning the trail off for the duration of a test is not an option that exists.The 2025 consultation draft of Annex 11 matters more to this service than most commentary suggests, and for a different reason than the commentary claims. It grows to seventeen sections and adds a dedicated section 11 on Identity and Access Management, whose stated principles are segregation of duties and least privilege, "i.e. that users do not have higher access privileges than what is necessary for their job function" (draft 11.10), plus recurrent access reviews at 11.11 designed "in order to detect accesses which should have been changed or revoked during daily operation, but were accidentally forgotten." A new section 15 on Security requires that "Regulated users should ensure an effective information security management system is implemented and maintained, which safeguards authorised access to, and detects and prevents unauthorised access to GMP, systems and data." Draft section 7.5 on supplier contracts also secures "the process for release of new system versions and on the regulated user's possibility to test these prior to release", which is the cleanest contractual hook there is for recurring security testing of a vendor-supplied GxP system. All of that is draft text under a consultation that closed on 7 October 2025, with no final version published as of late August 2026.A correction worth stating plainly, because it circulates widely: the draft Annex 11 does not introduce AI rules. A full-text search of the consultation PDF returns zero occurrences of AI, artificial intelligence or machine learning. The AI content is in the separate draft Annex 22, which describes itself as "additional guidance to Annex 11 for computerised systems in which AI models are embedded." Its scope statement is unusually direct and every vendor selling AI into GMP manufacturing should read it: dynamic models that "continuously and automatically learn and adapt performance during use" are "not covered by this document, and should not be used in critical GMP applications", the same is said of probabilistic models, and therefore "the document does not apply to Generative AI and Large Language Models (LLM), and such models should not be used in critical GMP applications." In non-critical applications it requires that qualified personnel remain responsible for output suitability, "i.e. a human-in-the-loop (HITL)". Again: draft, scoped to the manufacture of medicinal products and active substances, and not a ban on LLMs in pharmaceutical companies. It is currently the clearest regulatory signal on record, and it changes where an AI feature may sit rather than whether it may exist.Two boundary errors are worth correcting because a device-industry reader will notice both. First, FDA's premarket cybersecurity guidance, reissued 3 February 2026, attaches to a cyber device under FD&C section 524B. Legal analysis of the revision reports that it recommends manufacturers conduct extensive cybersecurity testing including vulnerability and penetration testing, and that it was issued as a Level 2 guidance aligned to the Quality Management System Regulation, which incorporates ISO 13485:2016. It does not govern a pharmaceutical company's enterprise or manufacturing IT. For those systems the drivers are Part 11, Annex 11, the HIPAA Security Rule where protected health information is involved, with risk analysis and risk management as Required implementation specifications at 45 CFR 164.308(a)(1) and an Evaluation standard at 164.308(a)(8), plus customer diligence. HHS issued a Security Rule notice of proposed rulemaking on 27 December 2024 and states that the current rule remains in effect while that rulemaking proceeds; we do not quote a proposed testing cadence from it because we could not verify one in the rule text.Second, ANSI/AAMI SW96:2023 does not supersede AAMI TIR57. The standard covers security risk management for medical device manufacturers within the ISO 14971 safety risk management process, and its own scope statement says it "is intended to be used in conjunction with AAMI TIR57 and AAMI TIR97." Several widely-read summaries state the opposite. Adjacent standards worth naming correctly are ANSI/AAMI/IEC 62304 for medical device software lifecycle processes, in which security is not the subject, and IEC 81001-5-1:2021, which adds security activities to that lifecycle.Our recommended operating model for testing a validated system, which is industry practice rather than a regulatory requirement, has six parts. Split the test by state-change risk. Raise a change control record for the test itself, with an impact assessment concluding whether any planned activity touches a GxP-critical function or data path; the assessment, not the test, is the regulatory artefact. Use seeded test data and test accounts only. Pre-agree how test-account activity is annotated in the audit trail so a future inspector reads a documented authorized activity rather than an anomaly. Route findings into the existing deviation and CAPA process rather than into a parallel security backlog. Retest under the same change control and keep the attestation with the validation package.The mindset that makes this acceptable to a quality organisation is the one GAMP 5 Second Edition describes: critical thinking by knowledgeable subject-matter experts, proportionate to risk, rather than uniform document-heavy validation. We have not reproduced text from the ISPE guide, which is paywalled, and we do not quote what we have not read. If your validation lead wants the operating model written into an SOP before any testing begins, that is the right instinct and we work that way by default. See our computer system validation practice for the validation side of the same problem.
The test is raised as a change with an impact assessment. That assessment is the inspectable artefact, not the tester’s notes.
Seeded data only
No real batch records and no subject data as evidence, ever. Proof of access is demonstrated with redacted artefacts.
Findings into CAPA
Security findings enter the quality system. A parallel security backlog is not actionable or defensible at inspection.
Which instrument actually asks for penetration testing
Three errors are repeated constantly in this market: treating FDA premarket guidance as if it governed pharmaceutical enterprise IT, treating a draft as a requirement, and claiming the draft Annex 11 introduces AI rules. All three are corrected below.
Instrument
What it says about security and testing
What it does not cover
21 CFR Part 11 (11.10)
Requires validation, "Limiting system access to authorized individuals" at 11.10(d), authority checks at 11.10(g), and "secure, computer-generated, time-stamped audit trails" at 11.10(e). Does not name penetration testing.
It sets no testing cadence and prescribes no method. It makes the authorization model testable, not the test mandatory.
EU Annex 11 (2011, in force)
Clause 12.1 requires physical or logical controls restricting access to authorised persons, 12.3 requires creation, change and cancellation of access authorisations to be recorded, and clause 9 requires audit trails to be available and regularly reviewed. Mirrored by PIC/S PE 009 Annex 11.
It contains no explicit periodic penetration testing expectation, and no AI provisions of any kind.
Draft Annex 11 (consultation 7 Jul to 7 Oct 2025) — DRAFT ONLY
Adds a dedicated section 11 Identity and Access Management built on segregation of duties and least privilege, "i.e. that users do not have higher access privileges than what is necessary for their job function", with recurrent access reviews at 11.11. A new section 15 Security requires an effective ISMS that safeguards authorised access and detects and prevents unauthorised access. Section 7.5 secures the regulated user’s "possibility to test these prior to release" for new system versions.
Not in force and no final text published as of late August 2026. It contains zero occurrences of AI, artificial intelligence or machine learning; summaries claiming otherwise are wrong. It does not itself mandate penetration testing.
Draft Annex 22 on Artificial Intelligence — DRAFT ONLY
A separate draft annex, "additional guidance to Annex 11 for computerised systems in which AI models are embedded". Scoped to static, deterministic models. States that "the document does not apply to Generative AI and Large Language Models (LLM), and such models should not be used in critical GMP applications", and requires a human in the loop for non-critical use.
Also a draft, scoped to manufacture of medicinal products and active substances, and not a ban on LLMs across a pharmaceutical company. It creates no penetration testing obligation on its own.
FDA premarket cybersecurity guidance (3 Feb 2026)
Applies to a cyber device under FD&C section 524B. Legal analysis of the revision reports that it recommends extensive cybersecurity testing including vulnerability and penetration testing, plus threat modeling and an SBOM. Issued as a Level 2 guidance aligned to the QMSR, which incorporates ISO 13485:2016.
It does not govern pharmaceutical enterprise or manufacturing IT, non-device clinical trial software, or LIMS and ELN platforms unless separately devices. Saying "FDA requires penetration testing" without that boundary is simply wrong.
HIPAA Security Rule
Access control at 45 CFR 164.312(a)(1) permits access "only to those persons or software programs that have been granted access rights", which already contemplates an assistant or connector as an access holder. 164.312(b) requires audit controls that record and examine activity. 164.308(a)(4)(ii)(C) requires a covered entity to "establish, document, review, and modify a user’s right of access".
The rule does not use the words penetration testing. A December 2024 NPRM proposes updates and remains proposed; we do not state a testing cadence from it because we could not verify one in the rule text.
ANSI/AAMI SW96:2023
Security risk management for medical device manufacturers, in the context of the ISO 14971 safety risk management process. Recognised by FDA on 7 November 2023.
It does not supersede AAMI TIR57. ANSI’s own listing states it "is intended to be used in conjunction with AAMI TIR57 and AAMI TIR97". Several widely-read summaries get this backwards.
What you receive from a scoped engagement
Six artefacts, agreed in the test specification before work starts. The report is written for two audiences in the PTES sense: an executive section that answers whether the posture is adequate against the agreed objectives, and a technical section a developer can act on without a follow-up call.
A written test specification
Scope, exclude list, permitted activity classes, window, halt criteria, evidence rules, and the standard coverage will be measured against. Signed before testing, and the reference point if scope changes later.
CVSS v4.0 base score with correct nomenclature for comparability, an environment-adjusted rating with the reasoning shown, and a business impact statement in your terms rather than in confidentiality-integrity-availability language.
PTES distinguishes a systemic issue such as a missing patch management process from a symptomatic one such as a single missing patch on a single host. Reports that only list symptoms are scanner output with prose.
Borrowed from the OSSTMM Security Test Audit Report: an explicit section on what was in scope, what was excluded, and what was not reached. It is the section that tells you what you still do not know.
How individually low-severity findings compose into a high-severity outcome. NIST describes this as combinations of vulnerabilities giving more access than any single one, and it is usually the finding that changes a decision.
Per finding: original identifier, remediation claimed, what was re-executed, and the verdict of fixed, partially fixed, not fixed, or risk accepted with a named acceptor. This is the artefact diligence packages actually ask for.
Questions buyers ask about penetration testing and code review
The scope is decided jointly and written down before any testing occurs, because the phrase has no agreed industry meaning. CREST, the accreditation body that has been assessing penetration testing providers since 2006, states plainly that the phrase "lacks clear definition, and is often misunderstood" and that there is "significant definitional misalignment between buyers and service providers." We therefore begin every engagement with a written test specification: the assets in scope, the assets explicitly excluded, the classes of activity permitted, the testing window, the halt criteria, the evidence rules, and the standard the coverage will be measured against. If two providers quote very different prices for "a penetration test", the difference is almost always in that document rather than in skill.
Both, split by state-change risk. NIST SP 800-115 is candid that penetration testing "poses a high risk to the organization’s networks and systems because it uses real exploits and attacks against production systems and data", and it recommends that a test can be designed to stop when an additional action would cause damage. Read-only work such as reconnaissance, transport and header configuration, authentication flows against seeded test accounts, authorization matrix analysis and session handling can usually run against production with negligible risk to a validated state. Anything that writes, uploads, changes configuration or attempts exploitation belongs in a qualified mirror built to the same specification. That split is a recommendation of ours, not a regulatory requirement, and it is agreed in the rules of engagement rather than improvised during the test.
A signed authorization letter that names the systems and areas in scope, names the exclude list, names the window, and is signed by someone with actual authority to grant it. We test only systems the client owns or is explicitly authorized by the owner to test. This is not paperwork for its own sake. In Van Buren v. United States the Supreme Court read the Computer Fraud and Abuse Act so that a person exceeds authorized access when they obtain information from areas of a computer that are off-limits to them, which means the boundary that matters is the technical access boundary rather than anyone’s stated intent. The Department of Justice’s 2022 charging policy for good-faith security research is a useful backstop, but it binds federal prosecutors only, has no effect on civil liability or state law, and is not a substitute for written permission. Nothing here is legal advice; your counsel should review the engagement documents.
They are different services with different objects and we say which one you actually need. AI red teaming examines model behaviour: jailbreaks, refusal robustness, harm categories, misuse potential. AI application penetration testing examines the deployed system: the application, its APIs, the tool layer, the retrieval pipeline, identity and entitlements, cloud configuration and data stores. OWASP’s own GenAI Red Teaming Guide scopes red teaming across model evaluation, implementation testing, infrastructure assessment and runtime behaviour analysis, which is exactly why the terms collapse into each other in the market. We perform AI application penetration testing and secure code review, and we incorporate adversarial model probing where it produces a security finding in the deployed system rather than a model-safety observation.
No single test satisfies a regulation, but two Part 11 clauses put an application’s authorization model squarely inside the scope of a test. 21 CFR 11.10(d) requires "limiting system access to authorized individuals" and 11.10(g) requires authority checks so that only authorized individuals can use the system, sign records, access input or output devices, or alter a record. A penetration test is, by construction, an attempt to defeat exactly those two controls, which is why it produces evidence a quality organisation can use. It does not replace validation, and it does not by itself demonstrate compliance. The regulatory artefact is the change control record and impact assessment covering the test, plus the routing of findings into your existing deviation and CAPA process.
Only for cyber devices, and this distinction is widely got wrong. FDA’s premarket cybersecurity guidance, reissued 3 February 2026, attaches to section 524B of the Federal Food, Drug, and Cosmetic Act, which applies to a device submitted to the agency. Legal analysis of that revision reports that it recommends manufacturers conduct extensive cybersecurity testing including vulnerability and penetration testing, alongside threat modeling and a software bill of materials. It does not govern a pharmaceutical company’s enterprise or manufacturing IT, clinical-trial software that is not a device, or research platforms and LIMS or ELN systems unless they are separately devices. For those systems the drivers are Part 11, EU Annex 11, HIPAA where protected health information is involved, ISO/IEC 27001 where a customer demands it, and partner diligence.
Both are drafts and neither is in force. The European Commission opened consultation on 7 July 2025, closing 7 October 2025, on a revised EudraLex Volume 4 Chapter 4, a revised Annex 11 on computerised systems, and a new Annex 22 on artificial intelligence; as of late August 2026 no final text has been published. The draft Annex 11 grows to seventeen sections and adds a dedicated section 11 on Identity and Access Management, whose guiding principles are segregation of duties and the least privilege principle, that "users do not have higher access privileges than what is necessary for their job function", plus recurrent access reviews at 11.11 intended "to detect accesses which should have been changed or revoked during daily operation, but were accidentally forgotten". A new section 15 on Security requires an effective information security management system that safeguards authorised access and detects and prevents unauthorised access. Section 7.5 on supplier contracts includes the regulated user’s right to test new system versions prior to release. One correction worth making loudly: several consultancy summaries describe the Annex 11 draft as introducing AI rules. A full-text search of the consultation draft finds zero occurrences of AI, artificial intelligence or machine learning. The AI content sits in the separate draft Annex 22.
OWASP makes the argument better than any vendor could. Its community page on source code analysis tools states that current static analysis tools "can automatically identify only a relatively small percentage of application security flaws", produce high numbers of false positives, and are frequently unable to find configuration issues because those are not represented in the code. The same page lists authentication problems, access control issues and insecure use of cryptography among the weaknesses these tools do not find. Those three categories are where the highest-severity findings in a business application usually live. A manual review targets exactly what the scanners concede: authorization logic, business-logic abuse, cryptographic misuse in context, tenancy boundaries, trust decisions across service boundaries, secret and key lifecycle, and in AI systems the question of what a tool call may do on whose behalf.
Yes, because your policy governs only the code your own people write. Three paths bypass it entirely. First, package hallucination: a USENIX Security 2025 study generated 576,000 code samples across sixteen models and found hallucinated package names in at least 5.2 percent of commercial-model outputs and 21.7 percent of open-source-model outputs, cataloguing 205,474 unique fake package names. Once an attacker registers one of those names it becomes a real package, and software composition analysis cannot see the problem because the dependency legitimately exists. Second, your dependency tree is written by maintainers whose AI adoption rate you neither set nor observe. Third, models, weights, adapters, prompt libraries and MCP servers are now dependencies with no equivalent of a CVE feed. The answers are bill-of-materials completeness, dependency provenance, registry hygiene and human review of what a dependency actually does, none of which are AI-policy questions.
Findings carry CVSS v4.0, which has been the current version since November 2023, and they carry an explanation of what that number does and does not mean. FIRST’s own user guide contains the heading "CVSS Base Score (CVSS-B) Measures Severity, not Risk", and the same guide requires the CVSS-B, CVSS-BT, CVSS-BE and CVSS-BTE nomenclature to be used wherever a numerical score is communicated. So you receive the base score for comparability, an environment-adjusted score with the reasoning shown, and a plain-language business impact statement in your own terms: batch release, submission timeline, patient safety, regulatory exposure. The deliverable also separates systemic root causes from symptomatic instances, states what was not tested, and closes with a retest attestation per finding.
Testing is led by a named security architect on the IntuitionLabs expert bank rather than by an anonymous pool. For this service line that is an independent consultant with seventeen years in information security, including a decade on the central security team of a major enterprise infrastructure vendor doing design and architecture review, security requirements review, source code review, penetration testing and vulnerability response, and earlier client-facing consultancy work leading mobile penetration testing. The specialist is a member of our expert bank rather than an IntuitionLabs employee, and the named tester appears in the engagement documents before work begins.
No. IntuitionLabs is not an auditor and not a certifying body, and we do not issue certifications. IntuitionLabs itself does not hold SOC 2 or ISO/IEC 27001, and we will not imply otherwise on a security page. What we produce is a penetration test report and a retest attestation, which is the artefact that customer security questionnaires and partner diligence packages ask for: a current third-party test, dated, with scope stated and remediation status per finding. If your objective is a certification, we can prepare you for the audit and help you assemble evidence, and an accredited body performs the audit. Professional liability and cyber insurance are in force for our engagements; we do not publish coverage amounts or carrier names.
Start with the Test Specification
Bring the system, the environment, the regulatory context and what you need the report to prove. We will write the scope, the exclude list and the halt criteria with you before anyone quotes a price. Testing proceeds only under a signed authorization letter against systems you own or are explicitly authorized to test. See also our own security posture and Trust Center, and the Part 11 software development practice for systems still being built.
