Does this replace our scanners?

No. Agents read findings from the scanners you already run, such as Amazon Inspector, Security Hub, Wiz and Snyk. Your scanning setup stays where it is.

What access does it need?

Read-only access to the scanners, cloud accounts and repos you choose. Opening pull requests is added per repo and can be revoked at any time.

Can agents apply fixes to production?

Only where your policy allows it. Most teams have agents open pull requests that go through normal review and CI, so nothing reaches production without a merge.

How do you avoid breaking things?

Every fix comes with tests or a Terraform plan, and agents rescan after the merge. If a fix would destroy or replace a resource, the pull request says so up front.

AWS Partner

SOC 2 Reports

Frontier Remediationfor Vulnerabilities and Misconfigurations

Burn down the CVE and CSPM backlog with fixes ready to merge.

Your scanners already find the problems. Agents take the backlog from Amazon Inspector, Security Hub, Wiz or Snyk, check which findings are reachable in your environment, and turn each one into a tested fix ready to merge: a dependency bump, a Terraform change, a patch window. Your team reviews pull requests instead of spreadsheets.

Book a Demo See how it works

AWS Security Hub findingfix ready

S3 bucket invoices-prod allows public read

Finding: S3.8 Block Public Access disabled on 1 bucket
Exposure: 4,312 objects readable, 0 requests from outside in 30 days
Cause: Terraform module sets block_public_acls = false
Evidence: Bucket policy, ACLs, access logs, plan
Fix: Pull request to the module. Plan shows 1 change, no destroys

Prepared in 2m 05s. Waiting for owner review

[The work behind every finding]

Scanners find issues every day.The backlog only grows.

01The manual work

Prioritize

A finding is only a line in a report. Engineers still check if it is reachable, find the owner and work out a safe fix.

02The agent handoff

Fix ready

Frontier agents rank the backlog by real exposure, then prepare the change in the code or infrastructure that owns it.

03Your engineers’ role

Merge

Set which fixes agents may prepare and where. Review the pull request and decide what ships.

[Where CloudThinker fits]

Your stack stays.Agents work inside it.

01Findings

Already in your scanners

Amazon InspectorCVEs on EC2, ECR and Lambda
Microsoft Defender for CloudVulnerability assessment
Security Command CenterFindings across projects
WizCloud posture and toxic combinations
SnykCode and dependency findings

No change to scanning

02Code and config

Your system of record

TerraformModules and state
GitHubRepositories and Dependabot
GitLabRepositories and pipelines
KubernetesManifests and Helm charts

Source of truth stays put

03Remediation

CloudThinker

RankReachable and exploitable first
GroupOne fix for every finding it closes
FixChange written in your own code
TestPlan and pipeline run before review

Read-only by default

04Response

Pull requests, not reports

GitHubPull request ready to merge
GitLabMerge request with the plan
JiraTicket linked to each finding
SlackWeekly burn-down to owners

Merges run on approval

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

[Example scenario]

Monday, 09:00. 2,400 open findings.The audit is in six weeks.

A healthtech company with 22 AWS accounts, Security Hub and Amazon Inspector turned on, and Terraform for everything. Two security engineers own the backlog.

09:00
Backlog review startsSignal
Security Hub shows 2,400 open findings. Nobody knows which ones are reachable or who owns them.
09:05
Agent ranks by reachabilityAgent
Checks each finding against network paths, IAM and runtime use. 310 are reachable. 2,090 are closed with the reason.
09:40
Top finding explainedAgent
S3 bucket invoices-prod allows public read. The cause is a Terraform module default, used in 6 stacks.
09:42
Fixes grouped by ownerAgent
310 findings become 38 pull requests, grouped by module and owner, each with a clean Terraform plan.
14:00
Owners mergeYour team
Team leads review plans showing only the intended change. 29 pull requests merged on day one.
17:30
Verified and recordedAgent
Security Hub rescans. 241 findings closed, each linked to its pull request as audit evidence.

#sec-remediation4 messages

CloudThinker09:42
Backlog triaged: 310 of 2,400 findings are reachable. Grouped into 38 PRs by module and owner. Highest: public read on invoices-prod via modules/s3-bucket (6 stacks).
Security engineer10:15
Ranking looks right. Sending the PRs to the owners.
Platform lead14:00
Merged the s3-bucket module fix. Plan was 1 change, no destroys.
CloudThinker17:30
Rescan done. 241 findings closed today, each linked to its PR. 69 left, all assigned with owners.

unreachable findings closed with a reason: 2,090
pull requests instead of 310 tickets: 38
findings fixed and verified on day one: 241

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

[Frontier remediation agents]

Every finding gets a fix.Only the hard ones need a meeting.

Agents work the backlog from every scanner on one policy, so a critical finding arrives ranked by real exposure, with the fix already written.

Check reachability: Each finding checked against what is deployed, exposed and actually called before it is ranked.
Find the owner: The repo, module and team behind the resource found from code, tags and deploy history.
Write the fix: Dependency bumps, Terraform changes and config fixes opened as pull requests with tests and a plan.
Verify it closed: After the merge, agents rescan and confirm the finding is gone, or reopen it with the reason.

[What changes]

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

Moment	Today	With frontier agents
Prioritization	By severity score alone	By reachability and real exposure
Finding the owner	A ticket that bounces between teams	Routed to the repo and team that own it
The fix	Written by hand, when there is time	A pull request with tests and a plan
Closing the loop	Marked done in a spreadsheet	Rescanned and verified after the merge
Recurring issues	Fixed one resource at a time	Fixed once in the shared module

[Integrations]

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

Amazon Inspector
AWS Security Hub
AWS Config
Wiz
Prisma Cloud
Orca Security
Lacework
Snyk
Trivy
Qualys
Tenable
Dependabot
Terraform
GitHub
GitLab

[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
Pick one backlog
Connect one scanner read-only and let agents rank and draft fixes in shadow mode. Compare them with your own triage.
02Align
Agree the fix policy
Decide which fix types agents may open, which repos they may touch, and who reviews.
03Launch
Roll out team by team
Add each team’s repos and accounts on the same policies, pull request format and audit trail.
04Scale
Make it continuous
New findings get a drafted fix as they appear. The backlog stops growing instead of being cleared once a quarter.

[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.

Does this replace our scanners?: No. Agents read findings from the scanners you already run, such as Amazon Inspector, Security Hub, Wiz and Snyk. Your scanning setup stays where it is.
What access does it need?: Read-only access to the scanners, cloud accounts and repos you choose. Opening pull requests is added per repo and can be revoked at any time.
Can agents apply fixes to production?: Only where your policy allows it. Most teams have agents open pull requests that go through normal review and CI, so nothing reaches production without a merge.
How do you avoid breaking things?: Every fix comes with tests or a Terraform plan, and agents rescan after the merge. If a fix would destroy or replace a resource, the pull request says so up front.

[Go deeper]