Is it safe to test production?

Tests run only inside the scope and hours you approve, use your test accounts, and never run denial-of-service attempts. Proofs are captured without keeping customer data.

Does this replace our yearly pentest?

It covers the days in between. Many teams keep a human-led engagement for depth and compliance, and use agents for every release.

How is this different from a scanner?

A scanner reports what might be wrong. Agents try to exploit it inside your scope, and only report what they can prove, with the fix.

Do we follow the AWS testing policy?

Yes. Testing stays within the AWS customer penetration testing policy for permitted services, and your scope rules apply on top.

AWS Partner

SOC 2 Reports

Frontier Investigationfor Offensive Security

Every exposure proven exploitable or ruled out, with the fix attached.

A yearly pentest sees your attack surface on one week of the year. Agents test it every day, inside the scope you approve. Each exposure is proven exploitable with a safe proof, or ruled out with the reason. What is real arrives with the fix and a retest.

Book a Demo See how it works

Continuous attack testexploit proven

api.example.com /v2/invoices/{id}

Surface: Public API, 42 endpoints, discovered from the OpenAPI spec
Attempt: Swapped invoice id with a second test tenant token
Proof: Tenant B read tenant A invoice. Broken object authorization
Evidence: Request, response hash, no data kept beyond the proof
Fix: Ownership check in InvoiceController. Retest queued

Proven in 11m. Waiting for AppSec review

[The work behind every exposure]

Your attack surface changes daily.Your pentest happens once a year.

01The manual work

Test

A scanner report is only the start. AppSec still decides what is reachable, tries to exploit it by hand and argues about severity.

02The agent handoff

Exploit proven

Frontier agents test the surface inside your scope, prove what is exploitable with a safe proof and prepare the fix.

03Your engineers’ role

Approve

Set the scope and the rules of engagement. Review the proof, approve the fix and confirm the retest.

[Where CloudThinker fits]

Your stack stays.Agents work inside it.

01Attack surface

What attackers can reach

AWSPublic endpoints, IAM and S3
AzureApp services and Entra ID
Google CloudLoad balancers and IAM
CloudflareDNS and edge routes
Public APIYour documented endpoints

Scope you approve

02Known findings

Your system of record

Amazon InspectorKnown CVEs
WizCloud posture findings
SnykCode and dependency findings
SemgrepStatic analysis results

No change to scanning

03Offensive testing

CloudThinker

AttackChain findings the way an attacker would
ProveExploit captured with safe evidence
Rule outClose what is not reachable
FixChange ready for the owning team

Inside approved scope and hours

04Response

Proof, not lists

JiraTicket with the proof and the fix
GitHubPull request for the fix
SlackCritical findings to AppSec
RetestSame attack run after the fix

Fix verified by retest

Logos show common stacks. CloudThinker connects to each one through read-only access you approve.

[Example scenario]

Monday, 10:05. A new API version ships.The next pentest is in five months.

A 120-engineer B2B SaaS company with a public API, three AWS accounts and a two-person AppSec team. Enterprise customers ask for proof of testing every quarter.

10:05
New endpoints go liveSignal
API v2 deploys with 9 new endpoints. The agent sees the OpenAPI spec change and the new routes on the load balancer.
10:07
Agent maps the changeAgent
Adds the endpoints to the approved scope, checks auth on each one and plans tests with two test tenants.
10:18
One exposure provenAgent
Tenant B can read tenant A invoices on /v2/invoices/{id}. Proof captured as a request and a response hash, no data kept.
10:18
Eight ruled outAgent
The other 8 endpoints enforce ownership. Each one is closed with the test that shows it.
10:20
Fix preparedAgent
Pull request adds the ownership check to InvoiceController, with a regression test. AppSec is paged.
11:02
Fixed and retestedYour team
AppSec approves, the fix ships at 10:55, and the agent retest at 11:02 confirms the exposure is closed.

#appsec-findings4 messages

CloudThinker10:18
Proven: broken object authorization on GET /v2/invoices/{id}. Test tenant B read an invoice owned by test tenant A. Severity high. 8 other new endpoints passed.
AppSec engineer10:31
Confirmed on staging. Approving the PR, please retest after deploy.
GitHub Actions10:55
Deploy api v2.0.1 to production succeeded.
CloudThinker11:02
Retest passed. Tenant B now gets 404 on tenant A invoices. Finding closed, evidence added to the quarterly testing report.

from deploy to proven exposure: 13 min
from deploy to verified fix: 57 min
new endpoints ruled out with proof: 8 of 9

An illustrative example. Team, systems and times are representative, not a specific customer.

[Frontier investigation agents]

Every exposure gets tested.Only the proven ones reach your team.

Agents attack inside the scope you approve, so a finding arrives with a safe proof, and your team fixes what is exploitable, not what is theoretical.

Map the attack surface: Public endpoints, cloud assets and new routes discovered as they appear, kept inside your approved scope.
Prove exploitability: Each exposure tested with a safe proof, or ruled out with the test that shows it is not reachable.
Hand over the fix: Proven findings come with a pull request or a config change, mapped to the owner of the code.
Retest and report: Every fix retested after deploy, with evidence collected for customers and auditors.

[What changes]

Same team. Same tools.Far less of the work by hand.

Moment	Today	With frontier agents
How often you test	Once or twice a year	Every day, and on every new release
Scanner findings	Triaged by hand, argued over	Proven exploitable or ruled out
Fixing	A PDF report for developers to read	A pull request with a regression test
Retesting	At the next engagement	Right after the fix deploys
Evidence for customers	Last year’s pentest letter	A current record of what was tested and fixed

[Integrations]

Connects to the rest of your stack.Read-only to start.

Amazon Inspector
AWS Security Hub
Amazon GuardDuty
Wiz
Snyk
Semgrep
CrowdStrike
GitHub
GitLab
Jira
Slack

[Adoption path]

One pilot.Then company-wide.

The rollout follows the four phases of the AWS Cloud Adoption Framework, so it fits the plan your cloud team already runs.

01Envision
Agree the scope
Pick one application and write the rules of engagement: which hosts, which test accounts, which hours.
02Align
Set the safety rules
Decide what agents may attempt, what needs approval first, and how proofs are captured without keeping data.
03Launch
Add applications
Bring each application into scope on the same rules, so every team gets the same proof format.
04Scale
Test on every release
New endpoints and assets enter testing as they deploy. Findings feed threat models and secure coding training.

[AWS guidance]

Built the way AWS says to run it.Reviews start from a known reference.

[Trust and control]

Agents do the work.Your team keeps control.

You approve every change: Agents propose. Nothing touches production until someone on your team says yes, and you set that rule per system.
Every action on the record: Each step is logged, attributed and reversible, ready for your auditors.
Certified for enterprise: SOC 2 Type II and ISO 42001, with reports in our trust center.
Runs where you need it: In our cloud, through AWS Marketplace, or inside your own account.

[Questions]

What teams askbefore they start.

Is it safe to test production?: Tests run only inside the scope and hours you approve, use your test accounts, and never run denial-of-service attempts. Proofs are captured without keeping customer data.
Does this replace our yearly pentest?: It covers the days in between. Many teams keep a human-led engagement for depth and compliance, and use agents for every release.
How is this different from a scanner?: A scanner reports what might be wrong. Agents try to exploit it inside your scope, and only report what they can prove, with the fix.
Do we follow the AWS testing policy?: Yes. Testing stays within the AWS customer penetration testing policy for permitted services, and your scope rules apply on top.

[Go deeper]