Hi guys,
I recently asked an AI agent to delete an unused folder.
It used a broad pattern match and removed more than I intended.
Technically it did what I asked — but not what I meant.
I clicked "yes" too quickly. Luckily I had a backup.
That was just files. Now imagine the same semantic mismatch applied to
kubectl delete or terraform apply.
This got me thinking about pre-execution guardrails for AI agents working with infrastructure. So I built Evidra — an MCP server that evaluates operations against deterministic OPA policy before execution. If an operation looks dangerous (protected namespaces, mass deletions, public S3, wildcard IAM, etc.), it blocks it. There’s no LLM in the evaluation loop.
GitHub: https://github.com/vitas/evidra
I intentionally kept the policy scope narrow. This isn’t a full compliance engine — it focuses only on high-impact disaster scenarios. The goal is to keep it lightweight while preventing catastrophic mistakes, so teams can experiment with AI in ops more safely.
It’s not meant to replace admission controllers. It’s a pre-execution guardrail when automation is in the loop.
Although it’s motivated by AI workflows, it’s not limited to them. The same guardrails can run in CI against Terraform plans or rendered manifests — blocking catastrophic changes before execution, whether triggered by a human or an agent.
Every decision — allow or deny — is logged in a SHA-256 hash-chained evidence log.
Security model: https://github.com/vitas/evidra/blob/main/docs/SECURITY_MODEL.md
Landing: https://evidra.samebits.com
I’d love feedback — especially from teams experimenting with AI-assisted infra workflows.