Let's Use Claude Code Safely [Internal Study Session Slides]

We held a study session titled "Using Claude Code Safely Study Session" for internal team members (Cloud Business Division Consulting Department). We covered basic concepts for using Claude Code securely, introduced permission/sandbox features, and conducted a simple demonstration.

Here is the slide deck adjusted for DevelopersIO.

Below are the configuration samples shared during the study session.

• Using Claude Code Safely Study Session: Supplementary Materials - Gist

Slide content text is provided below for your reference.

Introduction

I'll talk about the purpose of this study session, the agenda, and scope.

Purpose of the Study Session

Claude Code (and AI agents in general) is very convenient. However, there are risks, and it can go out of control.

In this session, we will learn how to set up guardrails so that Claude Code can operate appropriately within proper boundaries.

Agenda

1. Understanding how Claude Code works
2. How to use Claude Code safely?
3. Techniques for deterrence
4. Techniques for restriction
5. Techniques for isolation
6. Various other topics

What we will cover / What we won't cover

What we will cover

• How Claude Code works and security concepts
• settings.json permissions / Hooks / Sandbox
• Sharing recommended setting samples

What we won't cover

• Security of extensions like MCP / Skills
• Security of related technologies (GitHub / Terraform / coding, etc.)
• Detailed instructions on writing settings.json
• Governance and compliance topics
  • Geographic constraints on inference, data retention periods, audit requirements, etc.

Understanding how Claude Code works

I'll explain how Claude Code works, especially the agentic loop and tools.

Agentic Loop

The agentic loop consists of three phases: gathering context, taking action, and verifying results. You are also part of the loop.

Agentic loop diagram: Gather context → Take action → Verify results. User intervention is included

Components of the Agentic Loop

The agentic loop is driven by inference models and tools that execute actions.

• Models: Understand code and reason/decide what to do next
  • Examples: sonnet, opus
• Tools: Perform actual file operations and command execution based on the model's judgment
  • Examples: Read, Edit, Bash

Reference: What Built-in Tools Can Do

– Quote: How Claude Code Works - Claude Code Docs (excerpt)

Tools are Key to Agentic Functionality

Without tools, Claude could only provide text responses. With tools, it can execute actions.

<Tool control is the key to security!>

How to Use Claude Code Safely?

To create a secure environment, controlling tools is critical.

Let's learn what control approaches are available.

Three Axes to Consider

• Deter: Guide away from executing dangerous tools
• Restrict: Prevent execution of dangerous tools
• Isolate: Create an environment where executing dangerous tools is safe

How to Implement in Claude Code?

• Deter → CLAUDE.md
• Restrict → Permissions, Hooks
• Isolate → Sandbox, Dev Container

(Each will be explained in detail later!)

AWS Analogy for Cloud Business Division

*Note: Please don't take this analogy too literally

Deter

CLAUDE.md ≈ AWS usage guidelines. Has some influence in guiding behavior but is just a guideline

Restrict

settings.json [permissions] ≈ User policies or SCPs. Systematically restrict allowed/disallowed operations

Isolate

Dev Container or Sandboxing ≈ AWS account separation. Isolate environments so hands can't reach beyond boundaries

Techniques for Deterrence

Let's consider techniques to request Claude not to execute dangerous tools.

CLAUDE.md

Let's look at how to use CLAUDE.md to give Claude persistent instructions.

What is CLAUDE.md?

The CLAUDE.md file is a markdown file that provides persistent instructions to Claude for your project, personal workflow, or across your organization. Claude reads these at the start of each session.

– How Claude Remembers Your Project - Claude Code Docs

Where to Place CLAUDE.md (Scope)

The scope of CLAUDE.md varies depending on where it's placed.

– Choose Where to Place Your CLAUDE.md File - Claude Code Docs

Sample "Request" to Avoid Dangerous Tool Execution

Here's an example of writing what you don't want Claude to do in CLAUDE.md:

# Security

- Do not read, edit, or commit sensitive files like .env, credentials, etc.
- Do not hardcode secrets or API keys in code
- Do not execute destructive commands like rm -rf / or force push

Other Deterrence Methods

There are several other points to consider besides CLAUDE.md.

• You can place context files in .claude/rules/
  • You can write rules scoped to specific files using the paths field
• Avoid ambiguous instructions
  • "Authentication is failing, fix it" → May lead to a wide range of experimental operations
• Don't request destructive operations from Claude in the first place
  • terraform apply/destroy, directory deletion, etc.

Techniques for Restriction

Let's learn about mechanisms to mechanically control tool execution.

To do this, let's first understand the tools.

Types of Tools

Claude Code executes actions through built-in tools. The main tools are:

– Tools Reference - Claude Code Docs

Tools That Need Special Control

From a security perspective, these are the tools that need particular attention:

• Bash: Can execute any shell command
• Read: Can read sensitive files (like .env)
• Edit / Write: Can modify files that shouldn't be changed

Controlling Permissions with settings.json

Tool control is specified in the permissions section of settings.json.

What is settings.json?

It's a configuration file that defines Claude Code's behavior.

It defines permission rules, hooks, sandbox, and various other settings.

• Reference: settings#Available Settings

Where to Place settings.json (Scope)

The scope of settings.json varies depending on where it's placed.

– Configuration Scopes - Claude Code Docs

Writing Permission Rules in the permissions Section

{
  "permissions": {
    "allow": [ ... ],
    "ask":   [ ... ],
    "deny":  [ ... ]
  }
}

• allow: Allow tool use without manual approval
• ask: Prompt for confirmation each time the tool is used
• deny: Refuse tool use

Tips: Evaluation Order

Permission rules are evaluated in the order deny → ask → allow.

Since the first matching rule takes precedence, deny always has top priority.

How to Write Permission Rules

Rules are written in the format Tool or Tool(specifier).

– Permission Rule Syntax - Claude Code Docs (recommended reading!)

Sample Recommended Settings

Example to place in ~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(//**/.env*)",
      "Read(//**/credentials*)",
      "Edit(//**/.env*)",
      "Edit(//**/credentials*)",
      "Bash(rm *)",
      "Bash(git *)"
]}}

• For complete samples, see → Gist

Other Restriction Methods: Hooks

Some things can't be fully covered by settings.json denials.

For such cases, use Hooks (or Sandbox, discussed next).

What are Hooks?

Hooks are user-defined shell commands (etc.) that run automatically at specific points in the Claude Code lifecycle. They're also defined in settings.json.

– Claude Code Hooks - Claude Code Docs

Examples of Lifecycle Events

In the context of tool control, PreToolUse is commonly used.

Hook Usage Example

Use a PreToolUse hook. Implement a hook that validates URLs in Bash commands and blocks disallowed domains.

– Setting Permissions - Claude Code Docs

For specific syntax, refer to the Hooks Reference.

Techniques for Isolation

Let's learn about mechanisms to limit the scope of impact.

Sandbox

This is a mechanism to restrict the filesystem and network access of the Bash tool at the OS level.

What is Sandboxing?

Claude Code includes a native sandboxing feature that provides a safer environment for agent execution while reducing the need for continuous permission prompts. Instead of asking for permission to execute each bash command, sandboxing creates pre-defined boundaries allowing Claude Code to operate more freely while mitigating risks.

– Sandboxing - Claude Code Docs

The scope of sandboxing is only the Bash tool and its child processes. Other built-in tools like Read, Edit, Write, WebFetch, etc., are not affected.

What's the Benefit?

Permission deny patterns match command strings.

"deny": ["Bash(cat .env)", "Bash(curl example.com)"]

However, commands can be rewritten in countless ways. python -c "print(open('.env').read())" or less .env, or my-custom-script .env, etc., can all bypass restrictions.

Sandboxing restricts file access and network connections at the OS level, so the same constraints apply to all child processes regardless of command names.

How to Enable

Add the following to settings.json (or enable with /sandbox):

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": false
}}

How to Set Boundaries

Example of sandbox configuration (filesystem / network / excludedCommands etc.)

Define in sandbox > filesystem, network. For detailed syntax, refer to the official reference. For a sample → Gist

Other Isolation Methods: Dev Container

For stronger isolation, Dev Container is also an option.

• Run Claude Code in a container, completely isolated from the host system
• Restrict network connections with a firewall whitelist
• Anthropic provides a reference implementation

Various Other Topics

Here are various tips, impressions, and notes.

Some parts may not be well organized.

Be Careful Where You Launch Claude Code

By default, Claude Code can access files in the directory where it was launched. Therefore, limiting where you launch it also limits its access scope.

Avoid launching in large directories like your home directory or directories with mixed projects/contexts. This reduces the risk of accessing unrelated files.

• Reference: Working Directory - Claude Code Docs

How to Choose Between Permissions / Hooks / Sandbox?

Permissions and sandbox are complementary and both should be used.

• Basic control of each tool → Permissions
• OS-level containment of Bash execution → Sandbox

Hooks are useful for advanced allow/deny decisions that are difficult to control with Permissions or sandbox.

Initial Impressions of Using Sandbox (Rough Notes)

• Very convenient for containing file read/write and network access circumventions that can't be fully prevented with permissions.deny Bash(xx)

• By default, Bash execution is allowed without approval. Added autoAllowBashIfSandboxed:false because that's scary

• By default, when Bash execution fails in sandbox, it tries to re-execute outside sandbox after asking for approval

  • Added allowUnsandboxedCommands:false to prevent bypass
  • Best practice seems to be explicitly listing commands you want to run outside sandbox in excludedCommands

• Initially, you'll frequently see Bash execution failures or network access approval/denial confirmations. Practical approach is to gradually tune settings while using

• For example, executing the aws command repeatedly asks for approval to access 169.254.169.254 (instance metadata) and *.amazonaws.com. Better to allow these in network.allowedDomains

• Go-based tools like gh/terraform fail in sandbox because they can't access macOS TLS trust services

  • Can be worked around with enableWeakerNetworkIsolation:true but this weakens network isolation

Use Different Permission Modes

Permission modes list: default / acceptEdits / plan / auto / bypassPermissions / dontAsk and their respective uses

– Quote: Available Modes - Claude Code Docs

Don't Use dangerously-skip-permissions as a Rule

The --dangerously-skip-permissions flag is equivalent to --permission-mode bypassPermissions. It skips all permission prompts except for writes to protected directories. Generally avoid using it unless running in a strongly isolated environment.

Impressions of autoMode (Rough Notes)

• autoMode uses a classifier model to judge the safety of actions and decides execution without permission (currently in research preview)
• Brief impression: It executes quite a lot without approval, which feels a bit scary. Would want to properly lock down Permissions and Sandboxing settings before using
• Unverified: You can share trusted infrastructure with the classifier via autoMode.environment
• Unverified: You can override classifier's built-in block/allow rules
  • Define additional rules in autoMode.allow / autoMode.soft_deny
  • Get complete list of defaults with claude auto-mode defaults and edit based on that (don't start from an empty list)

Example of overriding block/allow rules with autoMode's allow / soft_deny settings

Small Tip: Removing "🤖 Co-Authored-By"

You can customize git commit and pull request messages by updating the attribution key. Here's how to set them to empty:

{
  "attribution": {
    "commit": "",
    "pr": ""
}}

Note: The includeCoAuthoredBy setting is now deprecated.

Set Up Claude Code's Surrounding Environment

• Secret management tools (1Password CLI, aws-vault, etc.)
  • Avoid storing credentials in plaintext in .env files
  • Eliminate the risk of Claude Code reading sensitive information
• .gitignore
  • Always ignore sensitive information. Reduce the risk of accidentally including it in commits
  • Also ignore personal settings like settings.local.json to prevent mixing personal settings with other members
• pre-commit
  • Detect and block secret commits with gitleaks
• And more...

Useful Resources

• Official documentation worth reading
  • Claude Code Settings: Basic specifications and list of configurable keys
  • Settings > Permissions: Permission rule syntax
  • Settings > Sandboxing: Understanding sandbox functionality
  • Getting Started > Permission Modes: Understanding permissions for each mode
  • Reference > Tools: List of available tools

Conclusion

Here's what we covered today:

• Tool control is key to using Claude Code safely
• Deter: Make requests through CLAUDE.md, but understand it's just basic protection
• Restrict: Define deny/ask/allow with permissions. Supplement with Hooks for complex decisions
• Isolate: Contain Bash tools at the OS level with sandbox. Consider Dev Container for stronger isolation
• Also set up surrounding environment (secret management, .gitignore, pre-commit, etc.)

Let's create a safe Claude Code environment!

References

Links referenced during the creation of this material.

Claude Code Official Documentation

• Basic Information
  • How Claude Code Works
  • How Claude Remembers Your Project
  • Model Configuration
  • Permission Modes
• settings.json (Permissions/Tools/Hooks)
  • Claude Code Settings
  • Setting Permissions
  • Tools Reference
  • Hooks Reference
• Sandbox, Dev Container
  • Sandboxing
  • Dev Container

Related Repositories & Tools

• anthropics/claude-code : .devcontainer - Dev Container Reference Implementation
• 1Password CLI
• 99designs/aws-vault
• pre-commit
• gitleaks/gitleaks