What is MCP and Why Cloud Security Needs It

If you've been paying attention to AI tooling in 2025-2026, you've probably seen "MCP" mentioned. Maybe you've added MCP servers to Claude Desktop. Maybe you've built one. Maybe you have no idea what it is and you're tired of another acronym.

This post explains MCP from the ground up — what it is, how it works, and why it's the most important development for cloud security tooling since infrastructure as code.

That's a bold claim. Let's back it up.

The Problem MCP Solves

AI assistants (Claude, ChatGPT, Gemini, local models) are good at reasoning, explaining, and generating code. But they're stuck in a text box. They can't do things. They can't check your cloud configuration. They can't run a security scan. They can't look at your attack path graph.

Before MCP, if you wanted an AI to interact with an external tool, you had a few options:

Option 1: Copy-paste. Run a scan, copy the output, paste it into Claude, ask for analysis. This works but doesn't scale. You're the middleware.

Option 2: Custom function calling. Each AI platform has its own function calling mechanism. Build a custom integration for Claude, another for ChatGPT, another for Gemini. Maintain three codebases for the same capability.

Option 3: LangChain/agent frameworks. Write a Python script that orchestrates the AI and the tool. Fragile, custom, usually breaks when either side updates.

None of these are good. They're workarounds for a missing layer: a standard protocol for AI agents to interact with external tools.

What MCP Is

The Model Context Protocol (MCP) is an open specification that defines how AI agents communicate with external tools and data sources. Think of it as "USB for AI" — a standard connector that lets any AI agent work with any tool that implements the protocol.

MCP was originally created by Anthropic and is now supported by Claude, ChatGPT, and a growing ecosystem of AI agents and tool providers.

The Three Primitives

MCP defines three types of things a server can expose:

Tools

Functions the AI agent can call. They have:

• A name (`scan`, `query_graph`, `remediate`)
• A description (so the AI knows when to use them)
• A JSON Schema for parameters
• A structured return value

```json { "name": "scan", "description": "Run a security scan on a connected cloud account", "inputSchema": { "type": "object", "properties": { "account_id": {"type": "string", "description": "The cloud account to scan"}, "provider": {"type": "string", "enum": ["aws", "gcp", "azure", "kubernetes"]}, "framework": {"type": "string", "description": "Compliance framework (e.g., cis-aws-3.0)"} }, "required": ["account_id", "provider"] } } ```

Resources

Data sources the AI can read. Like files, but dynamic. In a cloud security context:

• `stratusec://accounts` — list of connected cloud accounts
• `stratusec://findings/aws-prod` — findings for the production AWS account
• `stratusec://graph/aws-prod` — the Neo4j security graph for that account

Resources have URIs, MIME types, and the AI agent can read them as context for its reasoning.

Prompts

Pre-defined interaction templates. For example, a "security review" prompt that tells the AI agent how to systematically analyze an account:

```json { "name": "security_review", "description": "Perform a comprehensive security review of a cloud account", "arguments": [ {"name": "account_id", "required": true} ] } ```

Transport

MCP supports two transport modes:

• stdio — the MCP server runs as a subprocess. Simple, local. This is how most desktop integrations work.
• HTTP/SSE — the MCP server runs as a web service. For remote access, shared instances, and team use.

How Stratusec Implements MCP

Stratusec's MCP server exposes the full platform through the protocol. Here's exactly what's available:

MCP Tools

MCP Resources

Setup

Add this to your Claude Desktop config (`~/.claude/mcp.json`):

```json { "mcpServers": { "stratusec": { "command": "stratusec", "args": ["mcp", "serve"], "env": { "STRATUSEC_CONFIG": "~/.stratusec/config.yaml" } } } } ```

Or run as an HTTP server for team access:

```bash stratusec mcp serve --transport http --port 8080 --auth-token $MCP_TOKEN ```

That's it. Your AI assistant now understands your cloud security posture.

Real-World Workflows

Let's walk through scenarios that demonstrate why MCP matters for cloud security.

Scenario 1: Morning Security Review

Without MCP:

1. Open terminal
2. Run `stratusec scan --account aws-prod`
3. Wait for results
4. Open dashboard, browse findings
5. Export critical findings
6. Paste into Claude for analysis
7. Read Claude's analysis
8. Manually apply fixes

With MCP:

You: "Good morning. Run a scan on our production AWS account and give me a summary of anything new since yesterday."

Claude: [calls scan tool, calls get_findings with date filter] "Scan complete. 3 new findings since yesterday:

1. Critical: New IAM role `data-pipeline-role` has `s3:*` on all buckets. Created 4 hours ago by `john@company.com`. This role is assumable by the `data-pipeline` ECS task.
2. High: EBS volume `vol-0abc123` attached to `prod-api-server` is unencrypted. Created with the new deployment at 2:15 AM.
3. Medium: CloudTrail logging was disabled in eu-west-1. Changed 6 hours ago.

The IAM role is the priority — I traced the attack path and that ECS task is in a public subnet. Want me to scope the IAM policy to just the buckets it actually needs?"

You: "Yes, scope it. And re-enable CloudTrail in eu-west-1."

Claude: [calls remediate with dry-run for both, then applies after confirmation]

That's 15 minutes vs. an hour. And the AI caught the attack path (public subnet + overpermissioned role) that a finding list wouldn't surface.

Scenario 2: Incident Response

An alert fires at 2 AM. Someone needs to investigate. Your on-call engineer opens Claude:

Engineer: "GuardDuty flagged unusual API activity from IAM role `lambda-processor` in us-east-1. What can that role access, and is there an attack path from it to anything sensitive?"

Claude: [calls query_graph with Cypher to trace role permissions and relationships] "The `lambda-processor` role has the following access:

• Read/write to SQS queue `order-processing`
• Read to DynamoDB table `orders`
• Read to S3 bucket `order-attachments`
• It can also assume `admin-role` via a trust policy misconfiguration — the trust policy allows `lambda.amazonaws.com` but doesn't scope to a specific function.

Attack path: `lambda-processor` → assume `admin-role` → full account access.

The GuardDuty finding shows 47 unusual `sts:AssumeRole` calls in the last hour. This looks like a compromised Lambda function attempting privilege escalation.

Recommended immediate actions:

1. Revoke active sessions for `lambda-processor`
2. Fix the trust policy on `admin-role`
3. Investigate the Lambda function for code injection"

The AI didn't just read an alert. It queried the security graph, traced relationships, found the escalation path, and provided actionable response steps. At 2 AM. In 30 seconds.

Scenario 3: Policy Development

Security Engineer: "I want to create a guardrail that prevents anyone from deploying an RDS instance without encryption and multi-AZ in production."

Claude: [calls validate_guardrail to check if a similar policy exists, then generates] "Here's the OPA/Rego policy: ```rego package stratusec.guardrails.rds

deny[msg] { input.resource_type == "aws_db_instance" input.tags.environment == "production" not input.config.storage_encrypted msg := sprintf("Production RDS '%s' must have encryption enabled", [input.resource_name]) }

deny[msg] { input.resource_type == "aws_db_instance" input.tags.environment == "production" not input.config.multi_az msg := sprintf("Production RDS '%s' must be multi-AZ", [input.resource_name]) } ``` I tested it against your current production RDS instances. All 4 pass. Want me to add this to your active guardrail policies?"

Why Not Just Use API Calls?

Fair question. Stratusec has a REST API. Why do you need MCP?

The AI Reasoning Layer

When Claude uses MCP tools, it doesn't just call APIs. It reasons about what to call, in what order, and how to interpret the results. It chains tools together:

1. Get findings → 2. For critical ones, query the graph → 3. Find attack paths → 4. Generate remediation → 5. Check remediation against guardrails → 6. Apply with dry-run

This multi-step reasoning happens in the AI's context window. It's not a script. The AI adapts based on what it finds.

Discovery

MCP tools are self-describing. The AI reads the tool descriptions and schemas and figures out when to use them. You don't need to write a prompt that says "when the user asks about compliance, call this API." The AI understands from the tool metadata.

Ecosystem

MCP is a standard. Stratusec's MCP server works with Claude, ChatGPT, and any MCP-compatible agent. Build once, work everywhere. If you built a custom Claude function calling integration, it only works with Claude.

Composability

Your AI agent can use Stratusec's MCP server alongside other MCP servers — your database, your CI/CD, your documentation. The AI reasons across all of them:

"Scan the cloud, find the issue, look up who deployed the change in GitHub, create a Jira ticket, and schedule the fix for the next maintenance window."

That's four MCP servers (Stratusec, GitHub, Jira, calendar) composed in one conversation.

The Security of MCP

Giving an AI agent access to your cloud security tools raises obvious questions:

Authentication

Stratusec's MCP server respects the same auth as the API. Local mode uses your CLI credentials. HTTP mode requires an auth token. Enterprise mode integrates with SSO/SAML.

Authorization

MCP tool calls go through the same RBAC as API calls. If your role can't remediate, the AI can't remediate on your behalf.

Audit

Every MCP tool call is logged. Who (which user/session), what (which tool, which parameters), when, and what happened. In enterprise mode, this feeds into your SIEM.

Approval Gates

Auto-remediation through MCP supports the same approval workflows as the API and CLI. The AI proposes, you approve. Dry-run is available (and recommended) for all remediation actions.

Principle of Least Privilege

You can scope which MCP tools are available per user/role. Read-only users get `scan`, `get_findings`, `query_graph`, and `explain_finding`. They don't get `remediate`.

Getting Started

1. Install Stratusec

```bash pip install stratusec stratusec init --provider aws ```

2. Run Your First Scan

```bash stratusec scan ```

3. Add MCP Server

Claude Desktop (`~/.claude/mcp.json`): ```json { "mcpServers": { "stratusec": { "command": "stratusec", "args": ["mcp", "serve"] } } } ```

4. Start Asking

"What's the security status of my AWS account?" "Show me all public-facing resources." "Are there any attack paths from the internet to my databases?" "Fix the critical findings. Dry-run first."

The Future

MCP is still early. Adoption is growing fast — as of 2026, there are thousands of MCP servers for everything from databases to email to development tools. But for cloud security specifically, Stratusec is the only open source tool with native support.

That will change. In 12-18 months, expect MCP support to become standard in security tooling, the same way REST APIs became standard a decade ago. The tools that build for it early will have the best integrations, the most refined tool descriptions, and the most battle-tested workflows.

We built Stratusec MCP-native because we believe the primary interface for security tools in 2027 won't be a dashboard. It'll be a conversation.