Claude Code Enterprise Mastery

1With no rules, Claude Code reads your .env without blinking

Team Pulse, the course's small application, ships with no settings at all. Vajariya asks Claude to read the .env, the file where a project keeps its passwords, and to display everything. Claude complies, AWS keys (access to Amazon's cloud) included, without asking permission (video 2_2).

The course lists four threats, four ways to get trapped, and this is only one of them (video 2_3). Here they are:

• Credential leak: your passwords and keys become readable, so they can leave the project. That is the .env demonstration.
• Prompt injection: a prompt is a message written to Claude. Someone hides an instruction in a file Claude reads, like a code comment or a README (a project's introduction page). Claude reads it as text, then follows it as an order.
• Supply chain: your project uses code written by others, called code libraries. If one is booby-trapped, npm install, the command that downloads them, runs a small program that sends your credentials elsewhere.
• Subagents: a subagent is a small assistant that Claude launches for part of the work. According to the course, each one gets your full rights: it can therefore do everything you can do. The documentation does not say so, but provides rules to choose which subagents Claude may launch.

2Deny first, open up afterwards

Against these threats, the course's instruction is simple: forbid everything dangerous, then open up case by case. A rule tells Claude what it may do. It comes in three kinds:

• allow permits without asking.
• ask makes Claude put the question.
• deny refuses.

If two rules contradict each other, deny beats ask, and ask beats allow (the course says so, the documentation confirms it).

The course's starting deny list forbids:

• rm -rf: deleting a folder and everything in it.
• Reading the .env, the SSH keys and the AWS credentials.
• curl, wget and Claude's web tools: commands that fetch or send data on the web.
• chmod 777: opening a file to everyone for reading, writing and running.
• sudo: granting yourself administrator rights.

The deny list is written in a settings file. With that one file alone, the demo's test is run again: Claude refuses to read the .env, and the npm test command, which runs the tests, stays permitted.

This excerpt comes from the documentation, not from the course. It shows only three rules. In Bash(curl *), Bash means the commands typed in the terminal. The star * stands for any run of characters, so the rule targets any command that starts with curl.

{
  "permissions": {
    "deny": ["Read(./.env)", "Bash(curl *)"],
    "allow": ["Bash(npm run test *)"]
  }
}

One detail struck me: the course gives not one deny list but four, and they don't agree. The first is the video's, the five lines above. The other three are in the course's downloadable files:

• The permissions matrix, a table of what each role may do: eight denies.
• The administrator's file, which they enforce on every computer (idea 3): nineteen denies.
• A project's file: ten denies.

None contains all the others. The nineteen-deny file doesn't block Claude's tools that read web pages, which the video blocks. The matrix leaves out sudo, the command that grants administrator rights. Merging them is up to you.

The nineteen-deny file also blocks npx -y and pip install, two commands that download code and then run or install it. The documentation mentions neither. It writes Bash(curl:*) where the documentation shows Bash(curl *): according to it (as of 30 October 2026), that is the same rule written differently.

Vajariya promises too much: "These are your hard boundaries, [Claude] cannot cross them, no matter what" (video 2_1). The documentation qualifies this: see "My take", further down.

3Five layers of settings, and the company's wins

Claude Code does not read its settings in one place but in five, which the course calls layers. Here they are, from strongest to weakest:

1. Managed settings (managed-settings.json): set by the administrator, the person who manages the company's computers. They apply to every employee.
2. Command line: the options typed when launching Claude Code. They apply to a single session, one use from launch to close.
3. Project local (.claude/settings.local.json): your personal settings for this project, kept out of Git, the software that keeps the project's history.
4. Project shared (.claude/settings.json): saved in Git, so anyone who gets the project receives this file.
5. User: your settings valid for all your projects.

First rule: when two layers set the same thing, the higher one wins. Example from the documentation: the team sets the default AI model to Sonnet in the shared file, and you prefer Opus. You write it in your local file, which is above: only your sessions change. The company layer is at the very top, so nothing in your files undoes a managed setting.

Second rule: lists of rules, like allow and deny from idea 2, add up instead of overwriting each other. Course example: a developer allows curl in their global settings, the managed settings forbid it, and the ban wins. The order of the layers does not decide here, the rule from idea 2 does: a deny always wins.

The course adds that the developer can neither see nor change the managed layer, and that a higher layer overwrites the lower ones. The documentation qualifies this: they can see which source applies, with the /status command, and lists add up, as in the second rule above.

4The sandbox against approval fatigue

Well-set rules create another problem: permission prompts pile up. Each one is a message asking you to approve an action by Claude. After the tenth in five minutes, says Vajariya, "you start hitting approve without even actually reading what Claude is asking you to do" (video 2_4). That is approval fatigue: you let a mistake through without seeing it.

The course's answer is the sandbox, switched on with the /sandbox command. It is not a virtual machine, a fake computer inside the computer. It is a fence that the computer's system puts around the commands Claude launches. Inside, Claude works normally: it runs the tests, it writes in the project folder. According to the course, the limits cover files and the internet. As soon as a command goes past them, the system blocks it, whatever Claude decides.

That is where the value lies. The fence is held by the system, not by Claude's good will: so commands that stay inside can be approved automatically. They go through without a question (video 2_4), and the prompts that remain are the ones you will still read. Another mode, accept edits, does the same for files: Claude changes them without asking. In the demo, Claude runs the tests and Git without asking a question.

The sandbox does not replace the deny rules. The .env stays blocked because those rules stay active (the documentation confirms it for commands). Its limit on reading is in "Still relevant in 2026?".

5Before rolling out, four compliance questions, then a checklist by sector

Once the computers are under control, another question comes up: compliance. It is the security team's job, checking that the tool follows the company's rules. According to Vajariya, it decides whether you adopt Claude Code or stop the pilot, the trial run by a few engineers. It asks where the code goes and whether you can audit it, meaning check what it did. The course answers (video 8_1):

• Where the code goes: by default, your prompts go to Anthropic. If the company uses Amazon's cloud (Bedrock) or Google's (Vertex AI) instead, they go through its account at that provider and through its VPC, a private network reserved for your company. Anthropic "literally never" sees them.
  • The documentation is less absolute. Two small things still go to Anthropic: the name of the site the web tool fetches, and the rating of the satisfaction survey (never your conversation). Settings turn both off.
• Training: training a model means making it learn from texts. Anthropic doesn't train its models on commercial plan data, the plans sold to companies. The documentation confirms it, unless the customer chooses to provide its data.
• ZDR (Zero Data Retention, no data kept): once it has answered, Anthropic keeps neither your prompts nor the answers. The course adds that three things remain anyway: usage and billing data (what it takes to bill you), the verdicts of the safety filters and abuse alerts.
  • The documentation does not repeat the course's list. It names two other cases where Anthropic may keep data. First, if the law requires it. Second, if its safety systems spot a session (a conversation with Claude Code) that breaks the usage rules: it may then keep that session for up to two years.
  • ZDR does not come with the Enterprise plan. The company must ask Anthropic for it, and Anthropic grants it to companies that meet its conditions. It is requested separately for each company account.
  • It only protects exchanges with Claude Code. Chat on claude.ai and tools from other publishers plugged into Claude Code do not benefit. Anthropic also keeps the accounts' email addresses and the usage statistics.
• Local audit: every session leaves a plain-text (unencrypted) log in the ~/.claude/projects/ folder, where ~ means your home folder (path checked).

Why go through Amazon or Google? A large company already has a contract with one of them: an invoice, controlled access, rules on where its data may go. Sending its code to Anthropic means one more supplier for the security department to approve. Through Bedrock or Vertex, it uses the same Claude models at a supplier it has already accepted.

The recent models are there: Anthropic's documentation of 30 October 2026 lists Opus 5.5, Sonnet 5.5 and Haiku 5.5 on Bedrock. I found no official promise on how fast a new model arrives. Third-party comparisons speak of a few days to a few weeks after Anthropic.

On price, third-party sites give the same rate as direct. The exact rate is on Amazon's pricing page. One point is official. A regional access address guarantees that the data goes through a given region. It costs 10% more than the global one, which picks the most available route by itself (Anthropic pricing). The real cost stays the administration work: accounts, access, regions, models to choose.

Team and Max subscriptions are flat plans per person, sold by Anthropic. In the documentation I read, Amazon does not sell them. A fourth route exists: Claude Platform on AWS. Anthropic runs it, and the invoice comes through AWS. To tell the routes apart:

Route	Who sees the code	How you pay
Team or Max subscription	Anthropic	Flat fee per person
Direct API	Anthropic	By usage
Claude Platform on AWS	Anthropic	By usage, AWS invoice
Bedrock or Vertex	Amazon or Google, not Anthropic	By usage, the provider's invoice

To prepare that file, video 8_3 itself points to a checklist by sector, to download from the course resources. This compliance checklist is two pages long. It opens with ten requirements common to all, such as a permissions audit every quarter. Then come five blocks, one per regulatory framework:

• SOC 2 Type II, an audit that certifies a supplier protects its customers' data over time: audit logs kept at least 30 days, then sent to a SIEM. A SIEM gathers the security logs of the whole company to spot incidents.
• Healthcare (HIPAA), the American law that protects patient data: ZDR "mandatory", session logs deleted after 7 days at most, and a BAA signed with Anthropic. The BAA is the contract that binds a supplier to protect that data.
• Finance: every exchange with Claude logged, and data kept in approved jurisdictions. The code of trading systems, which buy and sell securities, goes through human review.
• Government (FedRAMP), the program that authorizes a cloud service for the US federal government: a VPC is mandatory, curl and wget are denied.
• GDPR, the European regulation on personal data: a data processing agreement signed with Anthropic, and a right to erasure to organize.

6To avoid a chaotic rollout, three phases, starting with a measured pilot

The team lead's question remains: how do you go from a few curious people to 20, 50 or even 100 engineers without everything going in all directions? Vajariya answers with three phases (video 10_1). His opening line: doing it in phases makes "the difference between success and chaos".

Chaos has precise faces. The repository's adoption playbook, two pages to fill in, lists six:

• No governance: rolling out with no deny rules, no CLAUDE.md (the team's instructions file), no written policy.
• Too fast: a hundred engineers get the tool before the rules are ready.
• Too slow: momentum is lost by over-analyzing the pilot.
• Wrong use cases: scaling tasks that AI doesn't help with.
• No cost monitoring: "discovering a $10k bill after 3 months", that is $10,000.
• No champions: management imposes the tool instead of relying on the teams' enthusiasm.

The video and the playbook give the same three phases, with different lengths: four weeks each in the video, six, then six, then thirteen and beyond in the playbook. The course doesn't say which to follow. The order matters more than the lengths:

1. Pilot: a small group of engineers tries Claude Code, and their work is measured before the tool, for example the time they spend reviewing a PR. A PR (pull request) is a proposed change to the code. In the video's words: "You need these numbers before and after". You also pick two or three people who will help the others later: the video calls them "internal champions".
2. Standardization: what the pilot learned becomes the rule for the whole company. You write CLAUDE.md templates (a team's instructions file), permission rules and shared settings. The playbook adds an AI usage policy, signed off by security and legal, and cost tracking per team.
3. Rollout: you train everyone and open places to ask questions, including a weekly office hour. The internal champions help their colleagues get started.

Before the first phase, the repository's onboarding checklist details the administrator's work. They connect SSO, single sign-on with the company account. They also turn on SCIM, a protocol that creates or removes accounts when an employee joins or leaves. They set spending caps and put the managed settings file in place. For each developer, a simple test closes the setup: ask Claude to read the .env, which must be refused.