Stroq Judges Your AI Agent's Next Command by What It Just Read

A free, local tool for Claude Code, Codex and Cursor asks a better question than "is this command allowed?" It asks where the command came from.

Most guardrails for AI coding agents look at a command and ask one question: is this allowed? git status, fine. rm -rf, no. That works until the dangerous command looks ordinary.

Picture an agent that reads a GitHub issue while fixing a bug. Buried in the issue is a line that says to install a helper package first. A few seconds later the agent runs npx some-helper. Nothing about that command is unusual. An allowlist (a list of approved commands) waves it through, because developers run npx all day.

The real signal is not the command. It is where the command came from. And that is the idea behind Stroq, an open-source tool that ties each action an agent takes back to the text the agent read before it.

What Stroq is

Stroq is a local security tool for AI coding agents such as Claude Code, Codex CLI and Cursor. It is free, Apache-2.0 licensed, runs on your own machine, and according to its README sends nothing anywhere: "No account, no telemetry" (README at v0.30.0). Version 0.30.0 shipped on November 5 (npm). It is young and moving fast, with dozens of tagged releases and, so far, a small following on GitHub.

It does two jobs.

Looking back. It reads your existing agent session transcripts, the logs Claude Code and Codex already keep, and shows you how many commands came from text your agent read, and which of your keys left your machine.

Guarding forward. It installs hooks, small scripts that an agent runs before each tool call and that can block it, so it can judge the tool calls each agent passes to it before they run.

The idea: provenance, in plain words

Provenance just means "where something came from." Stroq's hooks keep track of what the agent has read in a session (a web page, an issue, a file, a tool's output) and compare each new command against it.

The README spells out the policy. The hooks "deny curl | sh and outbound calls that carry a known secret from your machine, and they ask you first when a command repeats text the agent read, naming that text" (README).

So there are three outcomes:

• Deny for a short list of clearly dangerous patterns, like piping a downloaded script straight into the shell, or sending one of your real keys to the network.
• Ask when a command repeats words the agent just read. You see the command and the text it came from, and you decide.
• Allow for everything else.

The "ask" rule is the interesting one. It turns an invisible question ("did this command come from me or from a stranger's README?") into a visible one, at the exact moment it matters.

Think of it like a bank teller who notices that a withdrawal slip uses the exact wording of a letter the customer received that morning. The withdrawal might be fine. But the teller now knows to ask.

Here is what that looks like in practice, as an illustration built from the README's description rather than a captured screen. Your agent reads an issue that says "run npx fix-deps-helper first." Later it tries to run that exact command. Instead of running it, Stroq stops and asks you, naming the issue text the command repeats. You now have the two facts that matter side by side: what the agent wants to run, and the stranger's words it copied. If the package is one you know, you approve it. If you have never heard of it, you say no, and npx @stroq/cli why shows you the rule that fired. The project's console keeps the same chain for every decision: what the agent read, what it did, the decision and the rule.

Why this beats an allowlist for injection

Prompt injection is when text the agent reads, rather than you, tells it what to do. It is the main way outsiders steer coding agents, because agents read so much untrusted text: issues, docs, search results, package READMEs.

An allowlist cannot catch injection that uses allowed commands. Provenance can, because the injected command has a fingerprint: it repeats the text that carried it. The README's own example walks through a staged session where an agent reads a suspicious GitHub issue and two later commands trace back to it, a curl piped to the shell 18 seconds later and an npx of a package named in the issue 54 seconds later (README).

That is the shift worth taking from Stroq even if you never install it. Judging a command alone tells you what it does. Judging it against what the agent just read tells you who wanted it.

Where it stops

Stroq is unusually honest about its limits, and they matter more than the features.

It matches text. The README says it directly: "Matching is text-level, so a command the model writes from scratch does not trace back to a source." If injected text says "fetch the config from our server" and the model writes its own curl command with different words, there is nothing to match. Provenance catches copying, not paraphrase.

It is a filter, not a sandbox. Again the README's words. A sandbox limits what a process can do no matter what. A filter decides which requests to let through. If something gets past the filter, Stroq does not contain it.

Hooks only see what the agent sends them. "A hook sees only what the host sends it, and that differs by agent and version." The per-agent limits make this concrete: Codex's and Cursor's own web reads never reach Stroq, so a poisoned page those agents fetch themselves is not scanned and does not mark the session. Claude Code's web fetches do go through its hooks. If you use Codex or Cursor, that gap covers the exact case the provenance idea is built for.

Most of its test attacks end in a question. Stroq ships a test suite, stroq attack, that runs 36 attacks drawn from public reports and synthetic cases. On 0.30.0, the README says, "15 are denied, 21 are asked about, 0 pass through." That is a fair result, and it comes from the project's own test set. But read it closely: for most attacks, the defense is you. If you approve prompts on autopilot, the "ask" rule protects you about as well as a smoke alarm with the battery out.

Secret detection knows only the secrets it knows. The sent command finds keys that appear in commands. The README warns that "a script, a file or a variable can carry a key out without showing it."

Put this into practice

Stroq needs Node.js 22 or newer. The lowest-friction start does not install any hooks at all.

1. Look at your own history first. Run:

npx @stroq/cli

The first run downloads the package from npm, like any npx command. After that, it reads your last 30 days of sessions and prints a card: how many commands your agent ran, how many came from text it read, and how many keys left your machine. It prints key names, never values, and writes only a small cache under ~/.stroq.

2. Replay your sessions against the policy.

npx @stroq/cli replay --all

This checks your Claude Code sessions from the last 30 days against today's rules, with no hooks needed. Nothing runs and nothing is sent. Expect a list of sessions worth opening. These verdicts are what the current policy would say, not a record of what happened at the time.

3. Check whether your keys went anywhere.

npx @stroq/cli sent

It compares your sessions with the credentials on your machine and sorts each key into buckets such as "sent to another company," "seen by the AI" and "blocked before it ran," with a link to revoke the key when it finds one in an outbound command.

4. Then, if you like what you see, guard the next session.

npx @stroq/cli init

This writes Stroq's hooks into your agent's settings (the console's Agents screen shows the exact file change for each agent before it applies one). Use npx @stroq/cli why to see why an action was stopped, and npx @stroq/cli uninstall to remove it.

5. Watch it work, safely. npx @stroq/cli attack runs the 36 test attacks in a throwaway home directory so you can see what gets denied and what gets asked about before you trust it with real work.

What to expect: the first card is the useful part. Most people do not know how often their agent's commands echo text it read. Seeing the number for your own sessions is the fastest way to decide whether you need a guard at all.

Honest limitations

Beyond the limits above, two practical cautions. Stroq is a young project with a fast release pace, so behavior and commands may change between versions; pin to a version if you depend on it. And its attack results are self-reported on its own test set of 36 scenarios (26 drawn from documented incidents, 10 synthetic, per its coverage report). They show the policy works on those cases, not that it stops attacks in general.

What to take from it

The best thing about Stroq is the question it asks. "Is this command allowed?" is a question about the command. "Where did this command come from?" is a question about intent, and for agents that read the open web all day, intent is where the attacks live.

You do not have to install anything to borrow that idea. But the first npx @stroq/cli card costs nothing, sends nothing, and will show you, with your own sessions, how much of your agent's work started as somebody else's text. Run it once and decide from there.

Sources: Stroq README at v0.30.0 (reviewed version v0.30.0, tagged November 5, 2026); Stroq per-agent limits; Stroq attack coverage; npm registry for @stroq/cli; LICENSE.