Developer data protection
Claude
Keep secrets out of Claude Code context
Keep real credentials outside the material a coding task needs, configure the relevant Claude Code file and tool permissions, and verify the effective boundary with fake markers. Test direct reads, search and shell access separately in the intended client and mode. A deny rule’s presence is useful configuration evidence, but it is not a recorded outcome for every operation.
For Engineering security and Claude Code administrators
Record the permission decision and the visible result.
Synthetic canaries and blank observations. No current Claude Code or Aona behaviour has been tested here.01
Remove unnecessary credentials from the task
Start with the smallest workspace the developer needs. Credentials that are irrelevant to a coding task should not be included merely because they normally live beside the source. Use the organisation’s approved secret-management process rather than copying real values into a review conversation.
A file-access review is different from checking whether text resembles a secret. The synthetic markers in this guide are useful for seeing whether content becomes available. They are not realistic provider keys and may not trigger a secret detector. Do not substitute a working credential to make the exercise seem more convincing.
02
Read the effective permission rules
Claude Code documents allow, ask and deny rules, with deny evaluated before ask and allow. The permissions interface identifies the settings files from which rules originate. Inspect the effective rules for the client you are using, including managed and project configuration, rather than relying on a saved example from another machine.
The inert claude-settings.fragment.json targets only Read(./.env.canary), matching the fake file created in the isolated folder. Review it before an authorised administrator merges it into that fixture project’s supported settings; it is not loaded automatically. Verify the effective rule and its source in /permissions. Do not overwrite global or managed settings.
| Fragment key | Fixture-only value | Documented purpose |
|---|---|---|
| permissions.deny | Read(./.env.canary) | Deny the direct file-reading path at this relative location |
Source context: Claude Code: Configure permissions
03
Separate direct reads, searches and shell results
Establish that the approved client can read the permitted marker first. Then test the fake restricted file through the direct file-reading path and through the search or shell operations relevant to the developer’s task. Record a denial, approval request or returned marker without trying to defeat a control.
Current docs describe best-effort application of Read rules to other file-reading paths and limits for indirect subprocess reads. The OS sandbox is a separate boundary: the reviewed Bash-sandbox documentation lists macOS, Linux and WSL2, not native Windows. Record client/extension versions, shell, mode and sandbox availability. Do not extend a direct-read result to every operation.
| Operation | Record before testing | Observe |
|---|---|---|
| Direct file read | Effective file rule and relative path | Deny, ask or marker returned |
| Search in fixture folder | Tool, scope and matching rule | Decision and visible marker |
| Shell read of fixture | Shell, sandbox and permission mode | Decision and output |
| Allowed baseline | Same client and folder | Whether permitted text is readable |
Source context: Claude Code: Configure permissions · Claude Code: Sandboxed Bash tool
04
Record facts before interpreting a failure
Use one operation per worksheet row so that a command group does not hide which decision produced the result. Keep the expected policy, observed permission action and observed output in separate columns. “The rule exists” and “the content did not appear” are different facts.
A dated public issue reported recursive-command behaviour for a particular Claude Code version and Windows editor environment. It is useful motivation to include relevant operations in a review, not evidence that every current release has that behaviour. This page has not reproduced that report and supplies no installed-product result.
Source context: Claude Code: version-specific recursive-read report
05
Make the result maintainable
If a marker appears where policy requires exclusion, preserve the version and minimal synthetic reproduction for the responsible administrator. Keep real secrets out of the troubleshooting bundle. Do not broaden permissions or switch to a bypass mode as a way of completing a security test.
Recheck after client, extension, shell, operating-system or policy changes. Approve the combination that was reviewed, with an owner for unresolved paths. Supported endpoint data protection may provide another layer, but its policy and outcome need separate evidence from the client’s local file controls.
Source context: Aona: AI security coverage
Put it into practice
Claude Code fake-secret access review
Review direct file, search and shell operations against the same harmless marker.
Synthetic canaries and blank observations. No current Claude Code or Aona behaviour has been tested here.
| Fixture | Purpose | State |
|---|---|---|
| allowed-marker.txt | Confirm the baseline can be read | Untested |
| env-canary.txt | Copy to .env.canary in the test folder | Synthetic only |
| operations.csv | Separate permission action and output | Blank observations |
Work through your review
Use the checks to organise the evidence you need. Your selections stay in this tab.
0 of 3 reviewed
Example files for this task
Keep the source material and the instructions together. You can also download the complete worksheet or matrix as CSV.
README.mdInspect
# Claude Code fake-secret review
Synthetic fixture only. No file applies settings, invokes Claude Code or makes API calls. No real secrets are included.
1. Use a NEW isolated folder containing only this pack. Copy env-canary.txt to .env.canary. Do not use a real repository or symlink to other data.
2. Inspect claude-settings.fragment.json. Its only rule is permissions.deny: Read(./.env.canary), documented relative to the current directory. It is not an active settings filename. An authorised administrator may merge this reviewed fragment into the isolated project's supported settings, preserving every existing or managed restriction. Do not overwrite global settings.
3. Open that fixture folder in the approved client. In /permissions, verify the exact effective Read(./.env.canary) rule and its settings source. Record client/extension version, OS, shell and mode. If the rule is unsupported or not effective, stop and record that finding.
4. Establish the permitted baseline with the built-in file-reading tool on allowed-marker.txt.
5. Request the direct built-in read of .env.canary. With the exact rule active, the intended result is denial. Record the actual decision and whether the synthetic marker appeared; no result is supplied here.
6. Separately, if permitted by the approved test, review a named-file search and a shell read of ONLY .env.canary from this folder. Read rules have documented limits for indirect subprocess operations. Record those paths separately; do not select bypass mode or relax a sandbox.
7. Use operations.csv. Distinguish the intended policy from the observed tool decision and output.
Source review: 2026-09-21. Follow current permission syntax and supported client versions. The reviewed Bash sandbox supports macOS, Linux and WSL2; do not assume native-Windows OS-sandbox protection from this fragment. This is a direct-read rule, not a universal filesystem barrier.
## Guide and source references
Canonical guide: https://aona.ai/resources/guides/claude-code-env-secrets-permissions/
Source review: 2026-09-21
- Claude Code: Configure permissions: https://code.claude.com/docs/en/permissions
- Claude Code: Sandboxed Bash tool: https://code.claude.com/docs/en/sandboxing
- Claude Code: version-specific recursive-read report: https://github.com/anthropics/claude-code/issues/91690
- Aona: AI security coverage: https://aona.ai/resources/ai-security-coverage/
allowed-marker.txtInspect
SYNTHETIC_D05_ALLOWED_BASELINE
env-canary.txtInspect
EXAMPLE_ONLY=NOT_A_CREDENTIAL_D05_CANARY
operations.csvInspect
date,client_version,extension_version,os,shell,permission_mode,sandbox_state,rule_source,operation,expected_policy,permission_action,marker_returned,evidence
,,,,,,,,allowed baseline,DEFINE,UNTESTED,UNTESTED,
,,,,,,,,direct file read,DEFINE,UNTESTED,UNTESTED,
,,,,,,,,scoped search,DEFINE,UNTESTED,UNTESTED,
,,,,,,,,shell read,DEFINE,UNTESTED,UNTESTED,
review-note.mdInspect
# Access review decision
Restricted fixture path: .env.canary
Data: a fake marker, not a credential
Intended restriction: ____________________
Effective rule source: ____________________
Supported sandbox and prerequisites: ____________________
Observed configuration: ____________________
Unresolved path and owner: ____________________
Decision: NOT YET REVIEWED
Recheck after client, extension, shell, OS or policy change.
claude-settings.fragment.jsonInspect
{
"permissions": {
"deny": [
"Read(./.env.canary)"
]
}
}
Before you proceed
Keep these distinctions clear
- Using a detector test to answer a read-permission question
- A plain marker shows content access. A data-classification test needs a separately agreed, safe trigger.
- Publishing a historic issue as a current flaw
- Keep the report’s version and environment attached, and distinguish it from your own observation.
Apply it to employee AI use
Bring your actual data path.
Aona can help evaluate supported native endpoint prompt or file paths with an agreed synthetic input.
Aona does not replace Claude Code filesystem permissions, and this guide does not establish coverage of every shell result or CLI operation.
Bring the operations sheet and the intended restriction to a scoped installed-client review.
Review your use caseFAQ
Questions for this decision
Is a prompt telling Claude not to read .env enough?
Can I test with a revoked API key?
Does a direct Read denial cover every shell operation?
Are the reported recursive-command issues confirmed here?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- Claude Code: Configure permissions
Documents rule order, effective settings and tool-specific matching.
vendor · checked 2026-09-21 - Claude Code: Sandboxed Bash tool
Documents supported sandbox platforms, prerequisites and filesystem/network scope.
vendor · checked 2026-09-21 - Claude Code: version-specific recursive-read report
A dated, unverified practitioner report; supports testing operations separately, not a universal current flaw claim.
practitioner · checked 2026-09-21 - Aona: AI security coverage
Requires supported installed-client paths and separates native inspection from broader control claims.
vendor · checked 2026-09-21