Pentesting Campaigns

Pentesting Campaigns by persistent agents

Run compute-intensive agents for 72 hours or longer to probe deployed systems and code within your sandbox and security requirements.

learn more

Cobalt search paths explore deep openings in a sculpted chrome and graphite system.

API, worker and database activity in a sandboxed system within an isolated test environment.

[Platform]

Put your deployed software to the test.

Pentesting Campaigns are Octane’s most compute-intensive agentic workflows. Agents run multi-step tests against your software and code in synthetic environments built around your system, configured by a forward-deployed engineer to follow your approved scope and security requirements.

[RUNTIME RESEARCH]

72+ hours of agentic probing

Agents probe running systems and code for 72 hours or longer, with campaigns extending over weeks when the scope calls for it. Sustained, multi-step testing gives agents time to follow complex paths, challenge assumptions and uncover deep bugs. Every run stays within your approved sandbox, scope and security requirements.

Test deployed builds. Run multi-step sequences in a sandboxed environment.

Challenge assumptions. Test the security rules defined by your policies and specifications.

Keep the evidence. See what broke, what held and what the search could not reach.

[how it works]

From scope to deep agentic probing

[Phase 0]

Scope

Work with your forward-deployed engineer to define the targets, software builds and security rules. Agree on the boundaries and the evidence needed before the search begins.

[Phase 1]

Execute

Agents run multi-step tests against the software in scope. Your engineer steers the research, investigates leads and shares progress throughout the Campaign.

[Phase 2]

Reproduce

Findings are reproduced from a clean state and delivered with proof, root cause and remediation. A coverage ledger records the results, open leads and paths the search could not reach.

[WHAT YOU GET]

Proof for every finding. A clear record of coverage.

Findings come with:

A REPRODUCIBLE SEQUENCE AND WORKING PROOF
ROOT CAUSE AND THE BROKEN SECURITY RULE
SEVERITY WITH STATED PRECONDITIONS
A FIX AND TEST OR REMEDIATION GUIDANCE

Campaigns are right for:

COMPLEX DEPLOYED SYSTEMS
HIGH-STAKES QUESTIONS THAT NEED DEEPER RESEARCH
INTERACTIONS ACROSS PROGRAMS AND SERVICES
DEPENDENCY BEHAVIOR WITHIN AN AGREED SCOPE
TEAMS EXTENDING AUDITS, VERIFICATION AND BUG BOUNTIES

[COVERAGE YOU CAN INSPECT]

Know what was tested and what remains open.

A clean result is only as useful as its boundaries. The coverage ledger makes those boundaries visible. See the exact builds and security rules tested, the sequence counts and starting states, and whether each rule held or broke. Unresolved leads retain their evidence. Paths that could not be exercised are recorded with the reason why.

[what people ask]

FAQ

What is an Octane Pentesting Campaign?

A Pentesting Campaign uses compute-intensive agentic workflows to probe running systems and code for 72 hours or longer, extending over weeks based on the agreed scope. An Octane forward-deployed engineer sets up the environment and configures testing to follow your sandbox and security requirements.

How does it complement Continuous Analysis?

Continuous Analysis evaluates code as it changes. Campaigns investigate runtime behavior by executing multi-step sequences against deployed builds in a scoped sandbox.

What does each finding include?

Each finding identifies the sequence that triggers the issue, the security rule it breaks, the root cause, severity and preconditions. It includes working proof and a fix with a test or other remediation guidance.

What if no vulnerability is found?

You still receive a coverage ledger showing what was tested and on which builds. It records the rules that held, unresolved leads and paths that could not be exercised. A clean result applies to those stated bounds.

Can dependencies be included?

Yes. Dependency research can be included in the agreed scope, following the versions used by your deployed builds and the assumptions your software makes about them.

How do we get started?

Start with a scoping conversation to define the systems, software builds, security rules and expected evidence. Your forward-deployed engineer uses that scope to prepare the research plan.