When engineering leaders decide to standardize on Claude Code, the productivity case is obvious. Developers move faster. Less time on boilerplate, more time on hard problems. The teams that adopt it early don't want to go back.
The question that lands on the security team's desk is a different one: how do we roll this out to 50 developers, or 200, in a way we can actually stand behind? How do we make sure the right guardrails are in place, that they stay in place, and that we can prove it to an auditor if we ever need to?
Anthropic has thought about this. Claude Code ships with a permission system that lets you write allow and deny rules for every tool the agent can use. It's the right mental model, and most security teams we talk to have already put real work into it. They know what they want to block, they've tested their rules, they understand the syntax.
Where they get stuck is operating that system at org scale. The rules are right. The infrastructure to manage them across a real organization isn't there yet. That's the gap Ceros fills.
How Claude Code's permission system works
The native system is built around a settings.json file with two keys: allow and deny. Each rule targets a tool and can include a pattern to filter arguments. Deny rules always take precedence. The syntax is expressive enough to cover most cases:
{
"permissions": {
"allow": [
"Bash(git *)",
"Bash(npm test *)",
"Read",
"Edit"
],
"deny": [
"Bash(aws *)",
"Bash(kubectl *)",
"Bash(curl *)",
"Bash(ssh *)",
"Edit(**/.github/workflows/**)"
]
}
}For a small team on a single project this works well. Commit the file, everyone picks it up, done. Anthropic also supports a managed settings file that administrators can push through MDM, a settings layer developers can't override. The building blocks for org-level control are genuinely there.
The limitations show up when you try to run this across many teams with different risk profiles, different roles, and an auditor who wants evidence rather than configuration files.
What the native system wasn't designed to do
Rules apply the same way to everyone. A settings.json file has no concept of who is running it. The same rules apply to a senior engineer, a contractor, and someone on their first week. There's no way to say "block kubectl globally, but allow it for the infrastructure team" or "contractors can't run shell commands at all." The rules are flat. Identity doesn't exist in the model.
Rules don't know anything about the device they're running on. A managed settings file delivered through MDM assumes the device is managed and healthy. But it has no runtime awareness of device state. If a developer's endpoint protection stops running mid-session, the same rules keep applying. The permission system can't respond to changes in the security posture of the machine it's running on.
When a rule fires, nothing is recorded. Claude Code blocks the action and moves on. There's no log that captures who triggered it, from which machine, what they were trying to do, or when. If a compliance team asks "show us evidence that your AI agent controls are working," there's no artifact to point to. You know the rules are configured. You can't prove they're being enforced.
Updating rules across a large org is a manual coordination problem. Changing a rule means touching files in repos, coordinating MDM deployments, or asking developers to pull changes. There's no central place where a security team can see all active rules, update them in one place, and have those changes propagate immediately. At 10 developers it's manageable. At 100 it's a process problem.
What Ceros adds on top of Claude Code
Ceros uses the same rule syntax as Claude Code's settings.json: Tool(pattern), allow and deny, argument-aware matching. If your team has already written rules, they translate directly into Ceros with no rewriting. The difference is the infrastructure underneath them.
Identity-scoped rules
The policy builder uses the same Tool(pattern) syntax you already know. What's new is the scope column: each rule can be applied globally, to a specific team, or conditioned on device posture.
Consider a rule like Bash(kubectl *) set to DENY globally, with a second rule set to ALLOW scoped to the infrastructure team. That combination, a restrictive global default with explicit carve-outs for teams that have a legitimate reason for the access, isn't expressible in a flat settings.json file. In Ceros, it's two rows in the policy table.
Device-scoped rules are a different kind of control entirely. A rule that blocks Bash(curl * | wget *) on unencrypted devices fires not just based on what the agent is doing, but on the live security state of the machine. A developer on a compliant device isn't affected. A developer on a machine that's failed its posture check gets a tighter ruleset automatically, for as long as that condition persists.
The audit trail compliance teams actually need
Every enforcement event in Ceros produces a signed log entry. Not just a note that something was blocked: a complete record of who attempted the action, from which machine, what the device's security posture was at that exact moment, and which rule matched. The log is cryptographically signed at the source so it can't be altered after the fact.
When a compliance team asks for evidence that AI agent controls are working, this is what you show them. Not a configuration file that you hope is being applied correctly, but a timestamped, signed record of every enforcement event, tied to a verified identity on a verified device.
A few examples of what that looks like in practice:
- A frontend developer attempts
Bash(aws s3 cp ./build s3://company-prod-releases/), matched against the globalBash(aws *)deny rule. Logged: user, team, device posture, timestamp. - A contractor attempts
Edit(.github/workflows/deploy.yml), matched against the global CI/CD deny rule. Same record. - An infrastructure engineer runs
Bash(kubectl get pods -n payments), matched against the infrastructure team allow rule. Also logged, with the same fidelity.
Every allow and every deny, signed and queryable.
Migrating your existing rules takes minutes
If your team has already put work into settings.json, that work carries over directly. The Import from settings.json option in the policy builder accepts your existing Claude Code configuration and creates the equivalent rules in the console. Your current rules become the baseline, and scoping, device conditions, and audit logging layer on top from there.
The rule syntax is identical. The path from "we have a settings.json that works for us" to "that same policy is now centrally managed, identity-scoped, and fully auditable" is an import and about fifteen minutes of configuration.
Get started in two commands
Your Claude Code sessions can be wrapped in a full enforcement and audit layer right now. No proxy configuration. No changes to how developers work. Run these two commands and you're enrolled:
curl -fsSL https://agent.beyondidentity.com/install.sh | bash
ceros claudeConnect the admin console, import your existing rules if you have them, and you'll have full policy visibility across your enrolled devices within the first session.
Sign up at beyondidentity.ai or reach out at @coltonchojnacki if you want to walk through your specific setup first.