DEV Community: Ansh Sonkar

Turned CNAPP engine into an MCP server

Ansh Sonkar — Tue, 16 Jun 2026 07:53:18 +0000

While building Emfirge my own CNAPP to learn about infrastructure building, I kept running into the same problem most of the time.

Cloud security tools are great at finding issues, but they're usually trapped inside dashboards. So lets say if I wanted to investigate an attack path, check compliance issues, understand blast radius, or simulate a fix, I had to jump between multiple screens and workflows.

At some point I started wondering

Why does this need to live in a dashboard at all?
So I converted the core of Emfirge into an MCP server.

Now it can run directly inside Claude, Cursor, Kiro, Cline, and other MCP-compatible clients.
Source Code GitHub: https://github.com/theanshsonkar/emfirge

The Idea

You provide a read-only AWS IAM role.
Emfirge builds a live graph of your infrastructure and maps the relationships between resources.
Instead of looking at individual findings, it analyzes how everything connects together.

From there it can do

Trace attack paths from the internet to sensitive resources
Calculate blast radius
Detect toxic combinations and privilege escalation risks
Run compliance checks
Simulate security fixes before they're applied
Pre-Simulating Infrastructure Changes

One feature I particularly wanted was the ability to test changes before touching production.

Rather than relying on an AI model to guess what might happen, Emfirge clones the infrastructure graph, applies the proposed change, and reruns the analysis.

This makes it possible to ask questions like

What happens if I make this bucket public?

What happens if I modify this security group?

Does this change increase or reduce risk?

The answer comes from the graph analysis rather than model speculation.

Privacy Was Non-Negotiable

One concern I had from day one was sending cloud infrastructure data to LLMs.

AWS account IDs, ARNs, resource identifiers, IP addresses, and other sensitive values shouldn't leave an environment unnecessarily.

To address this, resource identifiers are tokenized locally before any LLM interaction occurs. The model sees anonymized tokens instead of the original identifiers.

What Started as a Graph

Interestingly, most of the capabilities in Emfirge ended up being graph problems.

Attack path analysis.
Blast radius calculations.
Fix simulations.
Compliance relationships.
Toxic combinations.

Everything eventually became graph traversal, path finding, and risk modeling. Once I realized that, exposing the system through MCP felt like the natural next step.

Instead of navigating a dashboard, you can now interact with the infrastructure graph directly from your AI tooling.

Source Code GitHub: https://github.com/theanshsonkar/emfirge

I'd love feedback from people working in cloud security, platform engineering, or infrastructure. I'm especially interested in how others think MCP could be used for security workflows.

AI coding agents don't need more context, they need a graph

Ansh Sonkar — Sat, 06 Jun 2026 11:37:19 +0000

Github - Get the full Info about Carto

The problem

AI coding tools are confident. They'll propose a 12-line patch to a file with 83 transitive dependents like it's nothing. You accept it. Things break downstream. The agent can't see this coming because nothing in its context models your import graph. It reads the file it's editing, maybe a few greps, maybe a vector search hit, then writes confidently into code it doesn't understand. Most of the time the patch lands somewhere reasonable and tests pass. The bad case is silent: a confident refactor on a file that 60+ other files import, the cascade doesn't run locally, and three days later something downstream breaks.

So I built Carto

It indexes your codebase into a local SQLite database (import graph, domain map, blast radius for every file) and exposes a validate_diff tool your AI calls before showing you anything. It gets back the risk level, every file the change touches transitively, and whether it crosses domain boundaries it shouldn't. The AI sees all of this before it proposes the patch. It revises, splits the change, or flags it. The bad diff never makes it to your screen.

Real case

Last week Claude Code proposed a 12-line refactor of a postgres formatter. Looked clean. Lint passed. I was about to accept. validate_diff returned HIGH with 83 transitive dependents and a high_blast violation on the modified file. The agent threw out its own patch and asked if I wanted to split the change instead. That one tool call is the entire reason the rest of the system exists.

Beyond validation

Ask Carto what files to touch for any task, which files break if you change one, what patterns already exist before you write new code, or get a full architectural overview of the codebase (domains, entry points, key patterns). And because every decision is logged to a local SQLite log, the AI remembers what was already decided yesterday, last week, or three sessions ago. did_we_discuss_this("snake_case naming") returns the prior decision. The AI stops re-litigating settled questions inside the same repo.
This was the smallest piece to build and honestly the most useful one. The agent's worst trait is that it forgets, and SQLite turns out to be a fine memory.

Under the hood

tree-sitter parses every file for imports and symbols (0.05-0.2ms per file), Babel goes deeper on API handler files only to extract routes and models. Domains are detected by running Leiden+CPM graph clustering over the import graph (files that heavily import each other naturally cluster together, names inferred from path tokens). Blast radius queries run on a Uint32Array bitset layer built from SQLite. Median 20.7× faster than raw SQL on a 7,567-file repo. The bitset class itself is 60 lines, zero deps. Word-level OR, AND, popcount, iterate. Three pre-allocated bitsets total in the BFS hot loop, no allocation churn per hop.

simulate_change_impact

Only exists because of bitmap OR aggregation. Computing the union blast radius across multiple files simultaneously has no SQLite equivalent at this latency. It's the same insight that makes validate_diff cheap: a union of 20 files' blast radii reduces to one OR pass over data already in memory. validate_diff runs in 0.040ms at the median on a 7,567-file repo. Budget going in was p50 under 5ms, p99 under 15ms. Cleared by 30 to 60 times. The reason the budget mattered: this has to run inside the agent loop on every proposed diff. At 50ms the agent skips the call. At 0.04ms there's no reason not to make it.

No daemon. Just 4 git hooks (pre-commit, post-checkout, post-merge, post-rewrite) keep the index fresh. Stale files re-parse inline at MCP query time. 22 MCP tools total. carto init auto-wires into Cursor, Claude Code, Kiro, Windsurf, VS Code Copilot, Codex, Claude Desktop, Zed, JetBrains. One install, restart your AI tool, the AI calls Carto on its own from then on.

Why this shape was already in my head: I was building Emfirge, a cloud security agent that maps AWS infrastructure into a graph and simulates blast radius for every change. To make Emfirge's AI understand AWS, I wrote a module called cartography.py. It mapped resources, built a graph, wrote it into a structured map. The AI stopped hallucinating about IAM and VPC peering. One night I was watching Claude Code propose a refactor inside a file with 60+ dependents and realized I'd already solved this once. For AWS. Same exact shape. Source code and cloud infra are both directed graphs of components with declared dependencies. Carto is cartography.py retargeted at source.

npm install -g carto-md
cd your-project
carto init

MIT. Local only. No telemetry, no cloud, no account.

github.com/theanshsonkar/carto

Experimented to fork AWS infra graph and simulate what breaks before you deploy

Ansh Sonkar — Wed, 27 May 2026 04:52:56 +0000

Cloud security still feels heavily deploy → detect → respond, so I wanted to try flipping the workflow.

You connect an AWS account, Emfirge pulls infrastructure state across 18+ AWS services and builds a topology graph: SG → EC2 → IAM Role → S3 → RDS etc.

Then i keep two copies, One is real state and the other is Clone for mutations like staging environment for your security posture.

When you open a tf Pr I parse the diff, apply it to the clone and rebuild the graph, run BfS from internet. New path from internet to your database? Kinda this shows up in the PR comment before merge.
Same for simulation add any component of cloud and mutate on the actual Infrastructure.

Example:
If a change introduces a new internet → database path, it shows up during PR validation before merge.

Then I introduced 3 phases all powered by the same graph:

NOW
Current attack paths, blast radius, infra exposure, breach simulation

WHAT IF
Add/mutate cloud components and simulate security consequences before deployment

TIMELINE
Infrastructure drift, posture changes, and historical attack-path evolution over time

Still very early and exploring the direction. Curious what cloud/devops/security engineers think about infrastructure consequence simulation becoming part of CI/CD workflows.

https://www.emfirge.cloud