> For the complete documentation index, see [llms.txt](https://docs.hardpoint.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hardpoint.dev/threat-model.md). # Threat Model ## Purpose This document describes the trust boundaries, threat assumptions, and explicit non-goals that underpin Hardpoint's security architecture. It is intended for security engineers and compliance reviewers evaluating Hardpoint as a vendor, and for operators deploying Hardpoint in production. It does not describe implementation details, which are necessarily subject to change. The boundaries described here are invariant. *** ## Guiding Principle Hardpoint takes direct responsibility for the trust boundaries unique to multi-tenant isolation. Where industry-standard solutions exist for adjacent problems, we deliberately leverage them rather than reinventing them. Where no adequate solution exists, we build our own — and document the reasoning. Quantum resistance is a baseline requirement, not a feature. Any cryptographic mechanism\ introduced or updated within Hardpoint — whether for key encapsulation, signatures, or symmetric\ encryption — must meet a quantum-resistant standard. Algorithms that do not meet this bar are not\ adopted regardless of their conventional security standing. This applies to new mechanisms and\ governs the evaluation of any future changes to existing ones. *** ## System Boundary Hardpoint operates as a control plane and connection proxy for multi-tenant data infrastructure. All data plane traffic passes through Hardpoint routing infrastructure. No direct access to underlying data stores is granted to application code, tenants, or operators outside of Hardpoint-managed paths. *** ## Trusted Components Compromise of any of the following represents a significant security event with potential cross-tenant impact: **Hardpoint Control Plane API** The authoritative source of routing decisions, tenant configuration, and admission policy. Authenticated by all other components the same way any external caller would be — no implicit trust is granted by virtue of being Hardpoint-operated infrastructure. **Configured Ingress Identity Providers** The JWK/OIDC infrastructure of identity providers explicitly configured per deployment. These providers are trusted to issue verifiable credentials for ingress traffic. The trust relationship is established at configuration time and is not runtime-modifiable without control plane authentication. The specific mechanism for ingress identity verification (currently OIDC/JWKS) may evolve; the principle of predefined, explicitly trusted identity providers does not. **Cloud Provider Infrastructure** Hardpoint operates on infrastructure provided by hyperscale cloud vendors (currently AWS) and selected European providers. Side-channel attacks originating from the cloud provider layer are explicitly out of scope. *** ## Untrusted Components The following are verified, never assumed. A compromise of any of these components does not grant access to tenant data or the ability to forge authorisation decisions. **Incoming Traffic** All ingress traffic is treated as untrusted until verified against a configured identity provider. Verification is cryptographic. No traffic is admitted to the mesh on the basis of network provenance alone. **The Relay Mesh** Relay infrastructure is Hardpoint-operated but explicitly untrusted. Relays perform blind forwarding only. They cannot inspect tunnel content because end-to-end encryption is negotiated between the SDK and the destination agent using [ML-KEM](https://en.wikipedia.org/wiki/ML-KEM) (post-quantum key encapsulation), with session keys that are ephemeral and unique per request per service path. A compromised relay cannot decrypt traffic in transit, cannot forge authorisation decisions, and cannot impersonate the control plane. The relay's role is limited to forwarding a tuple of: verified ingress credential and API routing decision. The downstream agent independently verifies the legitimacy of this tuple via blind signature before admitting the connection. The relay cannot construct a valid tuple without a legitimate prior authorisation from the control plane. **Agents Seeking Mesh Admission** Agents must authenticate to the control plane via asymmetric cryptography before admission. Network presence alone — including presence within a peered VPC — does not grant mesh admission. *** ## Traffic Separation Relay infrastructure is provisioned per Hardpoint customer (not per tenant). Tenant separation within a customer's deployment is enforced at the agent and data layer, not at the relay layer. **Internet-facing deployments** (e.g. Vercel, Fly.io): relay is publicly reachable, protected by Cloudflare. TLS terminates at the Cloudflare edge; the ML-KEM tunnel between SDK and agent traverses the relay opaquely regardless of where TLS terminates. Traffic separation is cryptographic, not solely topological. **Private cloud deployments** (e.g. AWS): relay can be deployed within a VPC and accessed exclusively via VPC peering, never traversing the public internet. The "traffic terminates at a load balancer" objection: this is true at the network layer and irrelevant to the security model. The content of that traffic is opaque to the relay by cryptographic construction, not by policy alone. *** ## Network Isolation Hardpoint guarantees tenant network isolation as a policy enforced at the Hardpoint layer. The specific network primitives used to implement that guarantee vary by cloud provider and deployment model; the guarantee itself does not. Each Hardpoint customer is provisioned a dedicated network boundary — a VPC on AWS, or an equivalent construct on other supported providers. Tenants within that customer's deployment are isolated from each other within that boundary. No cross-tenant traffic is permitted without passing through Hardpoint's policy and authentication layer, regardless of network topology. Network-layer controls (subnets, security groups, firewall rules) are applied as a defence-in- depth measure and are provisioned and managed by Hardpoint's control plane. They are not the primary isolation mechanism. The primary isolation mechanism is Hardpoint's proxy and authentication layer, which enforces tenant boundaries cryptographically and independently of network topology. This means the isolation guarantee is portable across cloud providers. Customers do not need to understand or audit the network topology of the underlying infrastructure — the guarantee is stated at the Hardpoint layer and holds regardless of what primitives implement it beneath. **What this means in practice** * A tenant cannot reach another tenant's data store, directly or indirectly, through any network path — regardless of whether they share a VPC. * Network presence within a customer's VPC does not grant any access to Hardpoint-managed resources. Admission requires cryptographic authentication to the control plane. * Hardpoint does not provision separate cloud accounts or VPCs per tenant. The isolation boundary is enforced at the Hardpoint layer, not the cloud account layer. Customers requiring dedicated cloud accounts for regulatory reasons should discuss this with Hardpoint directly. *** ## Credential Model Hardpoint enforces a no-static-credentials guarantee within the platform trust boundary. Application code and tenant workloads connect via Hardpoint's zero-trust connection layer using short-lived, cryptographically verified identities. No passwords, connection strings, or static secrets are exposed to application code at any layer. At the infrastructure layer, data store credentials necessarily exist. These are managed exclusively by Hardpoint's control plane. Infrastructure credentials are rotated continuously by the control plane and stored only in HSM-backed key management (AWS KMS or equivalent). No human operator has access to current credential values after initial provisioning. The claim is precise: no static credential ever exists within the platform trust boundary. Infrastructure-layer credential management is automated, audited, and human-inaccessible by design. *** ## Encryption **In transit**: TLS 1.3 minimum for all connections. ML-KEM post-quantum key encapsulation is layered on top for SDK-to-agent tunnels, providing forward secrecy against future quantum adversaries. Session keys are ephemeral and scoped per request per service path. The tunneling protocol specification is publicly documented [here](https://github.com/hardpointlabs/agent/blob/master/PROTOCOL.md). **At rest**: AES-256 via AWS KMS with per-tenant key isolation. A compromise of one tenant's key material does not affect others. Customer-managed keys (BYOK) are supported; where used, Hardpoint cannot decrypt tenant data at rest even under compulsion. Key rotation is automated. Key access is audited independently of application-layer audit logs. *** ## Audit Model All data plane traffic passes through Hardpoint agents before reaching the underlying data store. Audit events are emitted at the agent layer and shipped to an append-only log sink before query execution completes. This provides: * Richer context than database-native audit extensions (tenant identity, originating service, OIDC identity, request trace ID — not just the query and database role) * Tamper resistance: the log record exists before the database has processed the request * Consistency across data store variants: the audit guarantee does not depend on extension support or database configuration There are no bypass paths for privileged operations such as schema migrations. All connections, including those from migration tooling, are routed through Hardpoint agents. *** ## Explicit Non-Goals The following are outside Hardpoint's threat model. This is not an oversight; it reflects deliberate scoping. * **Cloud provider-level attacks**: Hardpoint does not attempt to protect against a compromised hypervisor, memory side-channels, or coercion of the underlying cloud provider. * **Compromise of configured identity providers**: If an OIDC provider trusted by a deployment is compromised, the integrity of that deployment's ingress verification is affected. Customers should apply appropriate controls to their identity provider selection. * **Client-side compromise**: Hardpoint secures the connection and data layer. Compromise of the application process holding a valid OIDC token is outside scope. * **Physical infrastructure attacks**: datacenter physical security is delegated to the cloud provider. *** ### Reporting Security Issues Security disclosures: \ PGP key: available on our [security page](/security.md#pgp-public-key)