Threat Model

Last updated: 2026-06-01

What this document is. A short, public summary of how we think about the threats Nomatica AI faces, the controls we apply, and the residual risk we accept. The full internal threat model (with specific bypass attempts, fine-grained controls, and internal audit findings) is not published.

System overview

Nomatica AI is a multi-tenant SaaS platform with the following high-level components:

All public endpoints terminate TLS at the edge. All inter-service traffic is mTLS or signed JWT. All data at rest is encrypted by the underlying cloud provider.

Adversary classes

#	Adversary	Capability	Motivation
A1	Curious end user	Low	"Just exploring"
A2	Credential thief	Medium	Account takeover
A3	Bug bounty researcher	High	Reputation, bounty
A4	Opportunistic scanner	Medium	Worm-able vulnerabilities
A5	Determined attacker	High	Targeted account, IP theft, fraud
A6	Insider (employee)	High	Curious or malicious
A7	Supply-chain attacker	High	Compromise a dependency or build
A8	Nation-state	Very high	Strategic intelligence

Top threats (in priority order)

1. Account takeover via credential stuffing or phishing (A2, A4)

Risk: An attacker acquires a list of credentials from a third-party breach and tries them against Nomatica login flows.

Controls:

• Mandatory MFA for all new accounts (TOTP, WebAuthn/passkeys)
• Rate-limited login endpoint with exponential backoff after 5 failed attempts
• Credential-stuffing detection (request fingerprinting, JA4/JA3 matching against known-bad client profiles)
• Breached-password check (k-anonymity API) at signup and on password change
• Email + push notification on every new-device login
• Step-up auth for sensitive actions (payments, key rotation)

Residual risk: A targeted, slow, distributed stuffing attack from a botnet of residential proxies may evade rate limiting. We mitigate with CAPTCHA challenges when risk scoring crosses a threshold.

2. Cross-tenant data leakage (A5, A6)

Risk: A vulnerability in authorization logic allows one tenant to read another tenant's data.

Controls:

• All data access goes through a centralized authorization layer that takes (subject, action, resource) and returns a boolean. Application code never rolls its own checks.
• Postgres Row-Level Security (RLS) policies are enabled for all multi-tenant tables; queries without an explicit tenant_id filter cannot return rows for other tenants.
• Database accounts are per-service; the API service cannot, for example, read from the audit log table directly.
• Penetration tests twice a year focus on authorization logic
• A canary tenant exists in production with synthetic, decoy data; any cross-tenant read trips an alert within 60 seconds

Residual risk: Authorization bugs in business logic remain the single largest category of vulnerability we find. We accept that risk and invest heavily in code review, automated tests, and penetration tests to keep the rate of regression near zero.

3. Prompt injection and indirect prompt injection (A4, A5)

Risk: A user (or content fetched on a user's behalf) contains instructions that override the system's prompt, leading to data exfiltration, jailbreaks, or unintended actions.

Controls:

• The system prompt is structured as a fixed, signed message that is not influenced by user input
• Tool calls go through a "policy firewall" that re-checks authorization on every call, independent of the model's stated intent
• The model is instructed to refuse to reveal its system prompt verbatim; we do not rely on this for security — it's defense in depth
• Indirect prompt injection: any tool result that contains untrusted text is wrapped in <untrusted>...</untrusted> tags and explicitly excluded from instruction-following
• Output is filtered for known PII patterns before being returned to the caller

Residual risk: Novel jailbreaks surface regularly. We monitor public research, run an internal red team, and have a fast patch cadence for the model-handling code.

4. Supply-chain compromise (A7)

Risk: An attacker compromises a dependency, a build tool, or a container image, allowing them to ship malicious code through our normal release process.

Controls:

• npm audit and pip-audit run on every PR; HIGH/CRITICAL CVEs block the merge
• Lockfiles are committed; CI verifies the resolved tree matches the lockfile exactly
• Production builds use pinned digests, not floating tags
• SBOM (SPDX 2.3) is generated for every release and archived
• Container images are scanned with Trivy in CI and signed with cosign; the cluster's admission controller requires a valid signature
• Production access requires hardware-backed MFA on every session
• The release pipeline runs on a dedicated, isolated account that can push but cannot modify production data

Residual risk: A sophisticated attacker who compromises a popular open-source library may briefly ship malicious code before detection. We accept this risk and invest in defense-in-depth at runtime (egress filtering, syscall allowlists, RASP) so a malicious dependency is contained.

5. Web application vulnerabilities (A3, A4, A5)

Risk: A bug in application code (XSS, SSRF, IDOR, deserialization, SQL injection, etc.) leads to data exposure or compromise.

Controls:

• Static analysis (CodeQL, Semgrep) on every PR
• Required code review by at least one engineer not the author
• Web application firewall at the edge for OWASP Top 10
• CSP with no unsafe-inline or unsafe-eval; nonces for any required inline code
• All user-supplied HTML is sanitized (DOMPurify) before rendering
• Output encoding is automatic and framework-enforced (React's default escaping, parameterized SQL via the ORM)
• Penetration tests twice a year and ad-hoc after any authentication-related change

Residual risk: Application-layer bugs are inevitable. We aim for a fast detect-and-patch loop: Sentry alerts within 60 seconds, hotfix process that takes a reviewed PR to production in under 30 minutes.

6. Denial of service and economic abuse (A4)

Risk: An attacker drives up our infrastructure costs (model inference, edge compute) or makes the platform unavailable.

Controls:

• Rate limiting per IP, per user, and per tenant
• Token-bucket fairness on the inference gateway
• Hard spending limits per tenant; an overage triggers an alert and an automatic pause of inference for that tenant
• Edge WAF rules block known-bad ASNs and request patterns
• A status page and external monitoring (Pingdom, RUM) catch customer-impacting outages within 60 seconds

Residual risk: A coordinated, distributed attack from a large botnet can still degrade service. We accept this risk and have a runbook to scale capacity and engage the upstream provider's DDoS-mitigation team.

7. Insider threat (A6)

Risk: An employee (or compromised employee account) accesses customer data, leaks it, or tampers with production systems.

Controls:

• Least-privilege access; employees get only the permissions their role requires, for the duration of the task
• Every access to customer data is logged to a tamper-evident audit log; alerts fire on anomalous patterns (e.g. a customer-success engineer querying data for a tenant they don't own)
• Background checks for all employees with production access
• Mandatory phishing-resistant MFA (WebAuthn) for all production access
• Production requires an interactive justification on every session ("I am investigating ticket #1234 for tenant foo")
• Periodic access reviews; access is automatically revoked on role change

Residual risk: A determined insider with legitimate access can still exfiltrate some data before detection. We accept this risk and focus on minimizing the blast radius of any single account.

Threats we explicitly do not defend against

• Physical access to our cloud provider's data centers (covered by the provider)
• Compromise of a major upstream provider (Cloudflare, model provider, payment processor) — we have runbooks but no in-house mitigation
• Nation-state attacks with zero-day capabilities against the underlying kernel or hypervisor — we rely on the cloud provider's mitigations
• Side-channel attacks against shared hardware — we run only on dedicated-tenancy or single-tenant hardware tiers

What we publish (and what we don't)

We publish:

• The high-level architecture (this site)
• The list of controls in this threat model
• The data classification scheme (in the trust center)
• The incident response process (in the security policy)

We deliberately do not publish:

• Specific rate-limit values
• Specific WAF rules
• Specific internal escalation paths
• Specific employee names or roles
• The full list of CVEs we've patched in the last 90 days
• Detailed audit findings, even after remediation

This is the standard tradeoff for a publicly documented security posture: enough to demonstrate rigor, not so much that an attacker gets a roadmap.

How this document changes

We re-review the threat model quarterly and after every material change (new data store, new third-party integration, new deployment region). Material changes are noted in the changelog with a brief summary.