Aikido Security's AI Pentesting fits into the stack you already run. Even if you're committed to your current code and cloud security tools, you can add AI pentesting on top to catch the complex logic flaws deterministic tools miss.
If you're looking to get deeper engagements with your pentesting, or test every release, you might be looking for a solution beyond contracting manual pentesters. When First National Bank of America needed to pentest a new customer portal on a deadline, its team had an Aikido AI pentest running in less than a day. The test finished in 1 hour and 40 minutes and found a high-severity issue, which the bank fixed before the portal went public. Because each test takes hours, teams can run one whenever the application changes, and every test produces an audit-ready report. Readers still choosing a vendor should check out the AI Pentesting Buyer's Guide, but if you're seriously considering Aikido, read on.
{{cta}}
What you need to run an Aikido AI Pentest #
Optional but encouraged: Whitebox testing (giving an AI pentest access to connected repositories) finds more vulnerabilities than blackbox testing for the same amount of credits. Aikido Infinite (continuous pentesting) pentests the diffs on new deploys.
Start with one pentest #
You don't need to adopt any other Aikido product to run a first pentest, and every tool already in your stack can stay exactly where it is. For web application and API pentesting, most of the setup comes down to two decisions: which application you want tested and which of its domains are in scope.
We recommend pointing the pentest at a staging or pre-production environment that mirrors production but uses test data. That keeps testing isolated from your live application and lets the agents exercise it fully without risk to real users or data.
Aikido also asks you to give the agents login credentials and an account for each user role, such as a standard user and an admin, and they can work through the protected areas of the application and check whether one role can reach data that belongs to another. Without credentials, the test only sees what an anonymous visitor would.
Connecting your repositories is optional, but it changes what the test can find. Whitebox testing, with source code access, is far more thorough than tests without; across more than 1,000 pentests, whitebox testing uncovered 7x more vulns than greybox testing.
This depth has been borne out in Aikido's customer experience as well. First National Bank of America started its first pentest within a day of deciding to use Aikido, and the bank's Identity & Access Management engineer credited the white-box approach for the impact of the results, since the agents had the context of every repo.
“Being able to have Aikido look at our repositories and have that context gave us really good remediation tasks. Having that backend information, you’ll get much deeper findings...We found [a high-severity vulnerability] before it was in production. That’s a clear value for us.”
The setup docs walk through each assessment and access option in detail.
Choosing what to pentest #
Pentesting terms get used loosely, so it helps to start from what you want tested and work back to the name.
If you want to test on every deploy, add continuous pentesting with Aikido Infinite #
For those orgs that require continuous testing, Aikido Infinite can keep pentesting continuously as the application changes. It uses the last full assessment as its baseline and watches the branches you configure. When a change looks security-relevant, it launches targeted agents, either on deploy or on a schedule you set. Before switching it on, confirm that the right people have permissions, that the branches or schedule match how your team ships, that the agents can still reach the application, and that you have enough credits for the testing you expect. Repositories need to be connected too, since Infinite reads them to work out which changes need testing.
How to integrate AI pentesting results into your security workflow #
Your SAST and SCA tools keep doing what they do, flagging risky code and vulnerable dependencies. The pentest answers a different question, which is what an attacker can actually exploit in the running application. That includes flaws static analysis can't see, like broken access control, or the e-signature forgery Aikido's agents found in a document-signing app that a manual team missed.
Each finding is validated by additional agents to rule out false positives and confirm exploitability, so pentest results can go straight to the top of the queue without a manual triage pass. Every finding also ships with a proof-of-concept and reproduction steps, which means a developer can confirm the issue without going back to the security team for context. Findings arrive with a severity rating and an estimated time to fix, which let the team set priorities and hand remediation directly to developers.
How to remediate and retest AI pentest findings #
A pentest feeding an overloaded backlog just adds to the pile, so decide where findings go and who owns them before the first run. In a simple setup, the team creates a work item in its existing tracker for each finding, links it to the Aikido finding, and assigns it to the developer who owns the affected code.
The fix then goes through your normal code review and gets deployed to the test environment, where the finding is retested. Retest results give you evidence the issue is gone, which a merged pull request alone can't prove. If you want automatic ticket creation or status syncing, try it with a real pentest finding before rolling it out across teams. The pentesting in CI/CD walkthrough covers this flow end to end.
What to decide before your first AI pentest #
- Scope: For web applications and API pentests, (we will cover other domains in a future piece) start by listing what you need tested, which usually means specific applications, servers, APIs, and the user roles that access them. Including each role matters, because many of the most serious findings, like one user reaching another user's data, only show up when the test can log in as more than one kind of user. You'll also need to decide whether to include your whole internet-facing perimeter or keep the first test focused on a single application.
- Access: An AI pentest can only test what it can reach, so it needs credentials for every role in scope. You'll also decide whether to connect source code. With code access, the test can trace a finding back to the exact file and line, which makes the fix faster. Without it, the test works the way an outside attacker would, from the running app alone.
- Cadence: A one-off pentest gives you a point-in-time picture, which is often what an auditor or a customer's security review asks for. Continuous testing tied to deployments checks each release as it ships, so a new endpoint gets tested before it's been live for months. The right choice depends on how often your app changes and who's asking for the results.
- Ownership: Decide who configures tests, who sees findings, who can request retests, and who approves fixes before the first results come in. Pentest findings often cross team lines, so settling this upfront keeps a critical result from sitting unread because everyone assumed someone else had it.
- Cost: Pricing depends on the number of assessments you run or how much continuous testing you use. Because it's based on usage, you can rightsize it to the scope you've chosen and adjust it as that scope changes. Check currentpentest pricing for the details.
Aikido AI pentesting for web applications and the rest of the Aikido Security platform #
An AI Pentest of a web application is one of the ways Aikido Security uses autonomous agents to surface vulnerabilities, and each one tests something the others structurally can't. The best results come from layering them, so each one runs where it's cheapest and most useful.
SAST as the default: Deterministic SAST runs on every commit and in the IDE, flagging known patterns like injection the same way every time. It's fast and cheap enough to gate your CI/CD pipeline, which makes it the baseline everything else builds on. It can't reason about intent, though, so logic flaws like IDORs and broken access control are left to the layers above it.
Code Security Audit for new apps and major releases: Code Security Audit reasons across the whole codebase, tracing a request from the route handler down to the database query and asking whether the code does what it's supposed to. It only needs access to the repo, so it finds logic flaws before there's a live target to test against, including code behind feature flags and admin-only routes a pentest may never reach. That makes it the natural first step on a new application or ahead of a major release.
Deep PR Review to keep up between releases: Deep PR Review applies the same reasoning to every pull request, checking how each change interacts with code elsewhere in the repository and in linked repos. It catches the logic flaws that would otherwise turn up in the next pentest or in production, while the developer who wrote the change still remembers why they wrote it that way.
AI pentesting on a cadence that matches your risk: The pentest validates all of this against the running app, and scope is enforced through technical controls that keep agents on allow-listed targets and out of production unless it's deliberately set in scope.
How often you run it depends on your regulatory requirements and how sensitive your industry is. Most teams test yearly or with major releases, often to satisfy SOC 2 or ISO 27001. Teams in regulated or high-risk sectors that need exploitability checked as their app changes use Aikido Infinite, which tests on every deploy, and Aikido Machine runs the same pentests on-prem for industries where code can't leave your network. External network pentesting covers every internet-facing under your domain.
Findings feed straight into remediation. Where supported, AutoFix proposes code changes for pentest findings, and developers review and merge them, then retest to confirm the fix worked. Teams can start with AI pentesting alone and add the other layers later, as Tyro did when it brought the rest of its application testing onto Aikido alongside its pentests.
{{walkthrough}}