Believe it or not, you can have all of the above. It's why I'm building MechaRuby: a set of tools from a Staff Engineer with 15 years of Rails experience, and more than 20 years of experience in tech and infrastructure and responding to critical system incidents.
Join me in building verifiably locked down, AI-scale friendly tools for Rails.
If you let an AI coding agent write features in your Rails app, how do you actually know it didn't just punch a hole in your security model?
Can you answer these three questions with total certainty right now?
-
01 / ROUTE AUTHORIZATION
Who can access
GET /admin/*? Can you answer that in five seconds without grepping across forty controllers and untangling a ton ofbefore_actioncallbacks? How sure are you that you didn't miss anything? Sure, you can write unit and system tests, but how do you know those are comprehensive? -
02 / TENANT DATA ISOLATION
When an agent writes
Invoice.find(params[:id]), do you trust yourself to catch that missing tenant scope in a 600-line PR diff? Tools like Snyk are awesome, and should be in your toolkit, but we can't just rely on one AI agent to verify the work of another AI agent. AI is clearly part of the workflow, but can't be AI agents all the way down. -
03 / SCHEMA & ENDPOINT DRIFT
When database columns or controller actions are added or changed, what confidence do you have that you won't miss encrypting that data at rest, or locking down that controller action before hitting production? A mental checklist? A wiki page? A human code review from a team who is probably fielding more PRs per week than ever?
I'm a builder at heart, and I absolutely love the speed of AI agents. An agent can build a complete application feature in a day that used to take me weeks or months. But with this speed comes risk. As a senior engineer it's your job to help identify and mitigate that risk, and I'll bet you're feeling the weight of that burden more than ever while balancing more than ever.
I'm building MechaRuby to replace my own mental checklists and manual process. Join me.
So what do we do about all this?
I think the fix is to use AI to create deterministic analysis tools that are:
- fast
- don't themselves rely on AI to be correct
AI agents are amazing, and can be trusted to do a lot more than I ever thought possible. But you know what I trust even more? A robust, automated, deterministic scanner that doesn't rely on my AI agent having a good day.
I want these verification tools to run in seconds or milliseconds so I can run them on every single CI build and have confidence that I'm getting all the information I need. And if I add new data to my database or new controller endpoints to access that data, I want these tools to automatically notice, audit, and flag any issues so I don't have to remember to catch all on my own. And since almost all apps are multi-tenant apps, I need to know that data is locked down to only the people who should see it.
We're experienced engineers, so we don't mind if getting the right system into place takes a little work, but I want to install a few gems into my Rails app and know that I'm going to get notified of security-critical changes. And the audit outputs of these tools shouldn't require an AI to ingest—they should still be compact and readable by the humans who ultimately bear the liability associated with security choices.
Right now MechaRuby is three gems:
Who / what application roles have access to which endpoints?
Authorization belongs in a single file, not scattered across forty controllers. With mecha_authorize, you map every route and HTTP verb to explicit boolean roles in config/mecha_authorize.yml. Unmapped routes return 404. Period.
How do you stop agents from leaking a customer's data to another customer?
Make cross-tenant data leaks a syntax error that can be caught automatically in CI, not a production incident. mecha_tenant parses your controller AST with Ruby's Prism parser. If an agent writes a bare Model.find(), CI fails instantly with the exact line number and the required tenant_scope(Model) call.
Did that new migration just leave customer secrets in plaintext? What about the data that's been in my schema for the last 2 years?
Account for every column in your database. Encrypt secrets; justify the rest. mecha_encrypt verifies 100% of your schema against config/mecha_encrypt.yml. Unclassified columns fail the build. Plaintext columns require a written justification.
NOTE: These gems are brand new and experimental. I'm actively using them in addition to the classic Rails solutions to ensure things are secure, but I know these gems can be improved. YOU are invited to help; in fact, bring your AI agent with you!
I've extracted them from my own production Rails apps to put hard guardrails on my coding agents, but they need testing across more systems, and more eyes to make sure they're comprehensive enough to be trusted by other people.
I want your help battle-testing them:
-
Point your AI agents at the repos and submit AI PRs:
mecha_authorize,mecha_tenant, andmecha_encrypt. I'll take the best ideas and fold them into the system. - Try them out on a side project or an internal service.
- Break my code, find issues, and tell me where the abstractions could be improved.
Let's make building with AI fast and safe!