How do I control what my team's coding agents can access?

Separate the layers before you configure anything

"Access" covers several layers, and each one is controlled in a different place. Settling the access on one layer leaves the others open.

Instructions in CLAUDE.md or AGENTS.md are context, not enforcement. Claude Code's own docs say to use a hook or a deny rule when an action must be blocked regardless of what the model decides. [1][2]

Start read-only

Begin each new agent, or each new kind of task, with read-only access, then add writes once you've seen how it behaves.

• Claude Code. Permission rules allow or deny tools and paths, and a bare tool name such as Bash in deny removes the tool entirely. Read(./.env) and Read(./secrets/**) deny rules block Claude's own file tools and the file commands it recognizes in Bash, such as cat. They don't cover a script that opens files itself, so turn on the sandbox for OS-level blocking. Plan mode reads and proposes without editing. [2][3]
• Codex. sandbox_mode = "read-only" lets the agent inspect files but not edit them or run commands without approval. workspace-write allows edits inside the workspace. danger-full-access removes the sandbox. [4]
• Outside services. Prefer a read-only scope even where the vendor offers write.

Use scoped tokens with an expiry, never personal keys

A personal token gives the agent everything you can do. Issue a credential for the agent and the task instead.

• GitHub. Fine-grained personal access tokens can be limited to specific repositories, carry specific permissions and an expiration, and an organization can require approval for them. GitHub recommends them over classic tokens. A fine-grained token still acts as the person who created it, so it gives scoped access rather than a separate agent identity. A GitHub App installation token or a machine user is what gives an agent its own identity. [5]
• One credential per agent. Two agents sharing a token can't be told apart in a log, and you can't revoke one without the other. For a separate identity per agent, use a GitHub App installation token or a machine user, not a personal token.
• Set an expiry you will actually hit. A token that outlives the task is access nobody is using on purpose.
• Keep tokens out of the work record. No tokens in issues, chat, screenshots or commits.

Sandbox the runtime

Permission prompts and sandboxes do different jobs. A prompt asks; a sandbox enforces at the operating-system level even if the model is tricked.

• Claude Code's sandbox restricts filesystem and network access for shell commands and their child processes. Its docs recommend using it together with permission rules, "since sandbox restrictions still apply even if a prompt injection bypasses Claude's decision-making." [2]
• In Claude Code, sandboxed Bash commands run without a prompt by default (autoAllowBashIfSandboxed). Decide whether you want "ask before every command" or "enforce a boundary"; they are different policies. [2]
• Managed settings let an administrator set rules that developers can't override, such as disabling bypass-permissions mode. [2]
• For Codex, choose the sandbox mode and the approval policy separately: --sandbox workspace-write --ask-for-approval on-request. [4]
• For the riskiest work, run the agent in a container or VM with no production credentials inside it.

Gate the actions that are hard to undo

Require a person for deploys, merges to main, destructive database changes, payments and messages to customers. Keep this list short so approvals mean something.

Test the boundary, then widen it

Don't trust a configuration you haven't attacked.

1. Ask the agent to read a file it shouldn't. It should fail on a deny rule.
2. Ask it to reach a host outside the allowlist. It should fail in the sandbox.
3. Ask it to write with a read-only token. The service should refuse.
4. Write down who owns each grant and when it expires.

One way to do this across a team: ARLI

The steps above work on one machine. On a team, the harder part is the outside services. Several people's agents need some access to a tracker like Linear, and each agent should get the access it needs and no more.

In ARLI, each teammate brings their own agent into one pod, and each agent is a named member with an owner. The person who connected Linear grants read access to one agent:

1. Connect Linear on the Connectors page.
2. Grant one agent read access to it.
3. That agent now sees Linear's read tools, and its calls through the grant are logged.

What the grant covers

The agent's local permissions and sandbox are still set in its own runtime. A ARLI grant covers the connected service; it doesn't change what the agent can do on your laptop.

Sources

Sources, checked 2026-10-27.

1. Claude Code docs, "How Claude remembers your project" · 2. Claude Code docs, "Configure permissions" · 3. Claude Code docs, "Common workflows" · 4. OpenAI Codex docs, Sandboxing · 5. GitHub Docs, Managing your personal access tokens · 6. NIST glossary, least privilege

Frequently asked questions