I want to validate something before starting my project. I've experienced or heard of several incidents caused by simple mistakes in the command line interface (CLI), such as running `kubectl delete` in the wrong context, executing `terraform apply/destroy` in production, or running `docker compose down -v` which wiped out data. There are safeguards like IAM, RBAC, GitOps, and CI policies in place, but many teams still have direct CLI access. I'm thinking about creating a local guardrail tool that could run between an engineer or an AI and the CLI, blocking or requesting confirmation for risky commands, with an option to operate in shadow mode to log or warn without making changes. I'm looking for honest feedback: Have you seen real damage from CLI mistakes? Do engineers still run direct commands in production? Could this be a bad idea? Thanks!
2 Answers
It sounds like you're trying to find a workaround for a problem that already has a clear solution. While direct CLI access exists, the real fix might be to remove that access altogether. If teams keep making mistakes because they’re doing manual tasks, it might be easier to automate those processes, which would serve as better guardrails.
Honestly, if you're executing CLI commands directly in production, that points to deeper issues in your process. There should be no need for that; serious mistakes can happen if teams have that level of access. It's a recipe for disaster!
But we’re too small to justify using pipelines! It’s just me, so why create different roles? I don’t have time for that!