Threat model
What Cirvix assumes about the agents, models, and networks it governs, and where the boundary between Cirvix's responsibility and yours sits.
Assumptions
- A model can be induced to call a tool it shouldn't by any text that reaches its context — a README, a ticket, a web page, a PDF.
- A model cannot reliably distinguish instructions from data, so the boundary that decides whether a call happens has to exist outside the model.
- A workload can be legitimately compromised while every individual call it makes is, in isolation, something policy would permit.
In scope
- Authorizing whether a specific tool call may happen, on whose authority
- Controlling egress from a governed agent's process
- Preventing raw secret material from entering a model's context
- Bounding how far delegated authority can grow across a chain of agents
- Producing a tamper-evident record of what was decided
Out of scope
- Attacks on model weights or training data
- Whether a model's reasoning is correct, when that reasoning never produces a governed call
- Compromise of the host operating system underneath the broker itself
- Any call that bypasses an instrumented surface entirely
The boundary Cirvix draws
Cirvix authorizes actions; it does not make a model trustworthy. A compromised agent still produces compromised reasoning — what changes is the set of actions that reasoning can reach.
Compliance roadmap
Cirvix is in private beta. No SOC 2, ISO 27001, or FedRAMP audit has been completed. Audit exports are formatted to match what those control tests look for — see Audit chain — but that is not the same claim as certification, and this page will say so plainly until it changes.
Edit this page on GitHub
Was this page helpful?