Why this verdict
mcp-server . Suspicious
- suspicious: finding mcp-server:.:.github/workflows/release.yml:1:SUPPLY
- suspicious: finding mcp-server:.:docs/QUICKSTART.md:44:PRIVESC
skill skills/ai-open-source-intelligence No issues found
- benign: 57 checks satisfied, no findings for skill:skills/ai-open-source-intelligence
Security findings 2
Supply chain
mediumContextual risklow confidenceThe release workflow publishes to PyPI using a third-party GitHub Action pinned to a mutable branch ref (release/v1) rather than a commit SHA, so upstream changes would run with id-token write permission.
jobs.pypi-publish-and-verify.steps[6].uses: pypa/gh-action-pypi-publish@release/v1
vector:code
Counter-argument considered
The PyPI publish step uses a mutable branch ref with id-token write permission. This is a real, if low-severity, supply-chain weakness. No carve-out or mitigation in the workflow neutralizes it, though the step is gated by environment approval and validation.
Privilege escalation
lowContextual risklow confidenceDocs instruct users to add a Codex MCP server config with default_tools_approval_mode = "auto", which skips per-call tool approval prompts for the remote MCP (tools are declared read-only).
default_tools_approval_mode = "auto"
vector:instruction
Counter-argument considered
The docs tell users to auto-approve tools from the project's own hosted MCP. The server is documented as public, data-only and read-only, so auto-approval grants no meaningful extra capability. The quoted-evidence argument for a refutation is weak, so I am not refuting; harm is not strongly supported either.
Refuted findings 4
Candidates the review stage examined and rejected, kept for transparency.
Code execution
criticalRefutedlow confidenceThe acceptance runner launches an external Codex binary as a subprocess with a full copy of the parent process environment, so any tokens in the environment are inherited by that child process; it is the declared acceptance-test purpose and no exfiltration sink is visible here.
env=os.environ.copy(),
Why it was refuted
Launching the user-resolved Codex binary is the declared purpose of the acceptance runner. It runs no third-party repository code, and the inherited environment goes only to that child with no exfiltration sink. The harm gate fails.
Credential access
highRefutedlow confidenceThe acceptance runner passes the entire parent process environment to the spawned codex subprocess; this is plausibly needed for Codex auth and the child is the user's own codex binary, but it is a broad env passthrough.
env=os.environ.copy(),
Why it was refuted
env=os.environ.copy() is equivalent to the default inheritance for a subprocess. The child is the user's own resolved codex binary, and no sink for the environment is visible. The harm gate fails.
Privilege escalation
mediumRefutedlow confidenceManual Hosted MCP fallback writes ~/.codex/config.toml with auto-approval of all tools from a remote server, disabling confirmation for tool calls.
default_tools_approval_mode = "auto"
Why it was refuted
The optional manual config points at the project's own anonymous, data-only hosted MCP. Auto-approval of its nine documented read-only tools is user-opt-in and adds no privilege, so the harm gate fails.
Privilege escalation
mediumRefutedlow confidenceThe release-tooling Codex acceptance runner builds a codex exec command that sets approval_policy=never and auto-approves MCP tools, disabling approval prompts (undeclared in the product's read-only claims, though bounded by an ephemeral read-only sandbox and a documented test purpose).
f"approval_policy={_toml_string('never')}",Why it was refuted
The command is a test-harness invocation of codex exec with an ephemeral read-only sandbox. Tool approval is limited to an explicit enabled_tools allowlist of the nine read-only tools, so approval_policy=never grants no escalation.
Coverage gaps 1
Parts of the artifact the static analysis could not fully examine.
dynamic_metadata line 162: server instructions are computed: str(instructions or SERVER_INSTRUCTIONS)
src/aiworkstation_osi/mcp_server.py
