Run your cloud security triage loop inside Claude Code: the Prowler plugin

A cloud security engineer’s day is mostly glue. A scan comes back with a few hundred failing checks. For each one that matters, you pull up what the check actually asserts, the compliance controls it maps to, the resource it fired on, what that resource is connected to, and whether the path leading out of it reaches anything sensitive. Then you write the fix, route it through change approval, and re-scan to prove it cleared. Finding the misconfiguration was the easy part. Assembling the context around it, and turning that into a reviewed, verified change, is the work.

The Prowler plugin for Claude Code automates that glue. It makes Claude Code a harness for your cloud security triage loop, and it gives the agent the structured context to run that loop credibly: the findings across your accounts, the resources and how they connect, the open-source logic behind every check, and the compliance frameworks each check maps to. The agent finds the misconfigurations, prioritizes them by real blast radius, tracks the work in your repo, opens the pull requests that fix them, and re-scans to confirm each one cleared.

Why this matters now

Two things changed.

First, Anthropic made plugins a first-class way to extend Claude Code. As the Claude Code documentation describes it, a single plugin bundles slash commands, subagents, skills, hooks, and MCP servers (Model Context Protocol servers, the standard way an agent talks to an external system) into one installable unit, and Anthropic now runs an official directory of them. That gives a security tool a clean way to ship not just an API connection but an entire opinionated workflow into the agent. Prowler ships one.

Second, the bottleneck in cloud security stopped being detection. Scanners have been finding misconfigurations for a decade. The expensive part is everything between a finding appearing and a fix landing with evidence: the triage, the context-gathering, the remediation, the proof. That glue is human hours, and it does not scale with the rate at which infrastructure now ships. AI-assisted development makes more cloud resources appear faster, which means more configuration drift and a larger triage backlog, not less.

An agent harness is a natural fit for glue work. The catch is grounding. An agent with no real context guesses, and a guessed change to a production IAM policy is exactly what a security team will not allow near production. So the question is not whether an agent can automate triage. It is whether it has the context to do it credibly and the controls to do it safely. That is the problem the plugin’s design is built around.

What the plugin is, and the context it carries

The plugin bundles two things: the Prowler MCP server and a skill called prowler:framework-compliance-triage. The skill is the workflow. The MCP server is what gives the agent its context.

Three things have to be in place: Claude Code installed and authenticated, a Prowler Cloud account (the free tier is enough to start), and an API key generated at cloud.prowler.com/profile. On first install, Claude Code stores that key so the plugin authenticates to your account and works against your own scan data.

What matters for a SecOps team is the depth of context the MCP server exposes. The agent is not reasoning from a one-line finding string. It can query, in structured form, the same things a senior analyst would open a dozen browser tabs to assemble:

• Findings across all connected accounts: an overview, the details of any single finding, and finding groups, so that one check failing on two hundred instances is one item to triage instead of two hundred rows. It can search and filter by service, severity, and status.
• Resources and their history: the configuration of a resource, the events that changed it over time, and how resources relate within an account.
• Attack paths: queries over the resource graph that show the exploitable path through connected resources, not just an isolated finding. This is the difference between “this bucket is public” and “this public bucket is reachable from a role that can read the production database.”
• The check catalog on Prowler Hub: every Prowler check’s description, its actual open-source logic, and its documented remediation. The agent can read what a check asserts and how Prowler recommends fixing it before it proposes anything.
• The compliance frameworks on Prowler Hub: every supported framework, the controls each check maps to, and your account’s current standing against a given framework.
• Scans: it can trigger a fresh scan or read the state of the latest one.

That surface is the whole point of the positioning. The agent’s reasoning is grounded in Prowler’s structured data and open-source logic, which is what separates automated triage you can trust from an agent improvising against your cloud.

Finding: from a scan to a working set

You describe the goal in plain language. The plugin’s own examples are the right shape:

“Make my AWS production account compliant with CIS 4.0.”

“Help me get to 100% on PCI-DSS for this GCP project.”

The skill queries your most recent scan and assembles the failing checks that bear on what you asked. A check is a single, named assertion about a resource. ec2_instance_imdsv2_enabled, for instance, flags any EC2 instance still accepting the older, token-less version of the instance metadata service, the weakness behind the 2019 Capital One incident. Because the agent pulls finding groups rather than raw rows, a check failing on hundreds of instances arrives as one item with its scope attached, not a wall of duplicates.

Prioritizing: severity, framework gap, and real blast radius

A list of three hundred failing checks is not a plan. The plugin orders the work three ways: by severity, by which checks actually close the compliance gap you named, and by blast radius drawn from the attack-path graph. That third axis is what keeps the list honest. A public storage bucket that an attack path connects to a role with production database access outranks an isolated low-severity finding, even when a severity label alone would not say so.

How this plays out depends on the mode you pick. In Claude-assisted mode, Claude presents each fix one at a time, with its target resources, the exact commands, the side effects, and whether the change is reversible, then waits for approval before doing anything. In Claude autonomous mode, Claude presents a single consolidated plan, grouped so that fixes sharing a root cause are handled together, asks for one confirmation, and proceeds, pausing only for wide-impact changes or findings it judges not applicable. Assisted mode is the right default the first time you run it on an account you care about. Autonomous mode is for when you have seen the pattern and trust it.

Grounding the fix in Prowler Hub

This is the step that earns a security team’s trust. Before proposing a remediation, the agent can pull the check’s actual logic and Prowler’s documented fixer from Prowler Hub, along with the compliance controls the check satisfies. The fix it proposes is anchored to what the check asserts and to published remediation guidance, not generated from the model’s general impression of cloud security. Because the check logic is open source, you can read it yourself, and you can see why the agent proposed what it did. For a team that will not let an opaque tool touch production, that auditability is the feature, not a footnote.

Tracking: an audit trail that lives in the repo

The plugin writes its progress to markdown reports under a .prowler/ directory in your repository. Tracking remediation as files in the repo means the work is versioned, diffable, and reviewable in the same place as your code. The state survives across sessions, so you can stop halfway and resume tomorrow with the plugin knowing what is fixed, what is pending, and what you decided to accept as a known exception. Accepted exceptions can be reflected as mute rules in Prowler, so the decision is recorded on both sides. For SecOps, this is the accountability layer: every change has a reason and a paper trail, not just an outcome.

Remediating and opening pull requests

Before it changes anything, the plugin asks which tool you want to remediate with: Terraform, a cloud CLI, the web console, or a mix. The answer shapes everything downstream.

Pick Terraform or another infrastructure-as-code path, and remediation becomes a code change. Claude edits the configuration, and because Claude Code already does git, it can open a pull request with the change, linked back to the finding in the .prowler/ report. The fix then goes through the same review your team uses for any other change, which is exactly where a change to a production IAM policy belongs. Pick the CLI or console path and the plugin gives you the precise commands or steps instead, for the cases where there is no IaC to edit.

Every proposed fix carries the same four pieces of context regardless of tool: the resources it touches, the exact commands it will run, the side effects to expect, and whether it can be rolled back.

Verifying: re-scan until the check passes

After a fix is applied, the plugin triggers a fresh scan and confirms the finding actually cleared. That last step closes the loop. You are not trusting that the change worked, you are checking that the check now passes and that your standing against the framework moved. Closing the finding and producing the evidence for it become the same action.

Where to start

Install the plugin from inside Claude Code:

/plugin marketplace add prowler-cloud/prowler
/plugin install prowler@prowler-plugins


The plugin documentation covers API key setup and the full configuration. Then point it at one account and one framework rather than everything at once. “Make my staging AWS account compliant with CIS 4.0” is a good first run: real enough to be useful, contained enough that you can review every change the plugin proposes and build trust in what it does before you let it near production.

Try Prowler Cloud free, no credit card required, at cloud.prowler.com.