Introducing CloudThinker's SuperPower Security Agent for Cloud

It's 2:47 AM and GuardDuty has raised UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS on a production account. The on-call security engineer opens the finding, copies the access key ID, opens CloudTrail in another tab, filters by the key, scrolls, opens the IAM console to see what the role can do, checks whether the source IP belongs to the CI provider, and starts a note for the incident channel. Forty minutes later they know whether it's real.

I've spent over a decade building and securing cloud infrastructure, from startups shipping their first container to enterprises running thousands of workloads across multi-account AWS. I've been that engineer at 2:47 AM. I've written 80-page compliance reports by hand. I've watched teams burn out, not because they lacked talent, but because the tooling asked too much of them.

The problem was never the people. It was the model.

Your cloud runs 24/7. Your security engineer should too.

---

Why scanners stop where security work starts

Every security tool I used followed the same pattern: scan, produce a list of findings, hand it to a human. The tools are good. Checkov is excellent at IaC scanning. Prowler is excellent at cloud posture. Trivy is excellent at container CVEs. The trouble is structural:

• Each scanner sees one layer. Checkov sees the Terraform, Prowler sees the account, Trivy sees the image. "This open security group fronts an RDS instance with PII, and that image has a reachable CVE" is a join no single scanner makes.
• Severity has no context. A 0.0.0.0/0 rule on a sandbox and the same rule on the payments database both come back as "high". Ranking them needs topology and data classification the scanner doesn't have.
• Compliance mapping is manual. Which finding breaks PCI-DSS Requirement 1.3, and which is a SOC 2 exception you already accepted, lives in someone's spreadsheet.
• Response is a runbook in a wiki. Going from a GuardDuty finding to CloudTrail forensics to containment is a sequence a senior engineer knows by heart and a junior engineer reads for the first time at 3 AM.

That mental overhead (the context switching, the cross-referencing, the knowledge that lives in one person's head) is what breaks teams. So we built something different.

---

Meet CloudThinker's security agent

CloudThinker's security agent is an agentic security engineer with 20 purpose-built security skills from CloudThinker's Skills Hub, which already offers 1000+ pre-built, composable AI skills for cloud operations.

It isn't a dashboard or another scanner. It's a security engineer that:

• Runs Checkov, Prowler, Trivy and kube-bench in parallel
• Reads CloudTrail logs and builds incident timelines
• Writes the compliance report your auditor needs, with evidence attached
• Learns from every scan, so each finding strengthens future prevention

I've worked with security teams across dozens of organizations, and the pattern is always the same: skilled engineers drowning in alerts, spending 70% of their time on toil that should be automated. The agent doesn't replace those engineers. It gives them their time back for architecture, threat modeling and the decisions that need human judgement.

01Scanners and signals

Your estate

• GuardDuty, CloudTrail, IAMRead access to findings, events and policies
• EKS clusterskube-bench, admission and network policy
• Repositories and pipelinesCheckov, TruffleHog, CI/CD config
• Images and registriesTrivy CVEs and SBOMs

Read-only to start

02Reasoning

CloudThinker

• Pick the skillsOne request, several scanners in parallel
• Join the findingsKnowledge graph: topology, data, history
• Map and proposeCompliance controls, fix, rollback

Writes wait for approval

03Where the team works

Chat and tickets

• Slack or TeamsFindings and approvals in the thread
• JiraRemediation tickets with evidence
• Auditor reportControls, evidence, exceptions

Nothing new to watch

---

How it works

The hard part was never any single tool. It's orchestration: knowing which tools to run, in what order, and how to connect their outputs into one picture.

That's what the agent does. Each of the 20 security skills is a self-contained capability, with its own tools, instructions and domain knowledge, and the agent picks the ones a request needs.

Ask "Scan our EKS clusters for CIS compliance" and it runs kube-bench, the CIS benchmark, an admission control review and a network policy audit in parallel. Tell it "We got a GuardDuty alert" and it chains detection, forensics, containment and the timeline.

The skills aren't isolated scanners. They share context through CloudThinker's knowledge graph, so IAM findings inform network policy, GuardDuty alerts trigger CloudTrail forensics, and incident timelines feed back into prevention rules. That cross-domain reasoning used to live only in your most senior security engineer's head. Now it's written down and always on.

Under the hood the commands are the ones your team would run. For a first posture pass, for example:

# Cloud posture against CIS
prowler aws --compliance cis_2.0_aws

# Terraform misconfigurations before they deploy
checkov -d ./terraform --framework terraform

# High and critical CVEs in a running image
trivy image --severity HIGH,CRITICAL <registry>/<image>:<tag>

The difference is what happens after. The agent reads the three outputs together, drops the findings that don't matter in your topology, maps the rest to controls, and proposes fixes.

---

Walkthrough: the 2:47 AM GuardDuty finding

Back to the finding from the opening. Here's how the agent works it, hypothesis first.

01Detect

Finding

GuardDuty flags instance credentials used from outside AWS.

02Forensics

CloudTrail

Every call made with that key, from where, in what order.

03Contain

Proposal

Revoke sessions and snapshot the instance, waiting for approval.

04Learn

Prevention rule

The gap that allowed it becomes a check on every future change.

The finding. InstanceCredentialExfiltration.OutsideAWS means credentials issued to an EC2 instance role were used from an IP address outside AWS. There are three plausible readings, and each predicts something different:

Check the key's activity. The agent pulls every event made with the access key in the finding:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=<access-key-id> \
  --start-time <finding-time-minus-6h> \
  --max-results 50

The calls come from an IP outside both your VPN range and your CI provider's published ranges. The sequence is GetCallerIdentity, then ListBuckets, then GetObject against a bucket tagged data-classification: pii. That matches the first reading and rules out the other two.

Check the blast radius. The role's attached policies grant s3:GetObject on *. That's the over-permission that made the theft valuable, and it's the finding the IAM least-privilege skill would have raised weeks ago.

Propose containment. The standard way to cut off stolen role credentials is to deny every session issued before now, which is what the IAM console's "Revoke active sessions" does:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "DateLessThan": { "aws:TokenIssueTime": "<now-in-utc>" }
      }
    }
  ]
}

The proposal in the incident thread is: attach that inline policy to the role, snapshot the instance's volumes for forensics, and replace the instance from a known-good image. Each step lists its rollback and waits for approval.

Write it down. The timeline skill assembles CloudTrail, VPC Flow Logs and GuardDuty into one ordered record, and the incident becomes a prevention rule: the least-privilege policy for that role, generated from what it actually called in the last 90 days.

The engineer's 40 minutes of tab-switching becomes a few minutes of reading a finding with the evidence attached.

---

Containment stays under your control

Security actions are exactly the ones you don't want an agent improvising. CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval. Every scan, finding, proposal, approval and change lands in the audit trail.

---

Real output: Kubernetes security assessment

One prompt, "Scan helm security issues and build SOC compliant dashboard", produces this:

I've seen consultants charge $30K to $50K for an assessment that delivers less than this in minutes. Not because the consultants aren't good, but because a person can only hold so much context at once. The agent doesn't forget, doesn't get tired at 3 AM and doesn't bill by the hour.

---

20 skills, three domains, one agent

When I designed the skill set, I drew from every security engagement I've led. The question wasn't "what tools exist?" It was "what does a senior security engineer do day to day, and what keeps them up at night?"

The answer fell into three domains: prevention (stop bad things before they deploy), detection and response (catch and contain what gets through), and compliance (prove to auditors you're doing both).

01Prevention

12 skills

IaC, posture, containers, Kubernetes, secrets, IAM, network, TLS, CI/CD and CVE priority.

02Detection and response

4 skills

GuardDuty analysis, CloudTrail forensics, containment and the incident timeline.

03Compliance

4 skills

CIS benchmarks, policy as code, encryption audit and data classification.

Most teams start with prevention: IaC scanning, CSPM and secrets detection. That alone removes most misconfigurations before they reach production. As your posture matures, you add detection and compliance. The skills compose: a GuardDuty alert triggers CloudTrail forensics, which feeds the incident timeline, which maps to compliance controls.

You don't configure 20 tools. You tell one agent what you need.

Every skill is in the Skills Hub: browse, activate and customize for your environment.

---

How it extends

In every organization I've worked with, the hardest security problems aren't generic. They're specific: your compliance framework, your incident runbook, your escalation paths, your internal tooling. Off-the-shelf products can't encode that knowledge, so it stays in people's heads, old wiki pages and Slack threads nobody can find.

The 20 security skills are the starting point. The Skills Hub already offers 1000+ pre-built, composable skills across observability (Datadog, Prometheus, Grafana), databases (PostgreSQL, MongoDB, Redis), CI/CD (GitLab, GitHub, Jenkins, Terraform), Kubernetes (ArgoCD, EKS, GKE), cost optimization and more. The security skills are built on the same open architecture, so you can:

• Compose across domains. Chain security skills with operational ones: "On every PR, run an IaC scan, secrets detection and a least-privilege check, then post the results to Slack."
• Add your own compliance frameworks. Encode your organization's security policies as skills that run alongside the built-in 1000+.
• Turn runbooks into skills. Incident procedures, escalation paths and remediation playbooks. I've seen teams convert a 20-page IR playbook into a skill in an afternoon, using the same pattern as the deployment checklists and DNS cutover skills in the Hub.
• Wrap new tools. Your own scripts, third-party scanners and internal APIs, the same way the Hub integrates Checkov, Prowler, Snyk, tfsec, Trivy and Kubescape.

Build your own in minutes

CloudThinker's Skills Framework keeps it simple. A skill is a declarative SKILL.md file that defines the trigger patterns, required tools, guardrails and output schema. Three steps:

1. Describe the operation in plain language, or point to an existing runbook.
2. Generate. CloudThinker writes the full SKILL.md with tools, guardrails and structured output.
3. Deploy. Test, refine, go live. The skill is immediately available to the security agent.

No code required. Your team's security knowledge becomes a reusable, governed capability instead of something that walks out the door with one person.

Learn how at cloudthinker.io/skills/framework, or browse 1000+ skills at cloudthinker.io/skills.

---

Why this beats the traditional approach

The deeper difference comes from three architectural decisions I made early and refused to compromise on.

Skills, not scripts. Each skill carries domain knowledge: not just what to scan, but why a finding matters, how to fix it and which controls it maps to. A script finds an open security group. A skill explains which services are exposed, what data flows through them, and whether it breaks PCI-DSS Requirement 1.3.

A knowledge graph, not flat reports. Every finding is connected to infrastructure topology, past incidents and compliance frameworks. The agent doesn't just flag 0.0.0.0/0. It knows this security group is attached to a production RDS instance that stores PII, and that the same misconfiguration caused a P1 three months ago. Without that context, you're generating noise.

Compound learning. Validated findings get reinforced, false positives get deprioritized, and your team's remediation patterns become the agent's recommendations. Over time it carries the context of a senior security engineer who's been on the team from the start.

---

Getting started

1. Browse the Skills Hub to see the 20 security skills alongside the 1000+ others.
2. Connect your AWS account with read access to CloudTrail, GuardDuty, IAM and security groups.
3. Connect your Kubernetes clusters for EKS security scanning.
4. Start with one prompt:

"Run a full security assessment of our production AWS account and EKS clusters. Rank findings by real exposure, map them to SOC 2 and CIS, and propose fixes. Propose only, change nothing."

"We got a GuardDuty credential exfiltration finding on the payments account. Pull the CloudTrail activity for that key, tell me whether it's real, and propose containment with rollback steps."

"Which IAM roles have permissions they haven't used in 90 days? Draft least-privilege policies for the five riskiest."

The first scan usually surfaces findings hiding in plain sight: open security groups, over-permissioned IAM roles, unencrypted S3 buckets, missing CIS controls. The kind experienced engineers know to look for, and that get missed when teams are stretched thin and moving fast.

I've seen it at every company I've worked with: the expertise exists, but the bandwidth doesn't. The security agent closes that gap.

---

Your cloud infrastructure runs 24/7. Your security engineer should too.

Explore the full skills library at cloudthinker.io/skills