Correlated, not duplicated
A leaked key found in code, seen live in cloud and observed being pasted in a browser is one finding with three sources. One severity, one owner, one closure.
Why SanCipher
One platform, built to a small number of rules.
Most security suites are four acquisitions wearing one logo. The seams show in the third month, when you discover each module keeps its own findings list and none of them agree. SanCipher was designed backwards from that failure.
The rules the product is held to
non-negotiable
Findings never fork
Every enforcement surface simulates first
Raw content stays inside your perimeter
Coverage shows the gap, not the flattering half
Evidence produced, certification never claimed
Architecture
Analysis moves to the data. Not the other way round.
The standard model asks you to copy your content into a vendor cloud so it can be inspected. That copy is a new liability with its own retention window, its own breach surface and its own data-flow review. We invert it: inference runs where the data already is, and only a finding record leaves.
- Browser sidecar. Local classification of paste, upload, download and form content, at the moment of the action.
- VPC scanner nodes. Cloud and code scanning on infrastructure you own, in the region you choose.
- Control plane. Holds findings, policy and audit — never raw content. Available as SaaS or self-hosted.
- Attestation on every record. Where analysis ran is a property of the finding, visible and exportable.
Your perimeter
Device · VPC
Raw content — documents, source, credentials, prompts
Classifier and model inference, running locally
Policy match, redaction, attestation
Finding record only — severity, rule, redacted context, attestation
The findings queue
Every module writes here. None of them keep a private list.
This is the rule that stops a platform degrading into a bundle. Modules surface findings in context, but the record lives in one queue with one resolution workflow.
Ranked by exploitability
Then by severity — in that order. A live credential outranks a theoretical critical every time, because one of them can be used this afternoon.
Verification that drains
Fixed items wait in a verification tab until a re-scan or a trace replay proves the fix landed. Nobody closes their own ticket on trust.
Accepted risk expires
Every exception carries an owner, a reason and a date. When the date passes the finding reopens automatically — no annual spreadsheet review required.
Routed, not triaged
Codeowner and tag mapping resolve ownership before the finding lands, so it arrives with a name on it rather than in a shared inbox.
Full evidence attached
Origin module, asset, reproduction, suggested fix, history and the linked ticket — all on the finding, not scattered across four consoles.
Automations
When this, do that — across every module.
Triggers come from any module and actions run across your integrations. Create a ticket, notify a channel, block a destination, revoke a credential, quarantine an extension, open a pull request, re-scan to verify. Every run is logged with its payload and outcome.
- Templates for the obvious cases. Live secret detected → revoke, rotate, notify owner, re-scan.
- Cross-module by default. A browser event can trigger a cloud action. Nothing is walled off.
- Every run auditable. Execution log with payload, outcome and who authorised the rule.
Rule · unsanctioned AI tool discovered
4 actions
Trigger · new tool in sanctioning queue
browser
Register as AI asset
ai
Notify #security-review
slack
Open a review ticket
jira
Integrations
It has to fit the stack you already run.
Identity, ticketing, SIEM, source control, chat, cloud and EDR — connected with health and last-sync visible, plus a full API, scoped keys and a webhook delivery log.
Identity
Okta, Entra ID, Google Workspace. SSO and SCIM, with role assignment scoped per module.
Ticketing
Jira, Linear, ServiceNow. Findings route with owner resolved, and close back on verification.
SIEM
Splunk, Sentinel, Chronicle. Finding records forwarded — never raw content.
Source control
GitHub, GitLab, Bitbucket, Azure DevOps. Org-level install with pipeline gates.
Chat
Slack and Teams, with severity routing so channels stay readable.
Cloud
AWS, Azure, GCP and Kubernetes. Read roles first, write only where you allow it.
EDR & MDM
Push the sidecar through the tooling you already use to reach devices.
API & webhooks
Scoped keys, webhook endpoints and a delivery log you can debug against.
Deployment
Where each component actually runs
This is a page in the product, not a line in a settings menu. If the in-perimeter claim matters, it deserves to be verifiable at a glance — with versions and health.
| Component | Runs where | Sees | Sends out |
|---|---|---|---|
| Browser sidecar | On the device, inside the browser | Paste, upload, download, form content | Finding record with redacted context |
| Cloud scanner node | In your VPC, region of your choice | Configuration, IAM, resource metadata | Findings and evidence artefacts |
| Code scanner | In your VPC or your CI runner | Source, dependencies, commit history | Findings with source-to-sink paths |
| Redtrace runner | In your VPC, against your endpoints | Agent exchanges and tool calls | Traces, redacted to your policy |
| Control plane | SaaS or self-hosted | Findings, policy, audit, users | Nothing — it is the destination |
Day one
Connect one cloud account with a read role and install the source-control app. Permission preview and dry run before any real scan.
Week one
Sidecar pushed through MDM to a pilot group. Discovery runs in observe mode — nothing is blocked until you decide it should be.
Month one
Policies simulated against real history, gates set to warn, and the first evidence pack exported for whoever asked for it.
Design discipline
Six rules that keep this from degrading
Every platform starts coherent. These are the constraints we hold the product to as it grows, written down so you can hold us to them too.
RULE 01
A section belongs to one module
If two modules need it, it becomes a shared pillar or a cross-link — never a duplicated menu item.
RULE 02
Findings never fork
Modules surface findings in context, but the record lives in the global queue with one resolution workflow.
RULE 03
Assets register inside their module
There is no global "add target" flow. That is what turns a clean product into a thirteen-item scan-target list.
RULE 04
Tabs are facets, sections are things
If a tab needs its own filters and its own primary action, it was always a section pretending to be a tab.
RULE 05
Settings holds configuration, not activity
Anything with a time axis belongs in a module or in the findings queue, where someone will actually see it.
RULE 06
Every enforcement surface simulates
Browser policies, pipeline gates and runtime guardrails all block real work. None of them ship without a dry run.
Bring your own environment.
Thirty minutes, one connected account, a real findings list at the end of it.
No credit card. No agent on the endpoint. Nothing leaves your network.