Architecture
Six layers, one direction
Each layer has a single job and a defined output. That matters more than it sounds: it is what allows a finding to be traced from an executive number back to the scanner that reported it, and forward from a scanner to the person who will fix it.
Scanners, cloud providers, identity systems, endpoint tooling, ticketing and GRC. Read-only credentials, scoped per connector.
→ raw findings, assets, configuration, in each vendor's own shapeScheduled pulls and webhook receipt, with per-connector rate limiting so a sync never becomes a denial of service against your own tooling. Failures are recorded per connector rather than silently retried, because a connector that has been dead for six days is itself a finding.
→ raw records, with provenance and a timestampOne schema, one severity vocabulary, one identifier convention. What one tool calls a host and another calls an instance become the same entity type before anything downstream tries to reason about them.
→ typed findings and assets in a common shapeDuplicate collapse, asset resolution, ownership inheritance and control association. This is the layer the rest of the platform exists to serve — described in detail below.
→ distinct findings, each joined to an asset, service and ownerComposite scoring from exposure, exploitation activity, business criticality and verified control state. Every score carries its factors, so a rank can be challenged specifically rather than in general.
→ a ranked, explainable queueOne model, three audiences: the engineer's queue, the executive score and framework evidence. They are the same data asked different questions, which is why they cannot disagree.
→ console, API, scheduled digestsPrioritised work into Jira or ServiceNow with the reasoning attached, and closure flowing back so the two systems agree without reconciliation.
→ tickets, webhooks, exportsNo agent on your estate. Nothing is installed on the hosts being assessed. If Prak Knit is switched off, every tool it reads from carries on exactly as before — which is the test of whether a platform is a layer or a lock-in.
Data model
Eight entities, and why each exists
A model is only as useful as the questions it can answer without a join nobody anticipated. These are the entities, and the reason each one is separate rather than a column on another.
One distinct problem, after duplicates from multiple tools have collapsed. Carries every source that reported it, so provenance survives deduplication.
A host, repository, container image, bucket, endpoint, model or agent. Technical, replaceable, often short-lived.
What the asset is part of. The stable unit that survives an asset being rebuilt on Tuesday — which is why findings map here and not to hosts.
What a customer would notice failing. Carries criticality and data classification, and is the vocabulary a board conversation actually uses.
A named individual with the authority to approve the change, not a team alias inherited from a past reorganisation.
A WAF rule, a network segment, an authentication requirement — with its live state and the date it was last verified. An unverified control counts for nothing.
Attack paths already reasoned about at design time, so a finding can be recognised as a predicted path rather than a surprise.
The mapping from evidence to PCI-DSS, ISO 27001, SOC 2 and the rest — one fact, many frameworks, rather than four parallel registers.
The two highlighted entities are the ones most estates lack, and their absence is what makes everything above them guesswork. A finding that cannot reach an application and a business service cannot be prioritised, owned or evidenced — only counted.
Correlation engine
Four decisions, made consistently
Findings are grouped by rule identity and asset, not by title text, which differs between vendors describing the same weakness. Every original report stays attached to the surviving finding, so "four tools agree" remains visible rather than being lost in the merge. Typical collapse on first ingestion is 25–60%.
The same machine appears as an IP to one tool, a hostname to another and a cloud resource identifier to a third. Resolution walks identifiers in preference order — cloud resource ID, then stable hostname, then network address, which is the least reliable because it is reassigned. Unresolved assets are surfaced, never silently merged: a wrong merge is far more damaging than an unmatched record.
Assets inherit ownership from the application they belong to, applications from the business service. Where a mapping is missing, the finding is flagged as unmapped rather than assigned to a default team — an unmapped finding is a fact about your programme, and hiding it removes the pressure to fix it.
When two sources disagree — different severities, different asset attribution, one says patched and the other does not — the disagreement is recorded and surfaced rather than resolved by picking the higher number. Conflicting sources are usually a sign that one connector is stale, and that is worth knowing.
Scoring sits on top of this and is described in full, with the arithmetic, in whitepaper 02. The deep version of everything on this page — identity resolution ordering, the deduplication key, multi-tenant isolation under a connection pool, and the design mistakes we made — is whitepaper 03.
Integrations
Read from these, write to those
Connectors implemented today. Each uses read-only credentials scoped to the minimum the connector needs, and each reports its own health, so a silent failure becomes visible rather than becoming a gap in your risk picture.
Anything not on this list can be ingested through the API in the same normalised shape, which is also how customers bring in internally-built scanners and penetration test results.
Deployment
Four options, and what genuinely changes
Most vendors list deployment models without saying what you give up. These are the real trade-offs.
SaaS
We run it. Fastest to value, and the only model where you get fixes the day they ship.
- Your data
- Held in our environment, isolated per tenant
- Connectors
- Must be reachable from our network, or via an outbound-only collector
- Updates
- Continuous
Private cloud
Your cloud account, your region, our deployment. Common where residency is a contractual requirement rather than a preference.
- Your data
- Never leaves your account
- Connectors
- Reach your estate directly, usually without new network paths
- Updates
- On a schedule you approve
On-premise
Your data centre, your operators. Requires you to run PostgreSQL and a container platform, and to own backup and restore.
- Your data
- Entirely yours, including backups
- Connectors
- Direct
- Updates
- You choose when; you also carry the cost of being behind
Air-gapped
No outbound connectivity at all. Honest about the consequence: threat intelligence — KEV, EPSS, CVE data — must be side-loaded, so it is as current as your last transfer.
- Your data
- Never crosses the boundary
- Connectors
- Internal only
- Updates
- Offline bundles
Security architecture
A security product should survive its own assessment
You are being asked to give a platform read access to every finding in your estate. These are the controls that make that defensible, stated specifically enough to be verified in a security review.
Tenant separation uses PostgreSQL row-level security with policies forced on every tenant-scoped table, and the application connects as a role that cannot bypass them. Application-layer filtering is one missed WHERE clause away from a cross-tenant leak; a policy is not.
API credentials carry scopes, checked in one place rather than per route, so a route added next month is covered by default. Keys expire, and rotation issues a successor with an overlap window so credentials can be replaced without an outage.
Who did what, to which tenant, when. Update, delete and truncate are rejected at the database layer — a log the application can edit is not evidence.
Your data is never used to train models and never shared. Erasure removes every row across every tenant-scoped table and issues a certificate with per-table counts, because "we deleted your data" is an assurance and a row count is evidence.
Backups are encrypted with a public key held on the backup host, so that host can write backups it cannot read. Restores are rehearsed on a schedule against real backups — an untested backup is a hypothesis.
A production instance validates its own configuration at startup and exits rather than running with authentication disabled, a default credential, or a database role that could bypass tenant isolation.
Deployment-specific detail — network paths, credential scopes per connector, residency — is covered in the security documentation, and we will complete your security questionnaire before a demo rather than after.
Bring your architects.
This is the conversation we prefer.
We would rather be challenged on the data model than demo dashboards.