SECURITY
Security, and what happens to your data.
What the billing audit does with your files, how Novarch runs when you use it every day, what reaches the model, who can sign in, and an honest table of what is done and what is not.
YOUR DATA IN THE BILLING AUDIT
Your files, during the free audit.
Nothing is installed and nothing in your systems changes. These are the terms the files are handled under. The NDA carries the full version, including where files are stored and which providers process them.
- Before
- An NDA is signed before anything moves. Yours or ours.
- Transfer
- A private, encrypted folder we create for you, or read-only access you grant and can revoke. Never an email attachment.
- Access
- The two founders, plus the storage and processing providers named in the NDA. Nobody else.
- Use
- Your audit and nothing else. Never used to train anything, by us or by any provider we use.
- Deletion
- Deleted within 30 days of delivering the report, or sooner if you ask, and confirmed in writing.
- Ownership
- The report is yours to keep, whether or not we ever speak again.
DEPLOYMENT
Two ways to run it.
Novarch runs as a single-tenant instance we operate for you, or inside your own environment. The product is the same either way.
HOSTED
Run by us.
Each customer gets its own Novarch instance, with its own app and its own database, never shared with another customer. We handle upgrades and keep it running.
- Its own database, never shared
- Region set per instance (US today)
- HTTPS only
- Its own SDK key
Where data lives: your instance, with our hosting provider, in your instance's region. Model calls go to Anthropic's API.
SELF-HOSTED
Run by you.
Installed inside your environment from a private Python package. It runs on your network, with your own Anthropic key, inside your compliance perimeter, and we never see your data.
- Private Python package
- Your Postgres or SQLite database
- Your own Anthropic API key
- No callbacks to us
Where data lives: in your infrastructure. The only data that leaves it is the model calls you allow to Anthropic, and the connections listed below that you turn on.
WHAT REACHES THE MODEL
What crosses the network.
No telemetry callbacks, no background sync and no vendor analytics. The one call Novarch makes on its own is to the model, and most checks never make it.
YOUR SYSTEMS AND AGENTS
Records arrive.
Read-only pulls or exports from your systems. An agent's actions come from the SDK.
›NOVARCH
Checks in code.
In our cloud or yours. Code settles most rules, and the result is stored with no model call.
›THE MODEL
Reviews the rest.
Only a rule code flags or cannot settle: three samples from Claude, and a larger Claude model breaks the tie when they disagree.
›YOUR TEAM
Decides.
Anything unsure goes to a person. Every decision is recorded.
- To the model
- Only when a check needs it: the rule, the evidence code gathered for it, and the records it applies to. For an agent, that is the session, meaning what it read, what came back and its stated reasoning, capped in length. Personal data inside those records reaches the model, and so does anything an agent passes as a tool argument, secrets included. Agent tool results you mark for redaction in the SDK are removed first. Novarch’s own credentials, environment variables and API keys are never sent.
- Policy ingestion
- The documents, transcripts and emails you give it are sent to the model to draft rules.
- Other connections
- Only if you turn them on: Microsoft Entra ID for sign-in, your SMTP server for notices, your webhook endpoints (signed, with private addresses refused unless you allow them) and an optional Slack alert.
ACCESS
Who can sign in, and what is logged.
- Single sign-on
- Microsoft Entra ID over OIDC. Remove someone's app-role assignment in your directory and their Novarch sessions end within 15 minutes by default.
- Named accounts
- Or an account for each person, with scrypt-hashed passwords, rate-limited sign-in and admin or operator roles. Nobody shares a login.
- Audit trail
- Every sign-in, invite, role change, single sign-on event and rule edit is logged with who did it, in tables that are only ever appended to.
- Secrets
- Sign-in secrets, refresh tokens, SMTP passwords and webhook secrets are encrypted in the database with a key you can rotate.
POSTURE ROADMAP
What's done. What's in motion. What's planned.
We're early, and we won't claim a compliance posture we haven't earned, so this table says where we actually are. If a row matters to your evaluation, ask us on a call.
THE RECORD
What every decision records.
The audit document is rendered from database rows, not written by an LLM. Where a model reviewed a check, its written reason is quoted as the model wrote it.
RECORDED
Per decision.
decision id · rules served, with versions · rule cited · signals computed and cited · model version, or none when code settled it · prompt version · time. A person's decision is recorded beside it: who, what and when.
RE-TESTING
Re-run on stored records.
Any decision can be re-run against its stored session, which can include actions that came after it. Checks settled in code give the same answer on the same records. Model reviews are sampled, so a re-run of one can differ.
EXPORT
A period, with its custody.
Export a period's decisions, sign-in events and rule history as JSON, or as CSV in a ZIP with a manifest and SHA-256 digests. Every export is itself logged. Self-hosted: read your database directly.
Have a specific security question?
If a row above matters for your evaluation, ask us directly. We'd rather walk you through where we are than have you guess from a marketing page.