CloudGuard AI

CloudGuard AI simplifies AWS management with voice-driven cost insights, resource governance, and secure, human-approved automation.

Comment 3

Inspiration

Small teams run real AWS accounts without a FinOps or cloud-governance engineer. "Why did the bill go up?", "Who owns this Lambda?" and "Tag everything for Project X" each mean digging through the console across services and regions. A bulk-tagging script can quietly overwrite values or hit the wrong account. We wanted to ask our AWS account the way we'd ask Alexa, and be able to trust the answer.

CloudGuard AI: Agentic investigation. Evidence-backed answers. Human-approved actions.

What it does

CloudGuard AI is a voice-first AWS governance and cost assistant, exposed as a self-hosted MCP server (spec 2025-11-25, Streamable HTTP) that Alexa+ or any MCP client can call.

  • 💰 Cost intelligence: a monthly bill split into usage, credits, tax and refunds; month-to-date spend; breakdown by service; month-over-month comparison; "why did my cost go up?"; AWS Cost Anomaly Detection.
  • 🏷️ Resource governance: multi-region inventory and search across Lambda, DynamoDB, S3 and EC2; untagged resources; policy compliance scans; evidence-only tag recommendations.
  • 🗣️ Conversational bulk tagging: "Tag all Lambda functions containing CodeBridge in Mumbai with owner = alex." CloudGuard:
    1. reads its interpretation back;
    2. asks for a missing region or tag value;
    3. reports how many resources match, and warns if discovery was incomplete;
    4. previews exactly what will change: to change, already correct, overwrites, and case-conflicting keys like Owner vs owner;
    5. executes only after a spoken "yes" (plus "I confirm the overwrite" when values are replaced);
    6. reads every resource back to verify it.
  • 🔎 Every answer carries raw AWS evidence, plus a short spoken summary.

How we built it

  • MCP server: Python with the official mcp SDK (FastMCP), protocol 2025-11-25 over stateless Streamable HTTP.
    • 14 high-level tools, all annotated read-only.
    • An Alexa-scoped token (alexa:read) sees only those tools, through voice-friendly response projections.
    • The server refuses to start if that surface is inconsistent.
  • Deterministic core: boto3 discovery, compliance and Cost Explorer engines decide every fact. Nothing is invented.
  • Simulated Alexa+ client: React + TypeScript + Vite, the official MCP TypeScript SDK, and the browser Web Speech API for voice in and out.
    • Eight-page dashboard: Overview, Cost Intelligence, Resource Governance, Voice Assistant, Tag Management, Activity & Audit, Settings, MCP Explorer.
    • Region clarification: "List my Lambda functions" → "Which AWS region?" → "Mumbai" → ap-south-1.
  • Safety by design: writes never go through MCP. Tagging runs on a separate path:
    • operator sign-in and an STS account check;
    • a 2-minute challenge bound to a plan hash, then a fresh re-resolve from AWS;
    • sts:AssumeRole into a least-privilege tagging role;
    • fenced writes, read-after-write verification, a kill switch and a JSONL audit log.
    • Team accounts use a two-person approval flow, where a different person approves the content hash.
  • Testing: 2,169 backend tests (pytest, botocore Stubber, moto), 733 web unit tests (Vitest) and 46 Playwright end-to-end tests.

Challenges we ran into

We kept a 23-entry, evidence-backed friction log (docs/FRICTION_LOG.md). Highlights:

  • S3 PutBucketTagging replaces the whole tag set and can't be IAM-restricted by tag key.
  • No AWS tagging API supports conditional writes, so we built fenced write intents and post-write verification.
  • Cost Explorer returns floating-point residues: our first version read a -3.8E-9 net as a "credit". We added a one-cent materiality threshold.
  • A full 18-region scan took about 101 s, far longer than a voice turn. We added scoped scans and a scan cache.
  • Browser speech recognition mishears AWS terms, so we added a read-back before discovery, transcript correction, and blocked interim speech from confirming anything.
  • Without Alexa+ device access, we built a faithful MCP client simulator.

Accomplishments that we're proud of

  • A voice tagging flow where a misheard word can never write to AWS. Interim speech can't confirm, every plan is read back, and the server re-checks the exact phrase.
  • Honesty about evidence: every response says whether it came from fixture data or a live account.
  • Thousands of automated tests, and a friction log we hope helps AWS teams.

What we learned

MCP tool annotations plus a projection layer make a clean security boundary for voice assistants. A "human in the loop" has to be enforced server-side, with hashes and expiry, not just by the UI.

What's next for CloudGuard AI

  • Live verification of the tagging path on a throwaway account
  • Amazon Bedrock (Nova) + Strands agents for explanations and prioritisation, while deterministic checks keep deciding the facts
  • Security checks (public S3, IAM wildcards, open security groups) and cost-waste checks (unattached EBS, idle EIPs)
  • OAuth account linking and a real Alexa+ integration when access opens

Honest status

  • The demo runs on a simulated Alexa+ web client. It is not a certified Alexa+ integration.
  • Read-only discovery and Cost Explorer have run against a real AWS account.
  • The tag-write path is fully implemented, but has been tested only against mocks and a simulated account.

Team: Mukesh Kumar & Rajesh M · Repo: https://github.com/mukeshkumar06/CloudGuard (MIT)

Built With

Share this project:

Updates

Submission history