Watching Before Blocking: How Atlas Is Rolling Out Real Permissions Without Breaking Anyone

Shadow mode isn't about being careful—it's about not accidentally locking your VP of Sales out of her own pipeline on a Tuesday

Atlas has been building a real permission system. Not the kind that shows up in a feature list and does nothing. The kind with a permission catalog covering CRM opportunities, meetings, activities, notes, projects, lead forms, exports, settings, integrations, billing views, and marketing surfaces. The kind with a single shared primitive—checkPermission—that every permission decision runs through, whether a human is clicking in the UI or NyLi is calling an MCP tool on their behalf.

That system is running right now. It checks permissions every time someone takes an action. It logs what it sees. And then it lets the action through anyway.

This is shadow mode. The permission check runs. The decision is recorded. Nothing is blocked. If the check itself fails for some reason—maybe a permission rule is malformed, maybe the catalog lookup breaks—it fails open. The action proceeds. The user never knows the system just evaluated whether to stop them.

The reason is simple: flipping enforcement on cold, before anyone has looked at what it would actually block, is how you accidentally lock a real user out of their own account on a Tuesday afternoon. Shadow mode lets the team watch the real traffic against the real rules first.

Freedom creates speed, but governance creates scale—and you can't govern what you can't see

Permissions are not exciting until they go wrong. Then they become the only thing anyone cares about. A user locked out of a deal they own. An agent that can read notes it shouldn't. A contractor who can see billing data. A junior rep who can delete opportunities.

The promise of AI agents makes this worse, not better. If NyLi can act on your behalf, it inherits your permissions. If those permissions are too broad, NyLi can do things you wouldn't want it to do. If they're too narrow, it gets blocked trying to complete work you asked it to do. Either way, the permission model has to be right.

Right now, Atlas is watching. Every export, every settings change, every integration toggle, every CRM action—opportunities, meetings, activities, notes, projects, lead forms, search—runs through the same permission check. The logs show what would have been blocked. The team can see patterns: which roles hit which walls, which rules are too strict, which are too loose, where the gaps are.

Enforcement is a separate, deliberate step. It requires backfilling the right grants for existing roles first. It requires confirming that the rules match how the organization actually works. Shadow mode buys the time to get that right.

Failing open isn't weakness—it's the move that keeps the system running while you learn what the rules should actually do

When the permission check itself fails—not when the user lacks permission, but when the check can't complete—Atlas fails open. The action proceeds. This is not an accident. It's the design choice that prioritizes visibility over disruption during observation.

Failing closed would be safer in theory. Block anything you can't verify. But in practice, failing closed during shadow mode means you're enforcing before you understand what you're enforcing. You're blocking actions that might be legitimate because the rule isn't finished yet. You're turning observation into production before you've seen the data.

Failing open preserves the current behavior—everything still works—while the permission system watches and learns. Once enforcement is live, the calculus changes. Then you fail closed. If the system can't verify permission, it blocks. But that switch only makes sense after you've watched the traffic and built confidence that the rules are right.

The discipline of the rollout is the more interesting claim than having RBAC in the first place

Every enterprise system eventually ships role-based permissions. The feature itself is table stakes. What separates a permission system that works from one that creates support tickets is how it gets deployed.

Shadow mode is not about being timid. It's about having the operational discipline to watch the system work before you give it the power to stop people from working. It's the recognition that permissions are a blunt instrument—block too much and you slow the business down, block too little and you create risk—and the only way to tune that instrument is to see it run against real behavior first.

Atlas is rolling out permissions the way you'd roll out anything with the power to lock people out: carefully, visibly, and with a fallback. The system is live. The checks are running. The logs are filling. Enforcement is a deliberate next step, not an accident. That's the story. That's the discipline. And that discipline is what makes governance actual governance instead of just another gate someone has to work around.