Verify a project boundary

Before you start

Use a disposable test project and harmless fixtures. Create one readable file inside the intended scope and a different file outside it. Keep real secrets and personal data out of the test.

Record the runtime version, host integration and policy being tested. The goal is evidence for one actual call path, not a general security certification.

Inspect the effective boundary

lean-ctx security status

Review the configured allowed roots and confirm that the host read routes through LeanCTX. The working directory alone is not proof of the effective access policy.

Exercise allowed and denied reads

Read the inside fixture through the intended host tool. Then request the outside fixture through the same path and confirm the expected refusal.

When relevant to your platform, test a symlink inside the project that resolves outside the allowed roots. Resolved paths must stay within the configured boundary. Record the response rather than assuming the operation was blocked.

A successful shell command or unrelated host file read is a different path and needs its own controls.

Test content handling separately

Path access and content inspection answer different questions. Configure the intended text policy and validate it:

lean-ctx policy validate
lean-ctx policy show

Use a harmless detector fixture through the supported MCP text-return path. Confirm the configured warn, redact or block response and whether the returned content contains the fixture.

Filters are off unless enabled. Coverage depends on the selected path; images, binary content and unrelated raw host reads are not automatically covered. Classification configured as redact is treated as block in the reviewed implementation.

Inspect the evidence

Confirm the recorded category and count without expecting the audit to copy sensitive matched values. Test both an expected detection and a benign input.

If the result differs from the policy, stop using that assumption and inspect the effective configuration before proceeding.

Check the result

Keep the version, configuration, fixture type, call path and observed response together. Your conclusion applies to those tested conditions. Repeat the relevant checks after changing integration or policy.

Continue with read-time filters for the exact configuration and security for the broader boundary.

Sources & versions13 references · Reviewed 17 Sept 2026

• pathjail.rsrust/src/core/pathjail.rsReviewed checkout
• workspace_authority.rsrust/src/core/workspace_authority.rsReviewed checkout
• workspace_cmd.rsrust/src/cli/workspace_cmd.rsReviewed checkout
• pathjail_scope.rsrust/src/core/pathjail_scope.rsReviewed checkout
• walk_guard.rsrust/src/tools/walk_guard.rsReviewed checkout
• allow_path_cmd.rsrust/src/cli/allow_path_cmd.rsReviewed checkout
• project_pins.rsrust/src/hooks/project_pins.rsReviewed checkout
• self_config.rsrust/src/core/shell_allowlist/self_config.rsReviewed checkout
• mod.rsrust/src/core/shell_allowlist/mod.rsGitHub
• sandbox.rsrust/src/core/sandbox.rsReviewed checkout
• secret_detection.rsrust/src/core/secret_detection.rsGitHub
• pipeline.rsrust/src/server/call_tool/pipeline.rsReviewed checkout
• 13-security-and-governance.mddocs/reference/13-security-and-governance.mdGitHub

Core checkout

0ce2207ee4

Reviewed runtime

3.10.2

SDK release

1.1.0

Separate baselines for source, CLI/configuration and SDK contracts. Review does not certify every platform or integration.

Versions & compatibility