Skip to main content

Ore Hammer Penetration Test — agentic web application penetration testing

Prove what an attackercould actually do.

Ore Hammer Penetration Test is an agentic pentest for scoped web applications and hosts. It follows established testing methodologies, reproduces weaknesses, builds exploit chains where appropriate, and validates real security impact before reporting — with evidence for every confirmed finding.

Contact usWatch the overview

Self-service coming soon.

Watch

Expert-level web application testing. At the speed and scale of your development.

The problem

Development moves at AI speed. Security testing still depends on human capacity.

Traditional penetration testing depends on the expertise, availability and time of individual testers. Thorough assessments are expensive, take time to coordinate and are difficult to repeat at the pace applications now change. AI-driven development is widening that gap.

Quality depends on who tests

The depth of an assessment varies with the tester’s experience, approach and time budget. The same application can receive very different scrutiny. Teams need consistent depth and evidence they can inspect.

Cost and time limit coverage

Finding an available tester, agreeing on scope and completing an engagement takes time and money. Most teams cannot repeat that process with every meaningful release. Testing frequency follows the budget and calendar, while development keeps moving.

Every release changes the picture

An assessment establishes what was tested in a particular version of your application. New code, dependencies and configuration changes can introduce risks the assessment never covered. With AI accelerating development, the distance between what was tested and what is running grows faster.

A reported fix still needs proof

A finding needs enough evidence to understand and reproduce it. A fix needs a retest to confirm it worked. Without that loop, teams accumulate tickets and closure statuses without knowing whether the underlying risk is gone.

Agentic penetration testing makes high-quality assessments possible as often as your code changes—with consistent coverage, reproducible evidence and retesting to verify fixes. Every assessment must operate within an explicitly defined, technically enforced scope.

What it does

What Ore Hammer Penetration Test does

  1. A methodology built for your application

    The agent plans each assessment around your application and the scope you define—unauthenticated or authenticated web testing, network black-box testing, a full penetration test, or source-informed white-box testing. Available source code helps guide deeper coverage of application logic and paths that external testing may miss. The plan, assumptions and testing hypotheses remain visible for your review.

  2. Coverage beyond the login

    Assess the functionality your users actually access. Support for form logins, API credentials, OAuth/JWT with refresh, bearer tokens, cookies and browser-captured MFA/SSO sessions enables testing across authenticated workflows. Eleven supported traffic formats let assessments start from real application activity.

  3. Evidence for auditors. Action for engineers.

    Every confirmed finding includes the replay artifact used to validate it. Compare assessment runs to track changes and export results in the format your team needs: PDF reports for auditors, Markdown files with evidence and remediation guidance for AI coding agents, or CSV findings ready for your engineering backlog.

  4. Scope enforced with technical controls

    Every assessment defines its allowed hosts and request-rate limits. Out-of-scope requests are blocked at the egress layer. Actions beyond read-only testing require a host-bound authorization token with an expiry, making the approved scope an enforced boundary throughout the assessment.

How it reasons

From a scope, to a hypothesis, to the artifact that proves it.

Three diagrams, not screenshots. The product demo shows the real interface.

Four modes, one scope
  1. PUBLICUnauthenticated web appWhat anyone can reach, from the public URL.
  2. BEHIND THE LOGINAuthenticated web appBehind the login, with a session you supply.
  3. NETWORKNetwork black-boxHosts and services, with no application session.
  4. COMPLETEFull pentestThe complete engagement, in one scoped job.

Mode names are the product's own; the one-line summaries are ours. Scope and mode are agreed per job.

One finding, from hypothesis to artifact
  1. HYPOTHESISWhat the agent thinks is exploitableStated in readable form, with the chain it assembled to get there.
  2. REQUESTA scoped, rate-capped attemptAgainst a named host, inside the mode and scope of the job.
  3. OBSERVATIONWhat came backRecorded as it was, so the reasoning can be checked.
  4. EVIDENCEThe replay artifactKept with the finding. Closure needs a re-check, not a status flip.

Every confirmed finding keeps the artifact that confirmed it, and the next run re-checks it.

What a job may touch
  1. ALLOWED HOSTSNamed per jobOut-of-scope requests are blocked at the egress layer, not filtered out of the report.
  2. RATECapped per jobA request-rate cap on every run.
  3. SCOPERead-only by defaultAnything beyond needs a separate, host-bound authorization token with an expiry.
  4. AUTHORIZATIONConfirmed by youBefore a run, you confirm you are authorized to have every scoped host tested.

Enforced on the job, not written into the report.

The loop

Scope, to methodology, to proof, to re-check.

SEE

The applications and hosts in scope, and the sessions and traffic that reach them.

UNDERSTAND

A planned methodology and readable hypotheses about what is exploitable.

ACT

The finding reproduced, with the replay artifact that confirms it.

ASSURE

The next run re-checks every closed finding; a fix is proved closed, not marked closed.

Who it’s for

Three people read this page for different reasons.

A pentest produces findings, but a finding has to satisfy the person who has to act on it — and the person who has to allow the test to run.

  • Security leadership

    You need to say what is exploitable today, and defend the answer. Every finding carries the artifact that reproduced it, and every closed finding was re-checked, not re-labeled.

  • AppSec

    You need to stop arguing about whether a finding is real. The hypothesis, the request and the observation are readable, and the replay artifact settles it.

  • Platform and DevOps

    You need to know the test cannot wander. Allowed hosts are named per job, rate is capped, out-of-scope requests are blocked at egress, and read-only is the default.

Getting started

From scope to first confirmed finding.

There is nothing to install. We agree the scope and the mode with you, you confirm authorization, and the first run goes.

Start · the first day

Scope and mode

We agree which applications and hosts are in scope, in which mode, and you confirm you are authorized to have them tested. Read-only unless you say otherwise.

Then · within hours

First run

Supply a session if the mode needs one, or recorded traffic to start from. The agent plans its methodology and returns confirmed findings with their evidence.

After that · every run

Re-check on every run

Each run is compared to the last. Closed findings are re-tested; a finding that returns is treated as new.

Datasheet

The technical answer.

Deployment
Agentless. Runs against the scope from outside; no agent in your environment.
Modes
Unauthenticated web app, authenticated web app, network black-box, full pentest.
Authentication
Form login, API credentials, OAuth/JWT with refresh, raw bearer or cookie profiles, browser-captured MFA/SSO sessions.
Traffic imports
HAR, Burp, ZAP, URL list, OpenAPI, Postman, Selenium Wire, CDP, Playwright trace, Puppeteer, mitmproxy.
Outputs
Confirmed findings with replay artifacts, readable hypotheses and chains, run-to-run comparison, CSV and PDF export.
Scope controls
Named allowed hosts per job, request-rate caps, guarded egress, host-bound tokens with expiry for anything beyond read-only.
Integrations
GitHub, GitLab, ticketing.

PDF · two pages

Ore Hammer Penetration Test product brief

The one-pager to forward internally: what it does, what it needs, what it returns.

Request the brief

PDF · technical

Ore Hammer Penetration Test datasheet

Full specification: modes, authentication, scope controls, data handling and limits.

Request the datasheet

Scoped engagement

Run it on something you own

The fastest way to evaluate this is a scoped run against an application you own. We scope it with you.

Contact us

Questions

What people ask before they say yes.

Is it safe to run against production?
It is built to be. Scope defaults to read-only; anything beyond it requires a separate, host-bound authorization token with an expiry. Every job names its allowed hosts and its rate cap, and out-of-scope requests are blocked at the egress layer rather than filtered out of the report afterwards.
Will you actually exploit anything?
Not destructively, by default. A finding is confirmed by reproducing the evidence it rests on — the request and what came back — inside read-only scope, without leaving persistent artifacts. Anything beyond read-only requires a separate, host-bound authorization token with an expiry, and every action is bounded by the hosts you scope in.
Does this replace a human pentest?
Not entirely. A human pentest is a point-in-time engagement with a report at the end. Ore Hammer Penetration Test runs an agentic pentest continuously and hands you the current state, with the evidence. Most teams use both, and the human engagement gets more interesting once the obvious paths are gone.
What do I have to give it?
Authorization for the scope, and — for the authenticated modes — a session, supplied one of five ways. Recorded traffic is optional and gives the agent the paths your users actually take. Nothing is installed in your environment.
What happens when a session expires?
A browser-captured MFA or SSO session cannot be refreshed once it expires; a long authenticated run needs a re-capture, or credentials that support programmatic refresh, such as OAuth/JWT with refresh.
How is this different from Ore Hammer Surface?
Surface finds and ranks the external surface without touching it; the Penetration Test proves what is exploitable on the surface you scope in. They are separate products, and the surface one finds is the surface the other is scoped against.

Alongside the suite

The proof, in one place.

Ore Hammer Penetration Test runs independently — it needs nothing else connected to be useful. It shares its vocabulary with Ore Hammer Surface, SentinelFlow and ActiveFlux, so a confirmed finding can be read back to the surface that exposed it, the repository that built it, and the cloud that runs it; joining those views into one graph is on the roadmap, not a prerequisite.

Trusted by security and platform teams at

  • Instacart
  • Plume
  • HealthTap
  • MergeBase
  • Arrivo
  • LMKR

Prove it on your own application.

Ore Hammer Penetration Test is available by invitation while we onboard carefully. Tell us what you run and we will scope a first engagement.

  • Agentless
  • Read-only by default
  • Scoped with you