Security

The security model, in full.

This page is written for the person who has to sign off on Cirvix before it touches production — architecture, what is and isn’t stored, and where the boundaries genuinely are. Not a badge wall.

Architecture

The boundary sits outside the model

An agent that can call tools can be induced to call them by anyone whose text reaches its context — a README, a ticket comment, a page it fetched. A model cannot reliably tell instructions from data, so the authorization boundary can't live inside it.

Intercept

Cirvix sits inline between the agent and every tool it can reach — as a local proxy, an SDK middleware, or a gateway in front of MCP servers. A call cannot bypass evaluation by being fast or by being ordinary.

Evaluate

The call is parsed into a canonical form and evaluated against the rule set: agent identity, action, resource, environment, and session state. Forbid always wins, a hold outranks a permit, and anything unmatched is denied. The evaluator is the same code in local dev, CI, and production.

Decide and record

The call is permitted, denied, or held for a human — and the decision, not just the outcome, is written to the append-only audit log before the agent ever sees the result.

Threat model

What Cirvix defends against — and what it doesn't

Both halves matter. A control plane that only publishes the first list is not one you can build an audit finding around.

Defends against

An agent calling a tool it was never authorized to call — every call is evaluated against policy before any side effect occurs.
Secret material reaching a model's context — agents receive an opaque handle; the real value is substituted at the network boundary, after policy authorizes that destination.
Delegated authority quietly growing — in an agent-to-agent chain, scope can only narrow, never be regained by going one hop deeper.
An MCP server silently changing what a tool does — tool definitions are pinned on approval, and drift is held for review rather than taking effect.
Undetected tampering of the decision record — the audit log is append-only and hash-chained; altering a past entry breaks verification from that point forward.
Calls to unauthorized network destinations — egress is matched against an allowlist at resolved-IP level, so a hostname that resolves into an internal range fails closed.

Does not defend against

A model reasoning badly inside the access it was actually granted. Cirvix narrows what a compromised agent's reasoning can reach; it does not make the reasoning trustworthy.
Prompt injection as a phenomenon. Injection scoring on natural-language content is probabilistic signal that can raise an approval requirement — it is never the sole control protecting a sensitive resource.
A call made outside an instrumented surface. A subprocess an agent spawns outside a wrapped runtime is outside enforcement until that surface is instrumented too — which is what the free scanner is for.
Compromise of your identity provider. Cirvix federates approvers and roles from the IdP you run; it does not replace it, and a compromised directory account compromises its approval authority with it.
Root-level compromise of the machine a broker runs on. On a developer laptop the broker holds resolved secret material in process memory for the life of a request — that is outside any userspace product's threat model, and we will not claim otherwise.
A permissive policy you wrote yourself. The engine enforces the rules it is given; policy quality is the customer's responsibility, and an overly broad rule will be honoured exactly as written.

Data handling

What Cirvix stores — and what it never sees

Stored

Decision records — agent, owner, action, resource, policy, verdict, approver, and timestamp for every authorized call.
Resolved tool-call arguments and results, as needed to reconstruct a run in the execution graph and the audit trail.
Agent identity documents, policy definitions and their revision history, and the MCP tool registry.
Account, workspace, and billing metadata once billing exists.

Never stored

Secret values. An agent is issued a handle (sec_handle_…); the credential itself is substituted at the boundary by the broker and is recorded in the trace as a handle, never as a value.
Raw model prompts or completions beyond what a specific tool call required — Cirvix instruments the call path, not a general prompt log.
Any data Cirvix was never sent. Deployments that never route a workload through Cirvix have nothing recorded, which is the gap `cirvix scan` reports.

What the agent sees vs. what the API receives

The clearest way to see the boundary is the secrets path — the agent only ever holds a handle; the credential itself never enters its context or the trace.

agent →  Authorization: Bearer sec_handle_a89f                         opaque; useless off-path cirvix → resolve sec_handle_a89f → substitute real credentialtrace  → records the handle, never the value

Tenancy

Isolation by deployment

Multi-tenant SaaS workspaces are logically isolated — no query, policy evaluation, or audit record crosses a workspace boundary. Enterprise customers who need physical separation run single-tenant VPC or on-premise, covered on the Enterprise page.

Encryption

In transit and at rest

All traffic between an agent, Cirvix, and the destination tool is encrypted in transit. Data at rest — the audit log, policy store, and configuration — is encrypted using the underlying cloud provider's storage-layer encryption.

Identity

Short-lived, attested credentials

Agent credentials are short-lived and attested to the workload, not copied into a long-lived environment variable. Attestation strength depends on the platform underneath it — the console labels a laptop-bound key differently from a hardware-rooted one in a managed cluster.

Vulnerability disclosure

Report it directly

Email umang@cirvix.com or use the contact published at /.well-known/security.txt. We will acknowledge a report, investigate, and tell you what we found — including when the answer is that it wasn’t exploitable.

Subprocessors

Who else touches the data

Cirvix is founder-led and in private beta; the production subprocessor list is not yet final. What's committed is the policy it will follow once it is.

A current, named subprocessor list will be published here and kept current before general availability — not after.
Categories in use are limited to cloud infrastructure and hosting, error and log aggregation, and transactional email — never a fourth category without disclosure.
The Data Processing Agreement — see the DPA — commits to advance notice before any new subprocessor is added for a customer under contract.

Compliance

The roadmap, stated honestly

An infrastructure buyer who catches one overstated claim discards the whole technical narrative — so here is exactly where Cirvix stands, not where it would be convenient to stand.

SOC 2 Type II: not yet audited; planned. No audit has been performed, and nothing on this site implies one has. It is planned once the platform is generally available — this page changes when that’s true, and not before.

ISO 27001: not certified. The EU AI Act’s logging expectations: not attested. What exists today is an audit trail built to export in shapes that map to all three — SOC 2, ISO 27001, and the EU AI Act — because the underlying record (hash-chained, decision-level, independently verifiable) is the same evidence any of those frameworks would ask for. Cirvix produces evidence; an auditor reaches the conclusion. No export changes what has actually been certified.