nittim Enterprise runs the whole audit inside your AWS account — your code has nowhere else to go.
In your VPC
Your code stays put
A component you run fetches the repo — including GitHub Enterprise on your network — and runs the deterministic evidence layer. Verify its full source: no audit logic in it.
Sealed, in your account
The analysis happens in-house
nittim's audit engine runs sealed, inside your account: takes the input, returns the report, keeps nothing. The sealed image ships today; attestation is on the roadmap.
Your model bill
Claude, via Bedrock, in your account
Model calls run through AWS Bedrock in your own account — nittim never proxies your code, and you pay AWS directly for model usage, at cost.
What nittim never sees
nittim never sees your code, findings, or reports — not even that an audit ran. Billing runs on signed usage receipts you export: counts and salted hashes, no repo names, no telemetry leaving your account. The audit engine is the licensed asset, sealed by packaging and license, not promise. The kit's boundary contract spells out exactly what crosses, both ways.
The management plane is already here
Enterprise deployments share the hosted product's organization layer: SSO, per-org isolation, an append-only audit log, and policy-as-code via a config file your repos already carry. Self-hosted deployments read .fis.yml; the hosted nittim audit path also reads .nittim.yml. Either way, CI's verdict gate enforces your policy.
Evaluate it properly
The kit gives you the code-touching component's full source, boundary contract, deployment topology, and architecture brief — what your platform and security teams need before you talk to us.
Downloads tie to your account, and nittim follows up personally — the whole funnel. Now in the design-partner phase: annual license, scoped per organization.
How accurate are the audits? The benchmark — corpus, method, every caveat — is public: see the numbers.