The DevOps agent your security team will actually approve

An AI on-call engineer you can actually put in production. Drive it from Slack or a Vercel dashboard — it diagnoses real AWS read-only, and anything that changes code waits for your approval.

Comment

Inspiration

I was an SRE, and on-call is the part of the job that quietly eats your life — the 2 a.m. calls, the hours lost to routine ops. So I tried to automate it: I built a proof-of-concept for AI-driven ops automation with Strands Agents. It actually worked. It just never shipped — a security review wouldn't approve an agent holding that much infrastructure access.

That rejection is what this project is really about. The hard part isn't making an agent capable; it's making one a security team will sign off on. SlackOps is my answer: read-only investigation runs on its own, and anything that touches code waits for a human.

What it does

SlackOps turns Claude Code Headless into a least-privilege DevOps agent on EC2, driven from two places:

  • Slack (Socket Mode) for on-call commands and notifications
  • A Next.js dashboard on Vercel for the job queue, results, audit trail, and approvals

You can pull CloudWatch logs, diagnose a service, or review a Terraform plan — none of which need write access. A PR job prepares and tests a change, then posts the diff; only an approved diff is pushed and opened as a PR, and the agent never merges it.

For the autonomous path, a CloudWatch alarm fires EventBridge → Lambda. Deterministic rules turn the untrusted alarm text into a known command and write a PENDING job to DynamoDB — even while EC2 is stopped. The worker runs the read-only diagnosis on its own and pings Slack; anything that would change code stops at the approval gate.

How I built it

DynamoDB is the spine. It coordinates jobs, status transitions, audit events, metrics, conversations, and detection settings — and a conditional write gives me atomic job claiming and a duplicate-approval lock without standing up a separate coordinator. The EC2 worker runs on an IAM Instance Profile (no stored keys); Claude reaches AWS only through a read-only AWS API MCP; inputs go into fixed templates; command and tool allowlists are default-deny; PR diffs pass an output gate. Every queued run records its audit, latency, tokens, and cost back into the table.

Challenges I ran into

My first version was much bigger — I wanted an internal knowledge ontology so the agent could reason and act on its own across more of the stack. I cut it. For a deployable, cost-honest scope, I kept only the core loop that actually solves the on-call problem, and let the boundaries — not a smarter prompt — do the heavy lifting.

The other hard part was prompt injection at the edges. Operator text is isolated inside templates; AWS MCP results are fenced by the Instance Profile, the read-only policy, and the tool allowlist; alarm text never becomes a command directly.

Accomplishments I'm proud of

I verified the whole AWS path end to end — CloudWatch ALARM → EventBridge → Lambda → DynamoDB → Claude worker → DONE → Slack — at about $0.15 for the measured run. It's deliberately light and cheap: it ships an MCP agent that any Claude developer can customize, instead of a heavy platform. The public Vercel dashboard reads the live table, and the quality gate stays green (319 tests, Ruff, strict mypy) without touching real AWS or Claude.

What I learned

Safe agentic ops come from system boundaries far more than from a clever prompt. Least privilege, deterministic routing, conditional transitions, audits, and approval gates are what make autonomy actually useful — without pretending every action is safe to automate.

What excites me

Taking an agent from local → POC → enterprise is usually where ideas die. Proving that a single person's idea can solve a real ops problem with a small, honest workflow loop is the fun part. Push it further and Claude becomes the brain that runs the cloud and the services, while people just give it direction remotely — so you could be in a meeting, a product demo, or an external event and still be operating and building at the same time.

Note

The Vercel dashboard is deployed and public. To keep costs near zero, the Claude worker on EC2 is started only when needed — email me and I'll bring it online for a live test.

Built With

Share this project:

Updates