CirvixSecurity / Threat model

What this defends,
and what it does not.

One page. The assets, the four adversaries in the order the product is designed around them, the boundaries, and — at the same size and on the same page — everything deliberately outside the model. Silence in a threat model reads as coverage, so nothing here is left silent. Category overview: AI-agent security.

4adversaries, ranked
11,629attack cases, 0 false negatives
2adversarial reviews, published
0runtime dependencies
The boundary

Where the line is.

An agent's tool call crosses exactly one place before it reaches a model, a service, or a disk. Everything below is about what that layer can and cannot promise. The AI agent security page states each claim as an inspectable mechanism.

Cirvix trust boundary An agent's tool call passes from the untrusted agent process into the Cirvix decision path, where it is normalized, scanned for secrets, classified for risk, evaluated against policy and recorded, before reaching an upstream tool. Secret material is substituted inside the boundary and never returned to the agent. UNTRUSTED Agent process Controls every argument of every tool call. Assumed prompt-injected. Holds a handle, never a credential. CIRVIX — THE DECISION PATH 1  normalize 2  secret detection 3  risk classification 4  policy evaluation 5  approval check 6  handle substitution 7  audit append Secrets and risk resolve before policy, because a rule may test them. No rule matched = deny. Cannot record = deny. Quota exhausted = deny. UPSTREAM Tools & MCP servers Filesystem, shell, HTTP, databases, model APIs. Receives the real credential. The agent never did. call allow result redacted
The local runtime holds resolved secret material in process memory for the life of a request. Root on that machine is outside the model — see below.
OS Trapping vs. Userspace Proxy

Where controls bind: Kernel vs. Proxy level.

For enterprise security architects and CISO diligence, we clearly delineate between userspace proxy inspection and OS-level kernel trapping across operating systems.

Operating SystemKernel-Level Trapping MechanismProxy-Level Interception (UDS / stdio / MCP)Diligence Boundary
LinuxeBPF & LSM (sys_enter_execve, sys_enter_connect) + seccomp-bpfJSON-RPC over Unix Domain Socket; tool argument AST parsing and secret redaction.Kernel drops raw child forks, unauthorized network egress, and unsanctioned binary execution. Proxy provides semantic inspection.
macOSEndpointSecurity (ES) subsystem (ES_EVENT_TYPE_AUTH_EXEC, AUTH_OPEN)Stdio stream wrapping; MCP gateway proxy.Apple ES framework halts unauthorized execution synchronously at the kernel level. Proxy enforces LLM-specific guardrails.
WindowsWindows Filtering Platform (WFP) callouts + ETW / MinifilterNamed Pipe broker (\\.\pipe\cirvix-ipc); process wrapper.WFP blocks unbrokered TCP/UDP connections; Minifilter denies disk writes outside policy; proxy governs prompt arguments.
Assets

What is being protected.

AssetWhere it livesLoss looks like
The rule setpolicy_versionsAn agent does something nobody authorised
The decision recordaudit_records, decisionsNobody can prove what happened
Secret materialsecrets, sealedA credential reaches a model's context
Tenant boundaryevery org_id predicateOne customer reads another's fleet
Session and key materialsessions, api_keys, hashedImpersonation
Adversaries

Four, in the order
the product is built around them.

  1. A compromised, autonomous, or cyber-capable agent (including frontier models with autonomous vulnerability discovery like GPT-6 Astra). Holds an endpoint API key, controls the arguments of every tool call, or attempts novel exploit chains to cause unapproved external side effects. Capability is not authority. This is the adversary the product exists for.
  2. An authenticated principal of one tenant — member, admin, or a stolen API key — trying to exceed their role or reach another tenant.
  3. An unauthenticated network attacker with reachability to the control plane: brute force, replay, enumeration, denial of service.
  4. An insider with database read access. Cannot obtain a usable credential from it: keys, refresh tokens, invitation tokens and secret handles are stored hashed, and secret values are sealed under a key that is not in the database.
Out of scope

What this does not defend.

Stated at the same size as the rest, so nobody mistakes silence for coverage.

Root on the endpoint

The runtime holds resolved secret material in process memory for the life of a request. A machine compromised at root is outside any userspace product's threat model.

A malicious operator of the control plane

Someone who can edit the database and recompute the chain can rewrite history. The chain proves tampering to anyone who kept an earlier head — not to someone who did not.

Your identity provider

If a directory account is compromised, the approval authority attached to it is compromised. Cirvix does not replace an IdP.

Network egress policy

SSRF defences here raise the cost of the easy attack. A network that cannot route to 169.254.169.254 is the durable control, and that is yours to build.

The free tier's local counter

It lives in a file on the user's machine, and the engine is Apache 2.0, so modifying it is permitted. It is honour-system metering. Everything that cannot be faked locally is enforced server-side.

Prompt injection itself

Cirvix does not prevent an agent being injected. It constrains what an injected agent is able to do. The sanitiser is a mitigation; the policy engine is the control.

Known limits

Three things worth
knowing before you rely on it.

  1. A delegation grant has no server axis. It constrains actions and resources, so a grant for fs.read on ** works against any MCP server exposing a read tool. Confining an agent to one server is the resource glob's job, or policy's. Both the limit and its mitigation are asserted as tests, so the guidance is checkable rather than advisory.
  2. The agent label is self-asserted. _meta.cirvix.agent selects which agent-scoped rules apply and which handles resolve. It grants nothing, because nothing is granted by a name. In a hostile multi-agent deployment, rules keyed on agent identity need a signed grant behind them. Suitable for attribution, not authorisation.
  3. Grants are local to one runtime. The signing key is per-process, so two instances cannot verify each other's grants and a restart invalidates every outstanding delegation. That is the safe direction — a grant cannot outlive the process that could revoke it — and fleet-wide issuance is the control plane's job.

The full reviews, unedited

Two adversarial reviews are published in the repository, including the eight vulnerabilities the first one found and fixed, and the ones checked that turned out fine. Report anything new to the address in our security.txt.

Security architecture
Copied to clipboard