Why this verdict
- inconclusive: gap invalid_judge_finding
- inconclusive: gap request_unanswered
- inconclusive: unresolved question on CRED
- inconclusive: unresolved question on EXFIL
Security findings 0
No individual findings recorded
The inconclusive verdict rests on the open questions and coverage gaps below; 1 candidate finding was refuted on review.
Open questions 6
What the analysis could not settle from the code alone.
The skill mandates that all outbound traffic traverse the session's Iron Proxy, trust its injected CA, and forbids bypassing either; nothing in the shown units establishes where the proxy forwards traffic or whether it can alter destinations beyond approved credential insertion. Is the proxy's egress behavior (destination fidelity, traffic modification policy) documented or constrained elsewhere in this artifact?
Data exfiltration
Whether the Iron Proxy's TLS interception and credential injection are restricted to the user-requested API hostname or observe all container egress, and where the injected credentials are stored and forwarded.
Credential access
[invalid file request] What does the ncl groups connect flow do with --host and the returned connect_url — does it transmit any credential material off-host, open a listener, or modify gateway policy, and does that match the skill's statement that the command does not grant access or change policy?
Credential access
[invalid file request] Where is the shared connect handoff defined, and does Iron Proxy restrict forwarding of intercepted traffic and injected credentials to only the user-requested API host or can it send to any other destination?
Credential access
[file request container/bin/ncl] Does this artifact ship the `ncl` executable or wrapper that `ncl groups connect --host <API hostname>` invokes, and if so, what does that connect flow do with the hostname and connect_url — does it send any credential material or change policy contrary to the skill's claims that the command does not grant access or change policy and is an operator-console handoff rather than an OAuth link?
Credential access
[file request .claude/skills/add-iron-proxy/SKILL.md] Where is the shared connect handoff defined, and does the Iron Proxy forward intercepted traffic and injected credentials only to the user-requested API host rather than any other destination?
Credential access
Refuted findings 1
Candidates the review stage examined and rejected, kept for transparency.
Credential access
highRefutedlow confidenceThe skill requires all container egress to route through an HTTP/HTTPS proxy whose custom CA is injected into the trust store, giving the Iron Proxy the technical capability to intercept and read every TLS connection from the container, including credentials not related to the declared API hosts.
Requires HTTP_PROXY, HTTPS_PROXY, and the Iron Proxy CA injected by NanoClaw.
Why it was refuted
The proxy-and-CA requirement is stated verbatim in the skill's own compatibility field and is the declared core capability of an inspecting gateway proxy for external accounts and APIs ('diagnose blocked requests'), so it falls under the declared-core-capability carve-out and is not concealed; the line is also purely declarative metadata with no agent instruction or source-to-sink chain.
Coverage gaps 4
Parts of the artifact the static analysis could not fully examine.
context:unanalyzable_binary binary content is only byte-scanned
.claude/skills/add-clidash/add/tools/clidash/public/favicon.ico
context:unanalyzable_binary binary content is only byte-scanned
src/drivers/docker-driver.ts
invalid_judge_finding request.0
request_unanswered request.0: invalid file request (evidence_ids not shown in the asking request)
