Security Model

Release binding: v0.1.0-enterprise-ready · AMI ami-010806d4d3445660e · 2026-05-19

Shared responsibility

Responsibility	Owner
Image hardening, application security, service isolation	Tigantic Holdings LLC
Network configuration (VPC, security groups, NACLs)	Customer
IAM policies for launching and managing instances	Customer
TLS certificate replacement for production	Customer
Volume backup scheduling	Customer
OS patching (unattended-upgrades enabled by default)	Shared
KMS key management and grant policies (AWS)	Shared

Topology and loopback isolation

Internet ──[firewall: 8443]──> hx-gate (0.0.0.0:8443, TLS)
                                  │ loopback only
                                  ▼
                              hx-engine
                                  │ loopback only
                                  ▼
                              redis

Only hx-gate binds a routable interface. The engine and Redis reject non-loopback connections at the bind level; internal isolation is enforced in the bind, not by firewall rules.

Filesystem boundaries: the runtime payload at /opt/hx-sdp is immutable after bake; configuration lives at /etc/hx-sdp with restricted permissions; customer state lives at /var/lib/hx-sdp and is excluded from default support bundles.

TLS

hx-gate terminates TLS on 8443. A self-signed certificate is generated at first boot; replace it with a CA-signed certificate before production traffic. The AWS AMI enforces TLS 1.2 minimum; the Google Cloud image serves TLS 1.3. Internal services communicate over loopback under a same-host threat model.

Credentials

Credential	Generated	Storage	Rotation
Bootstrap admin API key	First boot	/opt/hx-sdp/secrets/bootstrap-admin.json (0600)	Manual: create new keys, revoke old
Tenant API keys	At onboarding	SHA-256 hashed at rest	POST /gate/onboard/rotate-key
ML-DSA-65 signing keypair	First boot	/opt/hx-sdp/secrets/signing/ (0600)	Per instance: a new instance means a new keypair
TLS certificate	First boot, self-signed	/opt/hx-sdp/tls/ (0600)	Customer replaces, restart hx-gate
Redis auth	First boot	/opt/hx-sdp/secrets/redis.conf (0600)	Restart Redis and engine

No credentials are shared across instances, and no credentials are baked into the image.

systemd hardening

All three services run under: NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, an empty CapabilityBoundingSet, SystemCallFilter=@system-service, service-specific ReadWritePaths, and PrivateDevices (except hx-engine, which needs the GPU).

Platform enforcement

• AWS: IMDSv2 is required (HttpTokens = required, hop limit 1); cloud-init uses token-based IMDS access, and application code does not touch IMDS during normal operation. The AMI is encrypted with a KMS CMK; launching principals need kms:CreateGrant on the key, and volumes inherit encryption. The instance requires no IAM role for core operation and does not call AWS APIs during normal operation.
• Google Cloud: the Terraform module supports Shielded VM and OS Login; the image serves TLS 1.3 and runs the same manifest verification and preflight at boot.

Manifest verification

A signed manifest covers all deployed binaries and configuration and is verified at every boot with the build-time keypair whose public key is embedded in the image. Verification is fail-closed: if any file fails its hash check, services do not start.

Audit and support bundles

The gate writes an append-only JSONL audit log; ship it to your SIEM. Support bundles generated with hx-sdp support-bundle redact secrets, keys, and customer data.

Threat model summary

Threat	Mitigation
Network exposure	Single port (8443), firewall-restricted
Credential theft	Per-instance generation, no baked secrets
Lateral movement	Loopback isolation, systemd sandboxing
Data exfiltration	No egress without an explicit API call
Image tampering	Manifest verification at boot, fail-closed
Metadata service exploitation (AWS)	IMDSv2 only, hop limit 1
Privilege escalation	NoNewPrivileges, empty capability set
Disk forensics	Encryption at rest

Security reports: see Security.