An AI coding assistant that's genuinely useful for ninety percent of a codebase can still cause a genuinely expensive incident in the other ten percent. Authentication logic, billing code, and database migrations are exactly the paths where a plausible-looking but subtly wrong suggestion does real damage, and they're also exactly the paths where an assistant's pattern-matching instincts are most likely to lead it astray.
The answer isn't banning AI assistance from the codebase entirely, which throws away most of the value for a small slice of risk. The better answer is drawing explicit boundaries so the assistant can keep working everywhere else while a human reviews, or the tooling blocks outright, anything touching the paths where a mistake is expensive.
Why these three categories specifically
Authentication code fails in ways that are hard to notice immediately. A subtly broken session check or a permissions comparison that's technically valid but logically inverted can pass tests, pass a casual review, and sit in production for weeks before anyone notices unauthorized access happened. The failure mode isn't a crash, it's a silent security hole.
Billing code fails in ways that cost real money immediately or create compliance headaches. A rounding error in a proration calculation, a race condition in a refund flow, or a currency conversion that's off by a decimal place translates directly into dollars, either overcharging customers or leaking revenue, often before anyone's watching closely enough to catch it.
Database migrations fail in ways that are hard to undo. A migration that drops a column, changes a type incompatibly, or runs a lock-heavy operation against a large production table can cause data loss or extended downtime, and unlike most code changes, a bad migration that's already run against production data isn't always cleanly reversible.
Start by mapping the actual danger zones in your codebase
Before setting up any tooling, walk the codebase and identify the specific directories, files, or modules that fall into these categories for your specific application. This is more granular than "the backend" or "anything touching the database." You're looking for the actual auth middleware, the specific billing service classes, and the migrations directory, not a broad swath that would block useful AI assistance on adjacent, lower-risk code in the same general area.
Document this list somewhere the whole team can see it, not just in one engineer's head. The goal is a shared, explicit understanding of where the guardrails apply, which also doubles as useful onboarding material for new team members regardless of whether they're using an AI assistant.
Use CODEOWNERS or an equivalent to force human review
Photo by Vitaly Gariev on Pexels
Most modern version control platforms support a CODEOWNERS file or equivalent mechanism that requires a specific person or team's approval before a pull request touching certain paths can merge. Configuring this for your identified danger zones means any change, AI-assisted or not, gets a mandatory human review from someone who understands the risk, rather than relying on reviewers to notice a sensitive file changed among a larger diff.
This is a cheap, well-understood control that most teams already have access to and simply haven't pointed at their highest-risk paths specifically. It doesn't require new tooling, just a deliberate configuration decision.
Configure your AI assistant's own scoping where the tool supports it
Several AI coding assistants support project-level configuration files that can restrict which paths the assistant is allowed to modify directly, or that flag certain paths as requiring extra caution before suggesting changes. Where your specific tool supports this, configure it explicitly rather than relying on the assistant's general judgment about what's sensitive, since that judgment is trained on general patterns, not your specific application's risk profile.
Even when a tool doesn't support hard restrictions, many accept a project instructions file where you can explicitly state which paths require extra scrutiny, additional context, or should be avoided for autonomous changes entirely. This won't stop a determined attempt to modify those files, but it meaningfully changes the assistant's default behavior for the common case of a routine feature request that happens to touch adjacent code.
Add automated checks that specifically target the danger zones
Beyond human review, automated checks focused specifically on your danger zones catch a different class of problem than general-purpose linting or test coverage. For migrations, a check that flags any migration lacking a corresponding rollback script, or that detects a lock-heavy operation against a table above a certain size threshold, catches exactly the kind of mistake an AI assistant is prone to making when it generates a migration without full context on your production data volume.
For billing code, property-based tests that check invariants like "the sum of line items always equals the total" catch a wider range of subtly wrong logic than example-based unit tests alone, regardless of whether the code was written by a person or an assistant. For auth code, a dedicated test suite that specifically tries to break the permission model, attempting access with insufficient privileges and confirming it's denied, is worth maintaining as its own concern separate from general feature tests.
Treat AI-suggested changes in these paths with a different review posture
Even with technical guardrails in place, it's worth explicitly telling reviewers that a pull request touching auth, billing, or migrations should get a slower, more skeptical read than a typical feature PR, and that this applies with extra weight when the change came from an AI assistant. This isn't about distrusting the tool categorically, it's about matching review depth to the actual cost of a mistake in that specific area, the same way a security-sensitive change from a human engineer should also get a more careful look than a copy tweak.
"The teams that get burned by AI-generated code almost never get burned by the obvious stuff. They get burned by a plausible-looking change to a code path nobody was watching closely enough, because the diff looked routine." - Dennis Traina, founder of 137Foundry
Give the assistant real context instead of just restricting it
Guardrails that only block are a partial solution. An AI assistant given genuine context about why a path is sensitive, through clear code comments, a linked architecture document, or an explicit note in its project instructions, often produces meaningfully better suggestions than one that's simply told "don't touch this." Context reduces the number of naive suggestions in the first place, which is a better outcome than catching them after the fact in review.
This is particularly effective for migrations and billing logic, where the risk often comes from the assistant not knowing about a business rule or a data volume constraint that isn't visible from the code alone. A short comment explaining "this table has 40 million rows, avoid full-table locks" does more to prevent a bad suggestion than any downstream check will catch after the fact.
Revisit the boundary list as the codebase changes
The set of genuinely high-risk paths in a codebase isn't static. New features add new billing logic, refactors move authentication code to new locations, and what was once a low-traffic internal tool can become customer-facing and suddenly higher-stakes. Revisiting the danger-zone list on a regular cadence, not just when setting it up initially, keeps the guardrails pointed at where the actual risk currently lives rather than where it used to live.
Don't forget secrets and credentials as their own category
Beyond auth logic, billing code, and migrations, it's worth treating hardcoded secrets and credential handling as a fourth danger zone, since AI assistants trained on public code sometimes reproduce patterns like committing a placeholder API key or writing a config example that looks like it should be gitignored but isn't. A pre-commit hook that scans for common secret patterns, paired with the same CODEOWNERS-style review requirement on configuration files, closes a gap that's easy to overlook when the focus is entirely on application logic.
The CISA Secure by Design guidance covers this broader category of software supply chain risk in more depth, including how credential handling fits into a wider secure development posture beyond just the AI-assistance angle covered here.
Getting this set up without slowing the team to a crawl
The goal of all of this is narrow, targeted friction, not broad distrust of AI-assisted development. Most of a codebase should stay fast to iterate on with an assistant's help. A small, well-documented set of genuinely high-stakes paths getting mandatory human review and targeted automated checks is a proportionate response, not an overcorrection that erases the productivity gains the tooling was adopted for in the first place.
137Foundry's AI automation team works with engineering teams to set up exactly this kind of scoped guardrail system, mapping the actual risk surface in a specific codebase rather than applying a generic template that's either too loose to matter or too restrictive to be worth adopting.
Further reading on the underlying risks
The OWASP Top 10 remains a solid baseline for understanding the categories of vulnerability that show up most often in web applications, auth-related issues prominent among them, and is worth cross-referencing against whatever an AI assistant proposes in that part of the codebase. For migration-specific risk, PostgreSQL's own documentation on lock behavior is a useful reference regardless of which database you're running, since the underlying locking concepts translate across most relational systems.
The National Institute of Standards and Technology's guidance on secure software development covers a broader framework for thinking about where automated and AI-assisted tooling fits into a secure development lifecycle, useful context beyond the narrower guardrail setup covered here.
If you want to talk through what a scoped guardrail setup would look like for your specific codebase, 137Foundry's services page has more on how the team approaches this kind of engineering work, or you can read more on 137Foundry's about page and browse the homepage for related case studies.
