Security architecture,
by principle.

The principles SecurityVault is built on — how untrusted work is contained, how results enter the platform, how tenants stay apart, how decisions stay provable and what happens when something fails. The detailed design is available to customers and auditors under NDA.

Book a deep-dive View the platform

Platform credentials in a scanner

Scanners are treated as hostile and never hold platform secrets.

Authenticated path for results

Scanner results enter through an authenticated, verified ingestion boundary.

Every

Request tenant-scoped

Each request is bound to the acting organisation before it runs.

AI writes to verdicts

AI is advisory. Dispositions are made by people, on the record.

Separation of planes

Trusted control, untrusted work, protected data.

The platform is divided into zones with different levels of trust. Work that touches untrusted code never runs alongside the services that hold your data.

Control plane · trusted

APIauthenticated · validated

IdentitySSO · MFA · RBAC

Orchestrationschedules, never executes

Policy enginedeterministic · fail closed

AI assistanceadvisory only

Scan zone · untrusted

Executionisolated · ephemeral

Credentialsscoped to one target

Networkrestricted by default

Resultssigned · one way out

Data · protected

Recordstenant-isolated

Secretsencrypted · managed keys

Auditappend-only · tamper-evident

Artifactssigned · verified

Isolation of load

Read, write, ingestion and streaming traffic scale independently, reducing contention between scan processing and interactive console use.

Isolation of domains

Work is partitioned by security domain — code, cloud, supply chain, data, discovery, governance and more — so a backlog in one area stays in that area.

Live views

Changes publish versioned events that keep every entity-centric screen current without polling.

Untrusted work

We assume the scanner is compromised.

Scanners parse attacker-controlled input. We design as if one is already hostile, and enforce that assumption in infrastructure — not in policy documents.

Isolated execution

Every scan runs in its own short-lived, isolated environment that is destroyed when the scan ends. Accepted findings and evidence are retained by the platform.

Separated credentials

The credential that reads your repository and the credential that reports results are never held by the same component. A scanner reaches the target it was given and nothing more.

One way out

Results leave the scan zone only through an authenticated, signed channel that is verified before scanner findings are processed.

Never in a scanner

Database access, platform secrets, service tokens or any credential that could reach another tenant. Automated checks on every change refuse code that would break this.

Our own engines

SecurityVault's native analysis engines are held to exactly the same rules as third-party scanners. There is no privileged shortcut; if an engine breaks, scans fail closed.

Scan outcomes

No ambiguous end.

Every scan ends in an explicit, recorded outcome that says what happened — not just that something did.

Requested

recorded

Running

results arrive

Completed

Partial

Failed, with a reason

Partial is honest

If one tool fails, results from the others are kept and the gap is shown — a scan never reports clean because a tool silently didn't run.

Failures explain themselves

Time-outs, missing credentials and configuration errors are distinguished, with a hint your team can act on.

Ingestion

The only door into your data.

Results are verified, then attributed to the tenant that owns the scan. Nothing a scanner says about its own tenant is trusted.

Single-use authority

Each scan is issued a short-lived, single-use credential bound to that scan alone.

Signed and replay-proof

Every result is signed and protected against replay. If verification cannot be completed, the result is refused rather than accepted on trust.

Durable once accepted

Accepted results are stored durably before processing, so a restart cannot lose what was delivered.

Tenancy

Every query scoped to its tenant, tested on every change.

Every query is scoped to the tenant that owns the data, and the isolation guarantees are tested automatically before any release.

Bound sessions

Every request is bound to the authenticated organisation before its first query.

Identity is the authority

The tenant is taken from the verified session, never from a value a caller can set.

Scoped reads

Every read, update or delete of a resource is checked against the owning organisation. Cross-tenant access is treated as a release-blocking defect.

Signed API requests

API keys sign every request, binding the method, path, time and body, so a captured request cannot be altered or replayed later.

Human-only verdicts

Verdicts on findings can only be changed by an authenticated person — enforced in the application and again in storage.

Verified upgrades

Schema changes are forward-only and integrity-checked; upgrades are proven to match a fresh installation before a release ships.

Evidence pipeline

From a tool result to a lineage view.

Raw results become entities, relationships, findings, cases, attack paths and risk scores through a versioned pipeline. Results depend on the evidence, rule versions and configuration used; reviewers can inspect the supporting context.

Observation

validated

Entities & edges

provenance-tagged

Finding

correlated

Case

attack path

Risk

Provenance

Every relationship records how it was established. Lineage from repository to running workload is built only from observed and derived evidence; guesses are shown as candidates and never complete a path.

No fabrication

Missing or conflicting links are shown as such. Candidate relationships remain distinguishable from observed or deterministically derived evidence.

Correlation

Correlation rules are proven in shadow mode before they are allowed to open cases.

Explainable risk

Every risk score is versioned and comes with the factors that produced it.

Cryptography

Standard primitives. No invented protocols.

Industry-standard, peer-reviewed cryptography throughout. Algorithm and key-management detail is available to customers and auditors under NDA.

Where	Protection
Sessions	Short-lived signed tokens with key rotation; refresh handled out of reach of page scripts.
Stored credentials	Encrypted at rest; decrypted only at the moment a scan needs them.
Control decisions	Digitally signed and tied to a hash of exactly what was evaluated, verifiable by your auditors.
Audit log	Append-only and hash-chained, so tampering is evident.
Webhooks & results	Signed and protected against replay.
Software supply chain	Platform images are signed and verified before they run.
Transport	Data is encrypted in transit with TLS, both over public networks and between our internal services.

Identity & access

Your IdP. Least-privilege RBAC.

Authentication

OIDC and SAML single sign-on, MFA, and an outbound SCIM 2.0 push connector. Okta, Microsoft Entra ID, Google Workspace and CyberArk connectors ship in the platform. Inbound SCIM provisioning (an IdP creating users in SecurityVault) is in development. Discuss rollout with our team.

Authorisation

Permission bindings are the access authority. Personas — developer, AppSec, cloud, SOC, GRC, executive and more — only shape the home view; they never grant access.

Governance writes

Risk dispositions require an authorised person and a reason code. AI cannot make them. Separate lifecycle automation can record scope-specific scan outcomes while preserving human-held decisions.

CI principals

Pipelines authenticate with OIDC workload identity; gate results and pull-request comments are posted under a dedicated, rate-limited CI principal.

Dual control

Sensitive governance actions require a second approver; approval scope is checked at the action, not at login.

Audited prompts

Every natural-language query to the AI is audited, accepted or rejected. Invalid model output fails immediately and is never retried.

Resilience

When something fails, it fails safe.

Contained by design

Per-tool deadlines and isolated scan environments limit the impact of a failing scanner and preserve results from tools that completed.

Deny on doubt

If a policy cannot be evaluated or a signature cannot be verified, the answer is a deny with an explicit reason. There is no silent allow.

Durable processing

Accepted results are stored before downstream processing. Retry and recovery mechanisms support processing after a service restart.

Recoverable data

Replicated storage with point-in-time recovery.

Graceful identity

An existing valid session can continue during a brief IdP outage, subject to token expiry and session policy. New sign-ins may be affected.

Stateless services

Application services hold no state of their own and can be replaced at any time.

Engineering discipline

Observable by default. Gated on every merge.

Telemetry

Structured logs, metrics and distributed tracing across the platform, with central retention per environment.

Merge gates

Automated architectural and security invariants run on every change — tenant isolation, input validation, secret handling, accessibility and more. A failing gate blocks the merge.

Test layers

Unit, property, integration and end-to-end suites against the production build; schema proofs on fresh and upgraded databases.

We scan ourselves

The platform scans its own code and images on the same pipeline it sells, and findings are burned down on the record.

Supply chain

Images are built rootless, signed and verified; dependency updates pass the same gates as any other change.

Least-privilege networking

Network access between components is explicitly allowed, never assumed.

FAQ

The questions your architect will ask.

Where is my data held?: The hosted service runs in India and is isolated per tenant. Data is encrypted in transit with TLS, both over public networks and between our internal services, and encrypted at rest. Self-hosted deployments place storage under your control; outbound integrations depend on your configuration. Third-party processing locations are listed on the subprocessor list; the trust centre summarises how data is handled.
Can a scanner write to my data?: No. Scanners hold no database access or platform credentials. Results reach the platform only through the authenticated, signed ingestion path.
What happens if the policy engine is down?: Every evaluation error is a deny with an explicit reason code. There is no path that returns an allow without a successful evaluation.
Can AI change a finding disposition?: No. AI triage, remediation suggestions and natural-language filters are advisory. Governance fields cannot be changed by AI or automation.
How do you prove a finding really came from that commit?: Lineage links carry a provenance class. A link established by a verified attestation or workload identity is observed; a link by an exact commit or digest match is derived; a tag or label match is inferred and never completes a strict path. The view shows how each hop was established.
Can scanning run in our environment while you host the platform?: In development: registered execution environments in your own cloud, approved by your admin, reporting results outbound only. Today scanning runs in SecurityVault's isolated environment, or in a fully self-hosted deployment on request.
Can I run it entirely inside my own environment?: On request — a hands-on setup with us on your Kubernetes using the same signed images. No telemetry leaves unless you configure it to. Full requirements are shared under NDA.
Can we see the detailed design?: Yes. Customers and prospective customers under NDA can review the detailed architecture, threat model and control mapping with our engineers.

Architecture deep-dive

Review the architecture with us.

Discuss trust boundaries, deployment requirements and evidence with our engineers. Detailed implementation material is shared under NDA.

Book the deep-dive Read the docs