Claude Code and Prowler MCP make CIS compliance conversational

At a glance

What this is: This is a walkthrough of using Prowler MCP with Claude Code to query compliance, inspect failures, and optionally remediate issues from live scan data.

Why it matters: It matters because once a compliance assistant can read findings and trigger fixes, IAM, secrets handling, and approval boundaries become part of the control design, not an afterthought.

By the numbers:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.

👉 Read Prowler's walkthrough of Claude Code compliance checks through MCP

Context

Compliance workflows often fail because the data lives in one place and the action happens somewhere else. This article is about using Prowler MCP to collapse that gap so a terminal-bound assistant can query scan results, identify failed CIS requirements, and guide remediation without forcing practitioners through dashboard clicks.

The identity concern is real even though the topic is cloud compliance. The Prowler API key is effectively a privileged non-human credential, and the optional remediation step depends on the boundary between read access to findings and write access through local cloud credentials. That makes this a useful example of where NHI governance and operational security intersect in routine cloud work.

The starting position is increasingly typical for teams that already use cloud posture tooling but still rely on manual navigation to turn findings into action.

Key questions

Q: How should security teams govern AI assistants that can access audit data?

A: Treat them as privileged non-human identities with defined scope, logging, and approval boundaries. Access should be limited to the smallest useful data set, and any output that can influence operations should require human authorization before execution. That approach reduces the chance that an AI assistant becomes an unreviewed control point inside security operations.

Q: What breaks when a compliance assistant uses the same identity for reading findings and making changes?

A: You lose the boundary between observation and action. Once one credential can inspect posture and alter infrastructure, a diagnostic workflow can become an uncontrolled change path. That increases blast radius, weakens auditability, and makes it harder to prove who approved the final state.

Q: How do teams know if an AI-driven compliance workflow is actually controlled?

A: Look for three signals: tightly scoped tool access, separate identities for read and write actions, and an approval record for every applied fix. If the assistant can reach multiple providers, edit infrastructure, or operate without clear logs, the workflow is drifting beyond its intended control boundary.

Q: Who is accountable when an assistant applies a remediation that changes cloud configuration?

A: The organisation remains accountable, but ownership should be explicit across the IAM, cloud, and operations teams. The person approving the change, the team granting the credential, and the system owner all need traceable responsibility. That is the only way to keep agent-assisted remediation inside governance.

Technical breakdown

How MCP changes the compliance interaction model

Model Context Protocol provides a standard way for an AI client to call tools exposed by an external service. In this flow, Claude Code does not infer compliance from prose. It queries Prowler tools that return providers, scans, framework summaries, failed requirements, and finding details. The technical shift is from static reporting to tool-mediated retrieval, where the model can ask structured questions against the latest completed scan. That reduces friction, but it also means the quality of the underlying data, permissions, and tool boundaries now shapes the security outcome.

Practical implication: define exactly which MCP tools are read-only, which are operational, and which require separate approval.

Why the API key is the first control boundary

The Prowler API key used by the MCP is a non-human credential that authorises the assistant to read findings across the tenant. Because the key starts the session and reaches the full compliance dataset, it behaves like a secret with broad visibility, even if it is not allowed to mutate cloud state. In identity terms, this is a workload credential with high information value. If it leaks through config files, shared repos, or terminal history, an attacker does not need to compromise the cloud directly to learn where the organisation is weak.

Practical implication: store MCP credentials out of shared configuration and rotate them as sensitive NHI secrets.

How optional remediation crosses from read-only to write access

The article is explicit that remediation is not performed by the MCP itself. The fix step uses the cloud credentials already available to Claude Code locally, which can mean AWS profile access, Terraform changes, or another infrastructure interface. That creates a clean architectural split: the assistant reads compliance posture through the MCP and writes changes through separate operational credentials. The security question is whether those credentials are scoped narrowly enough that a diagnostic assistant cannot become an uncontrolled change agent.

Practical implication: separate diagnostic identity from remediation identity and require human approval before any write action.

Threat narrative

Attacker objective: The attacker wants to turn a trusted compliance assistant into a pathway for reading sensitive posture data or applying unauthorised changes.

1. Entry occurs through a privileged non-human API key or local cloud credential that gives the assistant access to compliance telemetry and, in some cases, remediation paths.
2. Escalation happens when the same workflow can move from read-only findings to infrastructure changes, especially if the write credential is broadly scoped.
3. Impact is unauthorised policy drift, exposure of security findings, or cloud changes made without the intended human review boundary.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• New York Times breach — New York Times source code and credentials exposed via GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Conversations are becoming a control surface, not just a user interface. When a compliance assistant can interrogate live scan data and translate findings into remediation steps, the real security boundary moves to the identity behind the conversation. That requires the same discipline applied to service accounts, automation tokens, and privileged workflows. Practitioners should treat the assistant as an operational actor with constrained authority, not as a harmless interface.

Non-human credentials now sit on the critical path for governance workflows. The API key in this model is not just an access token, it is the key to posture visibility across an environment. If that credential is overexposed, the organisation has effectively exported its control-plane intelligence into an unmanaged NHI. The governance gap is not the model, it is the absence of lifecycle control around the credential that powers the model.

Split-read and write workflows are the right pattern for agent-assisted compliance. The article’s architecture is strongest when the assistant can inspect and explain, but only humans or tightly scoped automation can apply changes. That pattern aligns with least privilege and preserves auditability across cloud and identity workflows. The practitioner conclusion is simple: diagnostic autonomy is acceptable, remediation autonomy must remain bounded.

Prowler-style compliance automation exposes a broader NHI governance problem: discovery without lifecycle control. The more tools an assistant can call, the more likely organisations are to create persistent machine identities that outlive the job they were meant to do. This is the same failure mode seen across NHI sprawl, where access is created for convenience and never retired with the workflow. Practitioners should design for expiry, not just access.

Cloud compliance tooling and agentic AI are converging on the same identity question. Whether the subject is CIS scanning, infrastructure changes, or workflow automation, the decisive issue is who or what is allowed to act on behalf of the organisation. That intersection belongs inside IAM, PAM, and NHI governance rather than in a separate AI experiment. Practitioners should align agent access with existing identity controls instead of inventing parallel trust models.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• From our research: Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• From our research: For a deeper view of how these controls map to identity governance, see Ultimate Guide to NHIs , Regulatory and Audit Perspectives.

What this signals

Non-human access is becoming the hidden dependency in AI-assisted operations. As soon as an assistant can query findings, inspect remediations, and move into write actions, the programme needs a policy model for machine identities that is as explicit as human IAM. The relevant benchmark is not whether the assistant is useful, but whether its privileges are time-bound, reviewable, and revocable. For broader control alignment, map the workflow to the OWASP Agentic AI Top 10.

Ephemeral access is the safer operating model for assistant-driven remediation. Persistent credentials for diagnostic agents create the same lifecycle problem that has already burdened cloud service accounts and secrets sprawl. The better pattern is short-lived access tied to a specific provider, scan, or approval event, with logs that show exactly when the permission expired. That design fits the governance direction outlined in Ultimate Guide to NHIs , 2025 Outlook and Predictions.

The operational signal to watch is whether teams start trusting the assistant more than the control evidence. If the workflow is useful but the identity model is vague, the programme may be accumulating NHI debt faster than it reduces compliance effort.

For practitioners

• Scope MCP credentials as sensitive NHI secrets Keep the Prowler API key out of shared repositories and shared machine configuration, and rotate it on the same schedule you would apply to a privileged service account.
• Separate read-only analysis from remediation identity Allow the assistant to query findings with one credential path, then require a distinct human-approved path for cloud changes through AWS profiles, Terraform, or equivalent tooling.
• Require human approval before any write action Use an explicit confirmation step before the assistant can apply a fix, and log the proposed command, target resource, and approver for audit purposes.
• Prefer infrastructure as code over live patching When the assistant identifies a misconfiguration, update the declarative source of truth first so the correction survives the next deployment cycle instead of drifting back.
• Map assistant permissions to least privilege Limit the assistant to the smallest provider, framework, and scan scope needed for the task, and review tool namespaces before exposing any broader operational capability.

Key takeaways

• AI-assisted compliance becomes risky when the credential behind the assistant is broader than the task it performs.
• The control value comes from separating inspection, approval, and remediation rather than letting one identity do all three.
• Cloud teams should treat assistant permissions as NHI governance work, not as a convenience setting inside a tool chain.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Read-only remediation workflow: An operating pattern where an assistant can inspect findings and propose fixes but cannot change systems directly. The human remains the decision-maker, while the machine identity is limited to observation and recommendation. This reduces blast radius and keeps write privileges outside the diagnostic path.
• Tool namespace: A grouped set of capabilities exposed by an MCP server or similar interface. Tool namespaces matter because they reveal which actions are informational, which are operational, and which should require stricter approval before an AI system can call them.

What's in the full article

Prowler's full post covers the operational detail this analysis intentionally leaves for the source:

• Exact MCP setup commands and config file examples for Claude Code
• Step-by-step tool outputs for provider discovery, framework selection, and failed requirement drill-down
• The optional remediation workflow, including proposed cloud commands and Terraform plan handling
• Read-only versus write-capable workflow boundaries inside the Prowler tool namespaces

👉 The full Prowler post shows the exact MCP commands, failure drill-down, and optional remediation flow.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity controls into operating models for automation, agents, and cloud workloads.