Introduction​

Mantle is an agent-first cloud and application security platform. We have five primary goals:

1. Help agents understand cloud environments without direct access granted to those environments.
2. Find security issues and propose fixes automatically.
3. Map relationships between cloud systems, including secret use and OpenID Connect trust boundaries.
4. Retain product-specific knowledge and undocumented edge cases.
5. Coordinate long-running security work across multiple agent sessions.

Human reviewers approve and merge changes that Mantle proposes.

We want Mantle to be an effective security coworker. Mantle helps teams:

1. Enforce least-privilege access for human operators.
2. Fix security defects across the technology stack.
3. Monitor completed remediations to prevent regressions.

This post explains how we built Mantle, what it does today, and how we plan to extend it.

High-level architecture​

This section describes the agent system and the application security scan workflow.

Mantle launches with three primary features:

• Application security scanning: Specialized agents inspect source code, review candidate findings, remove duplicates, propose fixes, and open draft pull requests.
• Cloud security scanning: Mantle uses the upstream CNCF Cartography package with Mantle integration code to ingest cloud resources on a schedule.
• Mantle MCP: Local agents can use information from Mantle through the Model Context Protocol.

This post examines application security scanning. A set of specialized agents finds, reviews, deduplicates, and remediates security issues. You can configure a scan schedule in the Mantle user interface. We recommend one scan each week, but you can select a different interval. The following section explains the workflow.

Mantle uses Temporal for durable execution and agent orchestration. Each scan claims one sandbox from Daytona and performs all repository operations in that sandbox.

1. A file-selector agent surveys the repository and proposes security-relevant exploration roots. The host limits the selection and prefers roots that were not scanned recently.
2. AppSec agents investigate the selected roots in parallel. Each agent examines the root, related files, and the local call graph.
3. The agents return candidate findings with severity, locations, and descriptions. An adversarial reviewer reads the cited source and rejects false positives.
4. Mantle embeds the accepted candidates and compares them with earlier findings. Vector similarity and a deduplication agent reject duplicate candidates.
5. A remediation agent applies each accepted fix in a separate worktree. Mantle publishes the finding and opens a draft pull request when remediation succeeds.
6. If automatic Slack assignment is enabled, Mantle uses git blame to identify a reviewer. Mantle then sends a notification when it can map that reviewer to Slack.

Below, you can see an automated remediation that keeps packages in a uv managed environment from updating automatically. Delaying package updates by a short period is less security theatre and more basic hygiene in a world plagued by supply chain attacks such as Mini Shai Hulud.

Questions and answers​

How does Mantle avoid scanning the same files repeatedly?​

The selector proposes more roots than the scan needs. The host first selects roots that do not appear in recent scan history. If it needs more roots, it adds changed prior roots and then unchanged prior roots. This process reduces repeat work, but it does not prohibit repeat scans.

How does Mantle identify duplicates when commits change file locations and line numbers?​

Mantle embeds each reviewed candidate and compares it with findings from the same organization and GitHub integration. Similarity scores of 0.90 or more cause automatic rejection. For scores from 0.50 to less than 0.90, a second agent decides whether the candidate is a duplicate. Mantle does not publish rejected duplicates.