Agentic penetration testing for financial services: Closing the assurance gap

Why is penetration testing different for financial services?

Financial institutions often combine large application estates with high-consequence functionality.

Banks, payment providers, insurers, fintech companies, and investment firms depend on customer applications, payment services, administrative systems, partner integrations, and APIs. A vulnerability here might expose sensitive financial data, cross an authorization boundary, enable account takeover or fraud, or affect a financial transaction.

APIs make the problem especially visible. A payment workflow might span customer identity, account data, API calls, authorization decisions, transaction functions, and third-party services. A security control can work and test correctly at several points in that chain and still fail at another.

Open banking and fintech integrations extend these relationships beyond systems directly controlled by a single financial institution. The result is an application attack surface where identity, object ownership, privilege, application state, and third-party connectivity can all affect whether a request is legitimate.

A point-in-time penetration test cannot provide indefinite assurance over an application that continues to change – but applying manual testing at the cadence of modern software development is rarely practical across an entire portfolio. The resulting problem for modern AppSec in financial services is a mismatch between the depth, frequency, and coverage that different testing methods can provide.

Three levels of application security assurance

Closing that gap does not require choosing between automated and manual testing. It requires applying different levels of testing where they provide the most value.

DAST for breadth and repeatability

Dynamic application security testing (DAST) tests running applications and APIs from the outside, exercising them much as an attacker would. Mature DAST provides systematic testing for known vulnerability classes and can be repeated throughout development and against deployed applications. This makes DAST well suited to broad runtime coverage across an application portfolio.

For a financial institution responsible for hundreds or thousands of applications and APIs, this repeatable coverage is vital. Routine security testing cannot depend on securing scarce specialist time for every application release.

Agentic pentesting for adaptive depth

Some weaknesses need more than systematic, predefined security checks. An application-specific authorization flaw, for example, may require understanding relationships between users, objects, endpoints, privileges, and application state. Investigating it can mean following one observation into another and changing the testing strategy as new information appears.

Agentic pentesting brings adaptive reasoning into automated application security testing. Instead of following only a predetermined set of checks, AI agents can gather information about an application, plan an assessment, pursue promising leads, and adapt their next actions based on what they observe.

Invicti Agentic Pentest uses coordinated specialist agents for reconnaissance, planning, attack, and reporting. Agents share application context and can adapt their investigation as the assessment progresses. This agentic layer is grounded in Invicti’s DAST and runtime testing foundation rather than operating as an unrestricted AI attacker.

That gives agentic testing a distinct role: more adaptive than routine automated testing, while practical to apply more frequently than specialist manual engagements.

Human testing for specialist judgment

Human pentesters remain important where testing depends heavily on business context, unusual attack scenarios, specialist expertise, or independent judgment. They are also necessary where a formal exercise specifies requirements around methodology, independence, tester qualifications, or other conditions that cannot simply be assumed to be satisfied by an automated assessment.

The three approaches therefore solve different parts of the assurance problem. DAST provides breadth and repeatability. Agentic pentesting adds adaptive depth. Human testing provides specialist judgment where people are specifically needed.

Why agentic testing needs a runtime foundation

Giving an AI system more freedom to investigate the security level of an application is only practically useful if its conclusions can be trusted.

AI can investigate, but evidence has to decide

Agentic AI is well suited to forming hypotheses and choosing what to investigate next – but security teams should not have to deal with unproven hypotheses being reported as actual vulnerabilities.

That distinction is particularly important at enterprise scale. Every reported vulnerability can create work across AppSec, development, remediation, retesting, risk management, and potentially audit or compliance teams. An agentic system that only generates plausible findings without verification may soon create a manual triage bottleneck.

Runtime validation provides the grounding layer. Instead of treating the AI’s interpretation as the final answer, candidate vulnerabilities can be checked against the running application. The aim is to distinguish between something that looks vulnerable and behavior that can actually be demonstrated to be vulnerable.

DAST grounds agentic investigation in runtime evidence

This is where Invicti’s DAST-first approach makes a difference. Invicti combines agentic reasoning with established runtime security testing. AI agents can decide where adaptive investigation is useful, while runtime testing provides evidence about how the application actually behaves. This builds on the principle of using runtime evidence to separate potential issues from demonstrated risks, and it’s the reason agentic pentesting needs a DAST foundation.

For supported vulnerability types, Invicti’s proof-based scanning can safely confirm exploitability and provide technical evidence. Where used, it can move a finding from suspicion toward demonstrated exploitability. For agentic testing, the progression is straightforward:

Adaptive investigation → candidate vulnerability → runtime validation → actionable evidence

For financial services teams, that evidence can clarify what happened, guide remediation priorities, and help distinguish demonstrated weaknesses from risks that still require investigation. 

Bounded autonomy for financial applications

Deeper autonomous testing also raises an obvious question for financial institutions: how much freedom should an AI agent have against a live banking or payment application? The answer should not be unlimited autonomy.

Production fidelity versus production risk

Production testing provides high-fidelity information about deployed code, configuration, authentication, integrations, and application behavior. It can therefore reveal issues that are difficult to reproduce accurately elsewhere.

Financial applications also make the consequences of uncontrolled testing painfully clear. A request might modify customer data, interact with payment functionality, trigger fraud controls, invoke downstream services, send notifications, or affect application state. More aggressive testing could disrupt availability or create other operational risks.

Production can still be an appropriate testing environment, but not for every technique and test scope.

Putting hard boundaries around autonomous testing

The practical model is bounded autonomy: allow the system to adapt within enforceable technical and operational constraints. Relevant controls include authorized scope, testing identities and permissions, request-rate and concurrency limits, restrictions around sensitive data, minimum-impact validation, monitoring, execution limits, and stop conditions.

Invicti Agentic Pentest includes controls such as defined target scope, network-level scope enforcement, rate limiting, execution limits, role-based access control, isolated execution, and non-destructive payload design. More aggressive or potentially disruptive testing can remain in staging or other controlled environments.

The distinction between telling an agent what not to do and technically preventing it from doing so is especially important. Instructing an agent not to delete any files is a guideline but not a guarantee – unlike technically preventing write operations. This is one of many considerations for safe agentic pentesting in production.

For financial institutions, increasing testing depth and frequency with agentic tools is only feasible when the additional security assurance gained does not introduce disproportionate operational risk.

How to turn testing depth into a risk-based decision

The practical value of thinking about separate testing layers is most apparent when they are applied according to application risk rather than treated as competing alternatives.

Start with broad runtime coverage

DAST can provide repeatable baseline testing across web applications and APIs, both during development and against deployed systems where appropriate.

Attack surface visibility belongs at this layer as well. An unknown application or API cannot be deliberately tested, prioritized, or assigned a deeper level of assurance, which makes application and API discovery part of the coverage picture.

Trigger deeper testing from risk and change

Not every financial application warrants the same testing depth. Customer banking applications, payment services, authentication systems, transaction APIs, privileged administrative interfaces, and critical third-party integrations are obvious candidates for deeper assessment. Exposure, sensitive data, privileges, transaction capability, API connectivity, architecture, change velocity, and regulatory importance can all inform the decision.

Change can provide another useful trigger. If a bank substantially redesigns authorization for a payment API, waiting for the next scheduled manual pentest creates an avoidable assurance gap. An agentic assessment can provide deeper investigation directly after that change while routine DAST continues to supply broader coverage. The same principle can apply after major releases, new API integrations, authentication changes, or other events that materially alter application risk.

Reserve human expertise for where it adds the most value

Human-led testing can then concentrate on assessments where specialist judgment provides unique value: unusual financial business logic, complex attack scenarios, strategic red teaming, high-context investigations, and formal assessments with specific tester requirements.

By reducing the human effort required for each deep assessment, agentic testing can make it practical to extend deeper testing across more of the portfolio. The economics will vary with the application portfolio and testing model, but the broader opportunity is to extend deeper testing without scaling specialist labor at the same rate. Our analysis of the economics of agentic pentesting looks more closely at the tradeoffs between coverage, cost, human effort, and the respective roles of DAST, agentic testing, and manual pentesting. 

The resulting assurance model is layered:

• Continuous DAST for coverage
• Agentic testing triggered by risk or change
• Specialist human testing where required

A critical financial application may receive all three. The difference is that deeper assurance no longer has to wait exclusively for a place on the manual pentesting calendar.

Regulatory requirements and the role of agentic pentesting

To be clear, financial-sector regulation does not prescribe this three-layer architecture, but it does reinforce why testing programs need different forms, depths, and frequencies of assurance.

Regulatory applicability also varies by entity, system, and jurisdiction. The technology may be global, but the assurance model should not assume that requirements are freely interchangeable between different jurisdictions.

EU: DORA and TLPT

The EU Digital Operational Resilience Act (DORA) specifically requires financial entities other than microenterprises to establish, maintain, and review a risk-based digital operational resilience testing program. It identifies testing methods including vulnerability assessments and scans, source code reviews where feasible, scenario-based testing, end-to-end testing, and penetration testing. DORA also requires appropriate testing at least yearly for ICT systems and applications supporting critical or important functions.

DORA separately establishes threat-led penetration testing (TLPT) for financial entities identified under its criteria. Those entities must perform TLPT at least every three years, subject to adjustment by the competent authority, and the tests cover critical or important functions using live production systems that support them. The applicable regulatory technical standards add requirements covering areas such as scope, methodology, testers, results, closure, remediation, and supervisory cooperation.

Agentic application pentesting should therefore not be treated as a drop-in replacement for DORA-required TLPT. Its more natural role is to support broader security testing and assurance between formal exercises: testing high-risk applications more frequently, responding to significant application changes, and producing evidence that can support remediation and retesting.

US: Risk-based testing and sector requirements

The US financial sector does not have a direct equivalent of DORA’s harmonized EU framework. Requirements and supervisory expectations instead depend on the institution, regulator, state, system, and activity.

Federal Financial Institutions Examination Council (FFIEC) guidance on information security provides a useful example of the risk-based approach. It describes penetration tests as real-world attacks used to identify weaknesses in business processes and technical controls. The frequency and scope of penetration testing should reflect the level of assurance the institution needs, as determined through risk assessment. Vulnerability assessments can be continuous or periodic under the same risk-management logic.

The FFIEC’s newer Development, Acquisition, and Maintenance guidance also addresses governance, maintenance, change management, interconnected systems, third-party dependencies, and the need for secure and resilient services.

Other requirements may apply to particular institutions. For example, PCI DSS applies to relevant cardholder data environments rather than financial applications generally. For PCI DSS environments, significant changes can trigger security activities outside the normal periodic cadence. PCI Security Standards Council guidance gives examples including major software changes, changes to account-data flows or cardholder data environment boundaries, supporting infrastructure changes, and changes to relevant third-party services.

The exact obligation still needs to be assessed against a specific requirement. An automated or agentic assessment should not automatically be assumed to satisfy a formal penetration testing requirement simply because it performs offensive security testing.

Across these different regimes, the common principle is risk-based assurance: deeper testing should reflect the importance and changing risk of the systems being protected, while formal regulatory exercises retain their specific scope, methodology, independence, and evidence requirements.

Closing the gap between periodic pentests

The main limitation of periodic penetration testing is the amount of a changing application estate that any point-in-time process can cover.

DAST already allows financial institutions to apply runtime security testing broadly and repeatedly. Human pentesters provide expertise and judgment that remain essential for specialist scenarios and formal assurance. The remaining gap is deeper investigation for applications that change faster than manual testing capacity can follow.

Agentic pentesting can help fill that gap. Invicti’s approach combines adaptive AI agents with a DAST and runtime intelligence foundation. Agents can investigate application-specific attack paths, while runtime validation provides evidence for the vulnerabilities they identify.

For financial institutions, that creates a path toward a more continuous model of application assurance: broad DAST coverage across the application estate, deeper agentic assessments triggered by risk and change, and human expertise applied where specialist judgment or formal requirements call for it.

The real goal is to reduce the time between a meaningful change in application risk and the testing needed to understand it.

Learn more about Invicti Agentic Pentest, including how coordinated AI agents work with Invicti’s DAST and runtime validation capabilities. To explore how that model could fit into your application security testing program, get a demo.