Penetration_testing for AI-built software

Web application penetration testing services, proved by a human.

We read your source, test the running application, and prove every finding by hand before it goes anywhere near your report. You get something your auditor accepts, for a fraction of what a traditional assessment costs.

Book a scoping call See pricing

From $2,500 · Written quote first · Free retest included

Human-validated findings. Auditor-ready report. Free retest.

Why_this_exists >>

03_The_ask

Then someone asks for proof.

$5k–$50k

a customer questionnaire blocks the deal, the auditor wants evidence, the insurer wants a current test — and traditional pentests cost this much.

Proof, not promises.

KRYO pairs AI-assisted, source-guided analysis with a penetration tester who validates every finding before it reaches your report.

How_it_works

From scoping call to signed-off retest.

  1. Scope in 15 minutes

    A short call to agree what to test. You get a precise scope and a written quote before any commitment — and testing starts only with written authorization.

  2. Source-guided testing

    We analyze your application and its AI integrations, reading the source where you share it, and exercise them in operation. Source access reaches vulnerability classes that black-box scanning cannot.

  3. Human validation

    A qualified penetration tester reviews every finding: confirming exploitability, removing false positives, and prioritizing results by business impact.

  4. Report, fix, retest

    An auditor-ready report in plain English with remediation guidance tied to the affected code or endpoint. A complimentary retest verifies your fixes and documents closure.

Inside_the_test

What the testing actually does.

Most providers will not describe this part. Ours is worth explaining, because it is the reason every finding in your report is proven rather than suspected.

real browser · driven, not fetched

We use the application, not just read it

Testing runs a real browser and works through your application the way a person would — filling forms, following flows, changing state along the way. We drive it with Playwright and the Chrome DevTools protocol rather than downloading pages.

That matters more than it sounds. Most of a modern application does not exist in the HTML a crawler fetches; it is assembled in the browser afterwards. A tool that never runs the page never sees the thing it was sent to test.

dom · network · runtime state

We read what the browser knows

The DevTools protocol exposes the live DOM, the network traffic underneath it, and the state the application is holding at that moment. That is what our engine works from — the running application, not a snapshot of its markup.

  • Live DOM, inspected at depth rather than parsed
  • Requests and responses as they actually happen
  • State that only exists after you interact

agent fleet · open source · our engine

A fleet of agents works the surface

That input goes to a fleet of AI agents which reason over it: mapping what is reachable, and forming hypotheses about where a weakness is likely to be. They work alongside established open-source penetration testing tools and our own engine.

Breadth is what this buys. Agents cover more of an application, more consistently, than one person working against a deadline — and they do not get bored on the fortieth form.

proof required · human sign-off

Nothing counts until it is proved, then reviewed

A hypothesis is not a finding. For each candidate the agents construct a proof and attempt the exploit. Anything that cannot be demonstrated is dropped rather than passed to you as something to look into.

What survives goes to a qualified penetration tester, who reviews every finding, confirms the exploit is real, and sets severity and priority against your business rather than a generic table. That review is the last gate before anything reaches your report.

None of this replaces judgement about what is worth testing, and none of it makes coverage complete — no responsible provider claims that. What it means is that your report is short, and that everything in it is real.

One_engagement

What that found, in practice.

A recent white-box engagement against a B2B SaaS platform serving millions of users — the web application plus its internal and external APIs. The client is not named and never will be, so take the shape of it rather than the logo.

more than 40

issues found across the application and both API surfaces

15

of them critical — proved by exploitation, not flagged by a scanner

years

that several of them had been sitting in production code, unnoticed

representative finding · critical

Stored cross-site scripting, proved end to end

Rather than report that input was insufficiently sanitised, we demonstrated the consequence: arbitrary JavaScript submitted through the application and executed inside a different user's account.

That is the difference between a finding and a suspicion. A developer reading it does not have to decide whether we are right — the proof is in the report, and the severity argues itself.

how it was run · scope and safety

Source-guided, and sealed off

Reading the source is what surfaced this class of issue: the flaws were in application logic — injection, cross-site scripting, server-side request forgery — rather than in an unpatched dependency a scanner would have named.

  • Testing ran on an isolated instance with no inbound access
  • Scope and written authorization agreed before anything started
  • Criticals fixed quickly, then verified in the included retest

One engagement is one data point, and a good result on someone else's application is not a promise about yours. It is here because it shows what the method produces — proof rather than a list, and findings in code that had passed everything else for years.

Who_it's_for

Built for teams that ship.

startups · saas · dev teams

Dev-heavy startups & SaaS

A security questionnaire is blocking a deal, or a SOC 2 Type II audit is coming. We work the way you do — GitHub, CI, OWASP — and hand you evidence your enterprise customer will accept.

  • Security questionnaires answered with proof
  • SOC 2 Type II testing evidence
  • Reports your customers' security teams respect

clinics · e-commerce · agencies · fintech

SMBs building with AI

Your insurer or payment processor is asking for a penetration test. We explain everything in plain English, guide you through each step, and deliver a report your insurer or assessor can read.

  • Cyber-insurance requirements met
  • PCI DSS 4.0 testing, mandatory since March 2025
  • Plain-English reporting and hand-holding throughout

ai adopters · copilots · agents

Companies adopting AI agents

You're wiring AI assistants and agents into email, documents, and customer data. Each connection is new exposure that traditional testing never covered. We check what your agents can be tricked into doing — and verify the fixes.

  • Prompt-injection and data-exposure testing
  • Agent permissions and connected tools reviewed
  • Plain-English report of what an attacker could reach

Commonly requested for: SOC 2 TYPE II PCI DSS 4.0 CYBER INSURANCE SECURITY QUESTIONNAIRES

Before_it_is_built

Some clients come to us with nothing to test yet.

They are still designing the thing. They want to know whether the plan has a problem in it before a team spends six months building on top of that problem. We review the design and write it up the same way we write up a test.

planning stage · design in progress

Reviewed while it is still cheap to change

We work from whatever exists at that point — architecture notes, specifications, data flows, user stories, sometimes a diagram somebody drew in a meeting. Enough to see how the parts are meant to fit together and where the trust boundaries fall.

The economics are the whole argument. Changing an authentication model or the way data moves between services costs very little while it is a decision, and a great deal once it is a dependency.

deliverable · written report

A report, not a conversation you forget

You get findings in writing, with severity and with the reasoning attached, so the team can act on them and you can show later that security was considered before the first commit rather than after the first incident.

  • Risks in the proposed design, ranked by what they would cost you
  • Recommendations tied to the decision they affect
  • Evidence that security shaped the build, for whoever asks

A design review cannot find implementation bugs, because there is no implementation yet. It reduces the number of problems you build in; it does not remove the need to test what you built. Most clients who start here come back for the test later, and the test is shorter for it.

Business_security_audit

Security beyond the codebase.

A penetration test tells you what an attacker could do to your application. A security audit tells you what they could do to your company. It is often the question an insurer or an enterprise customer is actually asking, and it is quoted separately from the testing above.

access · permissions · offboarding

Who can reach what

Accounts, admin rights, shared logins, and the access nobody removed when someone left. This is where a large share of real incidents start, and an application test will never see it.

  • Account and permission inventory
  • Admin and shared-credential review
  • Joiner, mover and leaver process in practice

suppliers · third parties · data

Who else touches your data

The tools, integrations and contractors with access to your systems or your customers' data. As far as your customers and your regulator are concerned, their mistakes are yours.

  • Supplier and tooling inventory
  • What data each one can actually reach
  • Contract and data-processing gaps flagged

detection · response · recovery

What happens when it goes wrong

Whether you would notice an incident at all, who decides what to do next, and how quickly you could be working again. Usually the shortest part to write and the most useful to read.

  • Detection and escalation as they really work
  • Backups and recovery, actually tested
  • A prioritised remediation list you can budget from

Commonly bought alongside a penetration test, and just as often on its own. Looking for functional testing rather than security? That is our quality assurance service.

Pricing

Transparent pricing. Quote in writing first.

Traditional penetration tests typically run $5,000–$50,000. Ours start at a price a small team can actually approve.

Spot Test

From $2,500one-off

One application or API, tested end to end.

  • Full engagement plus one retest
  • Auditor-ready report in plain English
  • Remediation guidance tied to your code
Request a quote

Most popular

Continuous

From $1,500/month

Security testing that keeps pace with your releases.

  • Quarterly in-depth testing
  • Monthly delta scans of what changed
  • Retests included, whenever you fix
  • Fresh evidence for audits and questionnaires
Book a scoping call

Multiple apps?

Let's scope it

Several applications, priority turnaround, or security-questionnaire support — we'll shape a plan around your portfolio.

  • Multi-app coverage
  • Priority scheduling
  • Questionnaire support
Talk to us

Final pricing depends on scope and is confirmed in a written quotation before any commitment.

Our_commitment

Honest testing you can put in front of anyone.

A human behind every finding

Every finding we report has been validated by an experienced penetration tester. No raw scanner dumps, no unverified noise.

Honest about limits

We define scope precisely, and we don't claim complete coverage — no responsible provider can. What we report, we can prove.

Your code, protected

NDA before we start. Isolated environments during testing. Your source and data are deleted after the engagement.

Built on hands-on experience

KRYO is built on hands-on application-security engineering: reading real codebases, proving real exploits, and reporting them so teams can fix them.

FAQ

Fair questions. Straight answers.

A penetration test is hands-on technical testing of your application: we try to break in and prove what an attacker could reach. A security audit looks at how your company operates around that software — who has access, which suppliers touch your data, and what happens when something goes wrong.

Different questions, and different evidence. A test produces working proof of a specific weakness: the request that got through, the data it returned, the account it reached. An audit produces a view of process and control — policies, access reviews, supplier agreements, incident procedure.

Most compliance frameworks and enterprise security questionnaires ask for both, at different points. You can buy either from us on its own, and we will tell you which one answers the question you are actually being asked.

No. A scanner produces a list. We produce proof.

Our tooling covers the attack surface quickly and consistently, and that part should be automated. A qualified penetration tester then works through what it found: confirming each issue is genuinely exploitable, chaining the ones that matter, and discarding the false positives that make raw automated output so hard to act on.

The difference shows up in your report. A scanner tells you a library version looks vulnerable. We tell you whether it can actually be reached in your application, what an attacker gets if they do, and what to change. Nothing reaches your report without human sign-off, and we would rather hand you five proven findings than fifty unverified ones.

Access is optional, and it is protected. We work under NDA, in isolated environments, and delete your code and data when the engagement closes.

If your policy does not allow sharing source at all, we can still test. You get a black-box engagement, and we will say plainly what that costs you in coverage rather than pretending it costs nothing.

Sharing source is worth considering, though. It lets us reach vulnerability classes that black-box testing structurally cannot: logic flaws in code paths that are hard to trigger from outside, authorisation checks that are missing rather than weak, and secrets committed where they should not be. Source-guided testing usually finds more in the same number of days, which is why it is our default.

Reports are written for exactly that audience. Every finding carries evidence — the request, the response, the reproduction steps — so a technical reviewer can verify it rather than take our word for it. The summary is plain English, so the people who are not technical can still act on it. Severity is explained rather than asserted.

The retest is included, and it produces a letter documenting what was fixed and confirmed closed. That letter is usually the thing an auditor, insurer or enterprise customer actually asks for: not that you had a test, but that you resolved what it found.

We do not claim a report guarantees any particular certification. Frameworks differ, and your assessor makes that call.

No. You get a written quote before any commitment, and the retest is included in it. Pricing starts at $2,500 for a spot test and $1,500 a month for continuous coverage — the number you agree is the number you pay.

The quote covers the agreed scope: the application or API, the environments, and the testing window. If something changes once we are in — you add a service, or the scope turns out to be larger than it was described — we stop and agree the new price in writing before continuing. We do not invoice for work you did not approve.

The retest matters here, because it is where some providers charge again. Fixing findings and having them verified is part of the engagement, not an upsell.

Fair question. The honest answer is evidence rather than reassurance.

The person who validates your findings has solved 131 labs in PortSwigger's Web Security Academy, covering all 28 of its vulnerability categories — injection, access control, SSRF, deserialization, request smuggling and the rest. Mostly by hand, which is the point: tooling surfaces candidates, but recognising what is genuinely exploitable is a skill built one class of bug at a time.

On a recent engagement that work found more than forty issues in a B2B SaaS platform serving millions of users, fifteen of them critical. Some had been in the code for years.

Beyond that: precise scope agreed in writing, a human behind every finding, and honest limits — we never claim complete coverage, because no responsible provider can. If we think a test will not answer the question you are actually being asked, we say so on the scoping call rather than after the invoice.

Yes. An agent connected to your email, files, or customer data can be manipulated through the content it reads — prompt injection, tool misuse, data leakage. That is attack surface a traditional test never looked at. We test agent integrations the same way we test applications: every finding validated by a human, with fixes verified in a retest.

A 15-minute scoping call. We agree what to test — which application, which environments, which accounts — and put the scope and written authorization in place before anything starts.

The authorization is not a formality. Testing a system without it is not something a responsible provider does, and your hosting provider may need notice as well. We work through that paperwork with you.

After that you get a written quote. If you accept it, we schedule the engagement and agree the window with you. You do not need to build anything for us unless you would rather we tested somewhere other than production.

Get_started >>

Book a 15-minute scoping call.

Tell us what you're shipping and what's driving the request — a questionnaire, an audit, an insurer. We'll reply with next steps: usually a short call and a written quote.

Prefer email? Write to info@kryo.solutions — and ask for a sample report.

Keep it high-level here — hold off on infrastructure details, credentials, or specifics until an NDA is in place.

Testing is performed only with written authorization. By submitting this form you agree to our Terms of Use. We use your details to respond to this request and, if you engage us, to deliver our services — see our Privacy Policy.