Threat model

Yenop protects against

• ✓
  Tool misuse after a prompt injectionAn agent convinced to act still has to pass a rule. The model's decision is never the final authorization decision.
• ✓
  Unauthorized destructive commands, and writes outside the projectCommands are parsed, not pattern-matched: sudo, xargs, bash -c, $(...), variables and redirects are followed.
• ✓
  Reads of secret files and credential storesHowever the path is spelled or reached: relative, quoted, through a variable, from git history, on Windows or POSIX.
• ✓
  Exfiltration pathsA credential over the network, a download piped into a shell, an outside call after sensitive data.
• ✓
  Multi-step attack chainsEvery run remembers whether it has taken in untrusted content and whether it has touched sensitive data. Steps that look harmless one at a time are judged together.
• ✓
  Tool servers overreaching what they claimed to coverThe MCP gateway judges every tools/call before it reaches the server.
• ✓
  Self-disableAny change to Yenop's own files, policies, mode, daemon, or the hook registration of any agent needs a person.
• ✓
  Runaway loopsPer-run budgets.

Yenop does not claim to protect against

• ✗
  A person with root on the machine, or an attacker who already has itThey can remove Yenop like any other program.
• ✗
  A compromised operating system or a compromised Yenop binary
• ✗
  Vulnerabilities inside a tool that was legitimately allowed to run
• ✗
  Actions taken through a path Yenop is not hooked intoAn agent Yenop does not yet support, or a runtime that ignores a hook by design. Yenop's boundary is fail-closed; a runtime that proceeds when a hook does not answer is fail-open by its own design, and we say so rather than imply otherwise.
• ✗
  A wholesale rewrite of the receipts file from scratchThe hash chain catches edits, deletions and reordering locally. Anchoring the head against a full rewrite is the control plane's job.

Yenop governs agent execution. It does not govern a compromised host.

How it fails

Closed. Any evaluation error is a deny. A policy file that does not parse makes Yenop refuse every action in that project, naming the file and the error, while keeping yenop check, status and receipts working so a person can fix it. Malformed hook input is a deny. Code handed to an interpreter that Yenop cannot read as shell is treated as opaque and needs a person, so obfuscation becomes the reason you are asked.

How we know it works

Not by trying twenty prompts. Three layers, all in the repository and all run on every push:

Surface enumeration. Every event each runtime can emit is listed and has a recorded fixture, so an adapter that stops handling an event fails a test rather than a user.

Property tests. About fourteen thousand generated, disguised commands per run: wrappers, quoting, variables, Windows paths, redirects. The parser must reach the same verdict for every spelling of the same action.

An adversarial harness. A real model, given a goal and a blocked action, tries to find another route. Yenop is run with the runtime's own sandbox off, so nothing but Yenop stands in the way. Findings become fixtures.

And the boundary is stated: what is outside it is listed above, not discovered later.

What leaves your machine

By default, nothing. Decisions, policies, run state and receipts are local files. The daemon listens on 127.0.0.1 only and requires a token.

Telemetry is off until you turn it on. yenop telemetry enable sends the report's numbers once a day: counts by verdict, rule id, runtime and tool kind, the Yenop version, the operating system name and major version, which runtimes are hooked, and a random install id you can reset. Never a command, a path, a prompt, source, a hostname, a username, a project name, a receipt, or an MCP argument. The payload is built from an allow-list in the source, and yenop telemetry status prints exactly what would be sent.

Receipts are evidence. yenop receipts --verify checks the hash chain and exits non-zero on the first broken line. A third party can check it without trusting us.

Reporting a vulnerability

Write to security@yenop.com. Tell us what you found and how to reproduce it. We answer as soon as we see it, within one working day at most, and credit you in the fix unless you prefer otherwise. Please do not open a public issue for a bypass until it is fixed.