New CloudThinker Security Agent runs continuous agentic penetration testing from commit to deployment

Today, we are announcing the CloudThinker Security Agent, an autonomous penetration testing system that runs continuously on every commit in your CI/CD pipeline. The Security Agent combines six domain-specialist agents — covering code, web, infrastructure, database, identity, and secrets — to discover the attack surface, plan exploits, validate them safely, and route remediation tickets directly to the developer who wrote the code, all in under 15 minutes per run.

Traditional security testing tools were designed for a world where engineering teams shipped weekly or monthly. AI-assisted development — what we refer to in this post as the AI-Driven Development Lifecycle (AI-DLC) — has compressed that cycle by three to five times. Static analysis (SAST), legacy dynamic scanners (DAST), and biannual manual penetration testing cannot keep up. The result is that verified vulnerabilities now sit in production for days at a time between scheduled audits.

In this post, we walk through the architecture, the six specialist agents, an end-to-end penetration test walkthrough, the OWASP API Security Top 10 report it produces, and how to enable continuous agentic pentesting in GitLab CI or GitHub Actions in four weeks. By the end you will know:

• Why SAST, legacy DAST, and biannual manual pentesting cannot keep up with AI-DLC
• How the six specialist Security Agents (@code-security, @web-security, @infra-security, @database-security, @identity-access, @secrets-guardian) map to a modern SaaS stack
• What a 15-minute, end-to-end pentest looks like — from git push to a verified, safe proof-of-concept
• How to wire the Security Agent into a GitLab CI/CD pipeline with a single webhook
• Where to start in the CloudThinker documentation

The Security Agent in CloudThinker's Multi-Agent System

The Security Agent is one of the domain specialists in CloudThinker's Multi-Agent System (MAS), working alongside the Cloud Engineer, Kubernetes Engineer, Database Engineer, and Principal Generalist agents shown above. Each specialist agent is built on the same platform foundation and follows the same operating model:

• Pre-installed Skills. Every specialist ships with a curated set of Skills from the CloudThinker Skills Library. For the Security Agent, that includes vulnerability scanning, exploit chaining, safe proof-of-concept generation, OWASP mapping, and report rendering — ready to use on day one.
• Sandbox-isolated execution. Every Skill runs inside a per-task microVM with strict egress policies, ephemeral storage, and a tamper-evident audit trail. See Sandbox Isolation for the full model.
• Connections to your stack. CloudThinker Connections wires the agents into GitLab, GitHub, AWS, Azure, GCP, Amazon EKS, your identity provider, and your ticketing system, so the Security Agent can read the diff, scope the test, and file the Jira ticket without manual setup.
• Use out of the box, or build advanced custom. Teams can deploy the Security Agent with the default Skills and Rules of Engagement in minutes. As the environment grows, teams can author custom Skills aligned with their stack using /create-skill and the Skills Framework — the same authoring model that powers every other specialist agent on the platform.

This positioning matters for the rest of the post. Everything we describe below — the six sub-specialists, the 15-minute walkthrough, the OWASP report, the four-week rollout — is the Security Agent specialist at work, drawing on the same platform primitives that the Cloud, Kubernetes, and Database specialists already use in customer environments.

---

The challenge

AI-assisted development has fundamentally changed engineering throughput. Teams using Claude Code, Cursor, and similar tools routinely ship in hours what previously took days. The security testing layer, however, has not adapted to that cadence. Three structural problems make traditional tooling unsuitable for AI-DLC:

• Static analysis tools (such as SonarQube and Trivy) lack runtime context. They review source files on disk and surface every CVE in the dependency tree, including transitive packages that no runtime ever loads. In one customer environment, an SCA scanner reported 847 critical CVEs; reachability analysis later showed that 3 were exploitable and 844 were dead code. The triage cost was three engineer-weeks.
• Legacy DAST scanners are blocked by modern authentication. Web crawlers and fuzzers were designed for unauthenticated HTML applications. JWT, OAuth, and MFA — present in essentially every modern SaaS — return 401 to the scanner, which then marks the route as "unauthenticated" and stops. In customer engagements we have measured 90% of authenticated API surface left untested.
• Manual penetration testing does not scale to AI-DLC cadence. A typical enterprise pentesting contract costs $150,000 or more per year and produces a report twice a year. Between engagements, the code can change 200 times. By the time the report is delivered, most findings reference code paths that no longer exist.

The result is a coverage gap that grows with every AI-accelerated commit.

---

Solution overview

The CloudThinker Security Agent is a multi-agent system that runs continuous, agentic penetration testing triggered by CI/CD events. Each agent is a domain specialist with its own Skill, backed by the Guardrails Engine and executed inside Sandbox Isolation. The agents collaborate to discover the attack surface, plan an exploit chain, validate it with a safe proof-of-concept, and route the finding to the developer who wrote the code — all in a single pipeline run.

The following architecture diagram illustrates the moving parts of a typical web/API penetration test.

The system has four primary components:

1. CI/CD trigger. A merge or post-deployment webhook from GitLab CI or GitHub Actions starts a pentest run. Interactive runs are also supported through a saved ChatOps Command — for example, calling /pentesting-web-api from any workspace channel.
2. Security Agent. The @web-security agent (and any other specialists scoped into the run) executes inside an isolated, per-run microVM with strict egress policies and a full audit trail.
3. Target backend. The agent fetches the live OpenAPI or GraphQL schema, parses the client-side single-page application bundle, and fuzz-scans the staging API endpoint under the configured Rules of Engagement. Production data is never read or modified.
4. Alerts and ticketing. Verified critical findings are dispatched in parallel to Slack, Microsoft Teams, email, Jira, and the CloudThinker Inbox, each enriched with the abstract syntax tree (AST) reference of the offending code, a suggested patch, and the safe proof-of-concept that confirmed the vulnerability.

The entire pipeline runs over HTTPS post-deployment webhooks. No agent needs to be installed inside the customer cluster.

---

How the Security Agent tests

The Security Agent reproduces, in software, the three loops that a human penetration tester executes during a manual engagement:

1. Surface discovery. The agent parses the SPA bundle, enumerates the API routes that the front end calls in practice, and resolves authentication state (JWT, OAuth, session headers) from the Rules of Engagement.
2. Cognitive planning and exploit chaining. Using a closed-loop ReAct reasoning pattern, the agent correlates multiple independent low-severity findings — a verbose error response, a CORS misconfiguration, a missing authorization check — into a multi-stage attack path.
3. Safe active verification. The agent generates a read-only proof-of-concept (for example, a non-mutating SQL subquery, a loopback SSRF, or a header echo) and executes it inside the staging environment. If the exploit succeeds, the finding is confirmed and a ticket is filed; if it does not, no alert is raised.

This third step is the source of the Security Agent's low false-positive rate: every reported finding is backed by an exploit that the platform has actually executed against the running system, under the safety boundaries defined in the Rules of Engagement.

---

The six specialist agents

CloudThinker does not ship a single, monolithic security agent. The platform ships a team of six domain specialists, each scoped to a clear part of the attack surface and each backed by a purpose-built Skill from the CloudThinker Skills Library.

Every agent inherits the same platform primitives: the Guardrails Engine enforces input and output policies on every model call, Sandbox Isolation bounds the blast radius of every action, the Knowledge Base preserves prior findings across runs, and Auto Mode provides graduated-autonomy controls so customers can choose whether each agent notifies, suggests, requests approval, or acts autonomously. The full reference is published at docs.cloudthinker.io.

Agents can be invoked through a saved Command — any prompt you save, callable from chat with a /-prefix name. For example:

/pentesting-web-api --target api.staging.example.com

Or directly from Slack or Microsoft Teams using the ChatOps interface:

@web-security white-box pentest api.example.com, build OWASP top-10 report, alert #alert on criticals

@web-security show me the attack path for P0-1

@web-security open the merge request to fix the issue

In the example above, three ChatOps messages invoke three different agents working in parallel, producing one Jira ticket with a patch attached.

---

Walkthrough: an end-to-end 15-minute pentest

The following walkthrough is from a representative customer environment. Timestamps are minutes elapsed from the initial Git push.

• T+00:00 — A developer merges the feature/billing-export branch to dev. The pull request adds a new endpoint, GET /api/billing/{org_id}/export.
• T+00:01 — A GitLab webhook fires. The @web-security agent receives the diff, the staging URL, and the Rules of Engagement for the target.
• T+00:03 — The agent parses the SPA bundle, identifies the new route, and observes that the client SDK passes org_id from the URL straight to the query layer without an explicit authorization check.
• T+00:05 — First finding: a suspected Insecure Direct Object Reference (OWASP API3:2023 — Broken Object Property Level Authorization) on the org_id path parameter. The finding is not yet ticketed because it could be a false positive.
• T+00:09 — The agent chains a second finding (a verbose 500 response leaks the SQL query template) with the suspected IDOR. The chain forms a plausible exploit hypothesis.
• T+00:12 — The agent generates a read-only proof-of-concept: a parameterized SELECT against the export endpoint using a sibling org_id known to belong to a different tenant in the staging namespace. The query returns rows from the other tenant. The exploit is confirmed.
• T+00:13 — A Jira ticket is opened. Severity: P0 (Critical). Attachments include the AST reference of the missing authorization check, a four-line suggested patch, the safe proof-of-concept script, the staging trace, and the corresponding OWASP API Top 10 reference.
• T+00:15 — The merge into main is blocked. The original developer receives a Slack notification with the patch pre-staged for review.

In this example, the elapsed time from commit to verified, ticketed, and patch-attached finding was 15 minutes. The same speed as the AI assistant that wrote the feature.

---

Sample output: OWASP API Security Top 10 report

Every Security Agent run produces an executive-ready report mapped to the OWASP API Security Top 10 (2023), with severity classification, action priorities, and the safe proof-of-concept attached for every finding.

The report above is representative of a typical first run on a customer's authenticated SaaS API. The scan covered both black-box and white-box (authenticated) phases. The black-box phase ran first against the public surface; the white-box phase followed, using test credentials passed in the Rules of Engagement. The report distinguishes the 10 findings that require immediate action (severity P0 and P1) from those that can be addressed in the next sprint cycle.

Reports are also exported as DOCX, PDF, and Markdown so they can be handed directly to compliance reviewers, customers, and auditors — including the artifact pattern used during SOC 2 Type II audits.

---

Customer outcomes

In customer engagements to date, the Security Agent has consistently delivered the following outcomes compared to a legacy SAST + DAST + biannual-pentest baseline.

The most significant operational metric, however, is one that does not appear in these statistics: the time that any single critical vulnerability spends in a production environment. Customer measurements show this dropping from days, between scheduled audits, to under 24 hours from the original commit.

For comparable enterprise stories, see the CloudThinker case studies, including how Diaflow achieved SOC 2, HIPAA, and GDPR readiness across three regions in four weeks, and how F88 operates a regulated DevSecOps program across more than 800 branches.

---

Phased rollout

CloudThinker recommends that customers adopt active agentic penetration testing in four phases, over approximately four weeks. The phased approach allows the security and platform teams to validate each capability before the next is enabled.

• Week 1 — Passive audit. Reconnaissance, certificate transparency log analysis, TLS validation, and subdomain enumeration. The objective is to produce a complete attack-surface map without sending any active traffic to production systems.
• Week 2 — Active web and API scan. The @web-security and @database-security agents are scoped to staging subnets only (for example, 10.x.0.0/16). The platform begins generating findings, but no exploits are executed yet.
• Week 3 — Safe exploit engine. The platform is configured to execute read-only proof-of-concept exploits. Findings are now confirmed by automated PoC execution before they are reported.
• Week 4 — Strict CI/CD blocking. The Security Agent is connected to GitLab or GitHub merge gates. Verified critical exploits block the merge, open a Jira ticket, and page the on-call engineer in Slack.

At the end of Week 4, no critical exploit can land in main without an agent either testing it or recording that it could not be tested. The full rollout playbook is published at docs.cloudthinker.io.

---

Best practices: developing your own Security Agent for each domain

The Security Agent ships with default Skills for each domain, but every customer environment is different. The following workflow is the recommended way to customize Olivier (or any specialist) to your stack, persist that customization as a reusable Skill, and scale it across your CI/CD pipeline.

1. Start with a prompt to @olivier

Begin in chat. Do not write a Skill from scratch. Describe in natural language what you want Olivier to test, the methodology, and the output format:

@olivier please help to pentest the web API with black-box and white-box
testing per OWASP Top 10, and export the report with CVE mapping.

Olivier executes this as a one-shot run inside Sandbox Isolation. It autonomously maps the attack surface (black-box phase), resolves the authentication flow using credentials from your Rules of Engagement (white-box phase), runs the OWASP Top 10 checks, validates each finding with a safe proof-of-concept, and exports the final report with CVE mapping and AST references. Treat this first run as a calibration step — review the discovered surface, the credentials Olivier used, and the findings, then refine the prompt if anything is wrong for your environment.

2. Persist the run as a reusable Skill with /create-skill

Once a one-shot run produces a useful report, persist it as a reusable Skill using the Skills Framework:

/create-skill pentesting-web-api
  --from-thread #current
  --scope api.example.com
  --auth bearer-via-login
  --owasp top-10
  --report cve-mapped

Olivier captures everything needed to repeat the test deterministically:

• The endpoint patterns it discovered (for example, /v1/billing/{org_id}/export)
• The authentication flow (login URL, token refresh interval, header injection rules)
• The Rules of Engagement (allowed HTTP methods, rate limits, destructive operations to avoid)
• Environment-specific validation logic (for example, "skip endpoints tagged internal-only" or "only test API version v2 or higher")
• Secret bindings (workspace secrets for shared values, Skill-scoped secrets for the test, per-run injection for ephemeral tokens — all encrypted at rest, redacted from prompts, and excluded from logs)
• The notification routing (Slack channel, Jira project, severity thresholds)

The result is a domain-specific Skill — pentesting-web-api — that codifies the conventions of one part of your platform. Skills are versioned and stored in the Knowledge Base, available to every team member with workspace access. The same workflow applies to every other specialist: build pentesting-postgres for @database-security, pentesting-corp-sso for @identity-access, and so on.

3. Run the Skill: /pentesting-web-api

Once the Skill exists, every subsequent pentest is one command:

/pentesting-web-api

That is the whole call. Same Rules of Engagement. Same discovered surface. Same auth flow. Same CVE-mapped report. Re-running a Skill is deterministic — no re-prompting, no re-discovering the API, no drift in the methodology between runs.

4. Scale: automate with webhook and schedule triggers

Skills can also be invoked without a human in the loop. Two automation patterns cover the majority of use cases:

• Webhook triggers. Wire /pentesting-web-api into GitLab CI, GitHub Actions, or a post-deployment webhook so the Skill runs on every merge into main or every staging deployment. The pipeline blocks on verified critical findings and posts the report to Slack, Microsoft Teams, or the CloudThinker Inbox.
• Schedule triggers. Set a cron schedule (for example, nightly at 02:00 UTC) so the Skill performs a continuous baseline scan of staging, with diffs against the previous run delivered to your security channel each morning.

The full reference for trigger configuration is published at docs.cloudthinker.io.

Tip: Olivier learns and updates your Skills at runtime

When the underlying environment changes — a new endpoint is added, the authentication flow is updated, a query parameter is renamed — Olivier detects the drift on the next run and proposes an update to the Skill. The proposed update appears as a Skill diff in the Knowledge Base, reviewed and approved by a human before it merges into the Skill definition.

Over time, the Skill stays aligned with the live environment without manual maintenance. This mirrors the Auto Mode graduated-autonomy framework: start in Notify, where the agent proposes Skill diffs; move to Act with approval once the team trusts the proposals; promote to Autonomous for routine, low-risk updates. The same trust ladder applies whether the agent is proposing a code change, a runbook update, or a Security Skill diff.

---

Getting started

The fastest path to a first pentest run is three steps:

1. Connect the repository and the staging environment. CloudThinker Connections ships with first-party integrations for GitLab, GitHub, AWS, Azure, GCP, Amazon EKS, and the major identity providers. Documentation is available at docs.cloudthinker.io.
2. Define the scope. Configure the Rules of Engagement, including target hostnames, authentication credentials, staging subnets, and the OWASP categories to be evaluated. Out of the box, the Security Agent maps to OWASP API Security Top 10 (2023) and OWASP Top 10 for Web.
3. Wire the webhook. Add the post-deployment webhook to the GitLab CI or GitHub Actions pipeline. The Security Agent will then run on every merge and publish findings to Slack, Microsoft Teams, Jira, or the CloudThinker Inbox.

To run an interactive scan, invoke a saved Command from chat:

/pentesting-web-api \
  --target api.staging.example.com \
  --owasp api-top-10 \
  --notify "#sec-criticals"

For team-level adoption, the Auto Mode graduated-autonomy controls allow customers to begin in Notify mode and progressively move to Act with approval or Autonomous as confidence grows.

---

Related reading

• CloudThinker Security — defense in depth across infrastructure, application, and agentic layers
• Introducing Olivier: CloudThinker's SuperPower Security Agent for Cloud — the cloud posture sibling of the testing agent
• Skills Framework — modular, composable agent capabilities
• Auto Mode — graduated autonomy with safe defaults
• Diaflow case study — SOC 2, HIPAA, and GDPR across three regions in four weeks
• CloudThinker documentation

---

Conclusion

AI-assisted development has changed how quickly code reaches production. Security testing has not yet caught up. The CloudThinker Security Agent closes that gap by running continuous, agentic penetration testing on every commit, validating findings with safe proofs-of-concept, and routing remediation directly to the developer who wrote the code — all within the same conversational tempo as the AI tools that generated the change.

To learn more, visit the CloudThinker Security page, explore the documentation, or book a demo to see the Security Agent in action.

— Steve Tran, CTO, CloudThinker