Threat model

This is the threat model of the platform as it runs on 30/09/2026: one cell in us-east-2, with one k3s machine and one managed PostgreSQL. Every control points to the file or configuration that implements it in Niadra’s repositories (niadra-back, the server; niadra-infra, the cloud and the cluster; niadra-frontend, the site and the Console), which your security team can read under a non-disclosure agreement. The last section says what is left without a control, or with a partial one.

​

Assets

What the platform protects, from the most sensitive down:

​

Trust boundaries

Each row is a boundary that traffic crosses, who sits on each side and what crosses it.

​

Threats per component

For each component, the threat, the control that exists today and where it is. “Test” names the test that proves the control in the server’s CI, which runs on every pull request against a real PostgreSQL, PgBouncer, RabbitMQ and Redis (niadra-back/.github/workflows/ci.yml).

​

Public edge

​

Authentication and authorization

​

Database and isolation between customers

​

Keys and encryption

​

AI models

​

Outbound to customer endpoints

​

Audit

​

Logs and observability

​

Delivery chain

​

Availability

​

Residual risks

What this design does not cover today, said as it is.

1. One machine and one zone. The cell runs on one k3s machine and one RDS without Multi-AZ. Losing the machine or the zone takes the API and the Console down until the template rebuilds them (scripts/stack.sh and a deploy); losing the database comes back from the instance’s automated backup or from the previous night’s pg_dump. The rebuild time has not been measured. The path to two more machines and a Multi-AZ database is described in niadra-infra/README.md and is not deployed.
2. Plain traffic inside the node. Between the pods, the connection pooler, the cache and the queue the traffic is not encrypted; it does not leave the machine, and the network policy limits who reaches each process. TLS 1.3 starts at the edge and on the hop from the pooler to the database. Whoever has administrator access to the node sees that traffic.
3. Masked text leaves the region. Extraction and decisions go to OpenRouter and from there to OpenAI and TypeSafe, outside us-east-2, with zero retention requested on every call. Masking is by rules and by a detector; a value both miss travels as text. The decision provider publishes neither its own region nor its own retention period.
4. The instance backup holds everything together. RDS’s automated backup contains the cell database (with the wrapped keys) and the space databases; restoring the whole instance would bring a deleted space back, until the backup expires. That is why a space’s deletion receipt states when the last copy expires. Today the instance backup lasts one day (the account’s plan); the nightly per-database backups last 35 days.
5. Scanning covers code dependencies only. A known vulnerability in the dependencies blocks the merge (the questionnaire says how), but the system packages of the container images are not scanned, and the development dependencies of the TypeScript repositories do not block. An advisory published after the merge only shows up on the next audit run.
6. No penetration test and no certification of its own. The ISO 27001, SOC 2 and PCI DSS seals belong to the cloud Niadra runs on, not to Niadra. A penetration test by an independent firm is part of the Regulated plan’s contract.
7. One person on call. Alerts reach the founder; there is no on-call rota. The incident response plan says what that means for response times.
8. Operational access exists. Niadra’s operation reaches the machine through Systems Manager and the databases through the runbooks, to restore and delete spaces. That access is in the account’s CloudTrail and, when it touches a space, leaves an admin receipt; there is no second approver for it.

​

Next steps