[Feature Request] Improve defensive security code review handling to avoid false positives on security APIs

**Bug Description**
Defensive security tool review blocked by another provider's filter: request to avoid similar false positives

Body

To be clear up front: this feedback is not about a block that occurred in Claude. The block happened with another provider (OpenAI Codex) that I was using for cross-review. I am sharing the project's nature and the incident in advance so that the same kind of false positive does not occur in Claude.

About the project
DataTrans manages the history of data transfers into and out of air-gapped (network-separated) environments. It is a defensive, preventive tool implementing regulation-mandated security review procedures. Features include a hash-chained ledger (audit log), node identity binding, media registration and disposal management, backup encryption, DACL-based access control, and non-disclosure of internal network information. The developer has a digital forensics background, and the purpose is internal institutional auditing and security compliance. The project falls squarely within the "defensive security, authorized security testing" category that Claude Code explicitly supports.

What happened with the other provider

When the sandbox denied SetNamedSecurityInfo, the model wrote a script stubbing out the ACL functions and was blocked for "disabling security features." That was a judgment on the model's behavior.
The grep output of my own repository's internal/platform/acl package (containing identifiers such as Restricted, everyone, and SID) was enough to trigger a block. Simply reading defensive code was blocked.
As a result, the v1.0.0 release was delayed, and the security package that most needs review has to be excluded from review.

Requests

Please continue to distinguish between reading and verifying defensive logic in one's own code and building offensive tools.
Please base judgments on task context (reviewing one's own repository, running regression tests) rather than on terms like ACL, SID, or permission checks by themselves.
When a security API fails because of insufficient sandbox permissions, the model should report the cause of the failure to the user and propose alternatives, rather than stubbing out or bypassing the feature. This would avoid problems like Run 1 altogether.

**Environment Info**
- Platform: win32
- Terminal: vscode
- Version: 2.1.267
- Feedback ID: 65d0353e-99f0-4258-bfc5-6d532c29753b

**Errors**
```json
[]
```

The issue names no files or tests; start by triaging the reported Claude Code behavior on win32 in VS Code around sandbox-denied SetNamedSecurityInfo and ACL/SID-related defensive code review. Done would mean the tool reports permission failures instead of bypassing security APIs and avoids false positives based only on security API terms.

Written by the indexing model from the issue text.