Refuted findings 7
Candidates the review stage examined and rejected, kept for transparency.
Data exfiltration
criticalRefutedlow confidenceUndeclared residue: the bundled workflows reference instructs configuring a remote third-party MCP endpoint (https://mcp.linear.app/mcp), an external network destination not named in the declared purpose, which would route agent context to Linear if the example is followed.
grok mcp add --transport http linear https://mcp.linear.app/mcp
Why it was refuted
Adding a remote HTTP MCP server via `grok mcp add` is the declared 'MCP servers' core capability (the target description explicitly covers MCP servers), demonstrated transparently with the vendor's officially referenced example endpoint, so the harm gate fails on the declared-core-capability carve-out. The command only writes configuration and transmits no agent data itself; any flow to Linear requires explicit subsequent use.
Persistence
criticalRefutedlow confidenceThe workflows example instructs adding a third-party remote HTTP MCP server (mcp.linear.app), writing a remote endpoint into the agent's MCP configuration through which session or workspace data would flow when used.
grok mcp add --transport http linear https://mcp.linear.app/mcp
Why it was refuted
Persistence here is `grok mcp add`, the declared MCP-management capability (subcommands table declares `grok mcp <list|add|remove|doctor>` for managing MCP servers), and the skill transparently gates repo-level persistence by warning that `--scope project` should be used only when config should be written to `.grok/config.toml`. Harm fails via the declared-core-capability carve-out with this stated mitigation, and undeclared fails because the behavior is the declared capability.
Privilege escalation
highRefutedlow confidenceThe bundled Grok CLI reference documents permission-bypass flags (--always-approve/--yolo and the Claude Code alias --dangerously-skip-permissions) that auto-approve tool execution in the operated Grok CLI, enabling unattended unsandboxed actions if the agent selects them; the surrounding text gates this ('only when the environment and command scope justify') but the risky capability is real and reachable from instructions the agent reads.
`--always-approve`, `--yolo` | Auto-approve tool execution; deny rules and hooks still apply.
Why it was refuted
The row openly documents the operated CLI's own permission flags, which is the declared 'permissions' core capability (the flag table is itself declared as capability claims D25/D26 over SRC:fd30e5e41a02c7b2), and the row notes deny rules and hooks still apply. The table documents rather than instructs, so no chain exists; harm and undeclared fail and the finding is refuted.
Agent hijacking
highRefutedlow confidenceThe bundled Grok CLI reference documents flags (--rules to append and --system-prompt-override to replace the system prompt) that override the instructions of the Grok agent being operated when the agent passes text to them; this is documentation of the target CLI within the declared scope, so only the capability, not any use, is established.
`--system-prompt-override <TEXT>` | Replace the system prompt.
Why it was refuted
The row is honest reference documentation of the grok CLI's own system-prompt override flag, configuring the child grok process a user explicitly launches, squarely inside the declared operate-the-CLI capability (D25/D26 cover this table). It directs no override at the reading agent and contains no instruction, so harm and undeclared fail and chain is absent.
Supply chain
highRefutedlow confidenceThe workflows reference instructs fetching and executing an unpinned npm package via `npx -y @modelcontextprotocol/server-filesystem` as an MCP server, an unpinned remote-code supply surface that the declared MCP-server capability does not pin to a version.
grok mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/dir
Why it was refuted
The example is the transparently labeled, officially referenced canonical invocation for adding a local stdio MCP server — the declared 'MCP servers' core capability — using the official @modelcontextprotocol-scoped package, so the harm gate fails on the declared-core-capability carve-out. Lack of version pinning is hygiene feedback about an open example, not undeclared or concealed supply-chain behavior.
Privilege escalation
highRefutedlow confidenceThe skill conditionally instructs use of the wrapped CLI's permission-bypass flags (--always-approve, with --yolo and the Claude Code alias --dangerously-skip-permissions documented in the bundled flag index), letting the grok agent execute tools without per-call approval; this sits inside the broadly declared 'permissions' scope and is plausibly honest, but a bypass capability is not itself declared.
Use `--always-approve` only when the environment and command scope justify unattended execution.
Why it was refuted
Instructing conditional use of `--always-approve` is the declared core capability (the target description covers operating the CLI's 'permissions'), openly declared as capability claim D15 at exactly this line, and the sentence embeds its own mitigation pairing the flag with a sandbox and explicit deny rules. Both the harm (declared-core-capability carve-out with mitigation) and undeclared gates fail, so the finding dies despite reach and a concrete conditional instruction.
Privilege escalation
mediumRefutedlow confidenceThe bundled CLI reference documents a Claude Code compatibility alias --dangerously-skip-permissions that disables the operated grok agent's permission checks.
and `--dangerously-skip-permissions`.
Why it was refuted
The sentence merely lists a Claude Code compatibility alias among the CLI's documented flags, within the declared permissions scope covered by D25/D26, and immediately steers users to native Grok flag names. It documents the CLI rather than instructing a bypass, so harm and undeclared fail and no chain to the claimed behavior exists.
