The question every client asks when they find out AI is writing code alongside the team is always the same. Won't it mess with what it shouldn't? Won't it read my database secret? Won't it take down my production? Short answer: here it can't. Not because we trust it a lot. It's because someone wrote four rules before it started typing, and those rules are versioned in Git like any other piece of code.
This text explains the four doors AI finds locked when it works alongside our developers, in business language. Whoever is selling you "AI with governance" should be able to show you the doors. If they can't, you're paying for a good demo, not for governance.
Why this text exists
Anyone who has never worked with a developer thinks AI writes code on its own, without supervision. That's not how it is. There's a human reading every change before it gets anywhere near production. But humans get tired, humans get careless, humans click "accept" at 6pm on a Friday. That's why, on top of the human, we built an extra layer: automatic blocks that run every time AI tries to do something. That's the layer we're going to describe.
The logic is simple: layered defense. Human reviews. AI produces. Automatic block prevents what should never have even been attempted. Three checkpoints, not one.
Door 1: AI does not touch production. Period.
Production is the environment your end clients use. Dev is the internal copy where the team tests first. The rule here is strict: AI operates only in dev. Any AI command that tries to touch production is blocked before it runs.
What gets blocked, in practice:
- Pushing code straight to the project's main branch without review.
- Applying an infrastructure change in the cloud (creating a server, tearing down a server, touching a firewall).
- Publishing a software package to the public registry without review.
- Deleting data, dropping a table, deleting a cloud instance.
Whoever applies to production is a human with DevOps responsibility. AI writes, the human approves and applies. Two pairs of eyes, always. The client pays for that caution: predictability.
Door 2: AI does not create or read a secret file
Systems store credentials (database password, payment key, integration token) in files called .env and similar. Those files don't go into Git, they stay outside version control. AI cannot read or create those files.
The rule is granular. Example templates, which show the file's format without carrying a real secret, are allowed. Files with a real secret, certificates, server private keys, service accounts for Firebase, for Google Cloud, all blocked before AI even starts writing.
Why this matters for your project: if your database credential were in a file of this category, AI wouldn't even have visibility into it. What it can't read, it can't leak.
Door 3: AI is audited every time it saves a file
Suppose AI, in a careless moment, writes an API key inside some file. It can happen (it's statistics, not infallible). For that case, every file AI saves goes through an automatic scan right after.
What the scan looks for, in business language:
- Cloud server credential (AWS, Google, Anthropic, OpenAI).
- Payment integration token (Mercado Pago, Stripe).
- Access to code and communication networks (GitHub, Slack).
- A database link with a password embedded in it.
- Passwords, tokens and any text that looks like a secret.
If a pattern is detected, AI gets an immediate alert and is instructed to remove it. It happens in the same second. It's not a nightly scan. It's not a process scheduled to run tomorrow.
Door 4: Nothing with a secret enters the Git history
Git is the permanent history of the code. What goes in there is recorded forever. That's why the fourth door: before every commit of a change to Git, a final scan is mandatory. If a secret slipped through the earlier steps, it gets intercepted here. The commit does not happen.
This is the last line of defense. After it, the secret would enter the history, and getting a secret out of the Git history is laborious and never fully clean. That's why the interception is strict: it blocks, returns an error message, forces the fix.
The proof that the door really locks
It happened while the team was writing this very text. The person was opening the review request in Git (a kind of change record) documenting the four doors. To explain what each door does, the request description mentioned words like "production", "private key" and the names of dangerous commands.
Result: the door itself blocked the team three times. It refused the first message because it said "production" near "infrastructure command". It refused the second because it mentioned "insecure permission". It refused the third because the descriptive text contained the typical pattern of a cryptographic key.
It may sound funny. It isn't. It's proof that the door doesn't check who is passing through, has no vip list, doesn't loosen up when it's the team itself. If not even we get through when we slip up, a client's secret doesn't get through either.
Versioned policy, not a verbal promise
All of this, the four doors, lives in a Git file. Anyone on the team opens it, reads it, audits it, proposes a change. It's not a promise we make in a meeting. It's a file with a history of who changed it, when, and why.
For the client, this means three practical things:
- Real auditability. You can ask to see the file. We show it.
- The same policy for everyone. There's no client A and client B. The rule is one, for every project that goes through Steply.
- Tracked evolution. When we tighten a rule (adding a new credential pattern to detect, for example), it's recorded.
LGPD, data processing agreement, vendor audit: all of that gets simpler when the rule is in a file, not in someone's head.
What changes for your project
If you're evaluating working with AI in building your product, and you're the decision-maker who has to answer to the board about risk, the right question isn't "do you use AI?". The question is: how does the vendor stop AI from doing what it shouldn't? If the answer involves a phrase like "we trust the team", keep looking.
Our answer is different. We treat AI as a vendor with versioned guard-rails, the way we'd treat an intern with restricted access. Want to understand how to apply this logic to your project, a quick conversation solves it: talk to us, we'll show you the doors working live.