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 shapeDuplicates consolidated, assets recognised across tools, owners and controls attached. This is the layer the rest of the platform exists to serve — what it delivers is described 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
Duplicate findings from different tools are consolidated into one record, with every source preserved — so "four tools agree" stays visible rather than being lost in the merge. Typical consolidation on first ingestion is 25–60%.
The same machine can look different to every tool that reports on it. Prak Knit recognises it as one asset, and anything it cannot match with confidence is surfaced for review rather than guessed at.
Every finding is tied to an application, a business service and an owner. Where that mapping is missing, the finding is flagged as unmapped rather than hidden in a default queue — an unmapped finding is a fact about your programme worth seeing.
When sources disagree — on severity, on the asset, on whether something is fixed — you see it, rather than having it quietly papered over. Conflicting sources are usually a sign that one connector is stale, and that is worth knowing.
Scoring sits on top of this. We walk through how it works in a technical session with your architects, under NDA.
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 outcomes that make that defensible. Architecture details are available under NDA for your security review.
Each customer's data is kept strictly separate from every other customer's, and that separation is tested on every release.
API credentials carry only the permissions they need and expire on a schedule, and rotation lets them be replaced without an outage.
Who did what, to which tenant, when — recorded in an audit trail that cannot be quietly rewritten after the fact, because a log that can be edited is not evidence.
Your data is never used to train models and never shared. Erasure on request comes with a certificate of what was removed, because "we deleted your data" is an assurance and a certificate is evidence.
Backups are encrypted, and restores are rehearsed on a schedule — an untested backup is a hypothesis.
A production instance checks its own configuration at startup and will not run in an unsafe state, such as with authentication disabled or a default credential.
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.