Rogue workload
Malicious or compromised service inside a cluster attempting lateral movement or credential abuse.
// Security
Trust is assumed because the workload is already running.
The honest question for a workload trust system is not "is it secure?" It is which attacker paths the system closes, which it constrains, which it makes attributable, and which it acknowledges remain. This page sets out QHx's threat model directly — including the residual risks.
001 · Objectives and non-goals
Scoping non-goals is part of the security model.
A security model that does not name what it is not responsible for is not a security model. It is a sales claim.
QHx's design center is workload identity, identity-bound communication, and durable provenance. It does not replace host hardening, supply-chain integrity, organizational identity governance, or application-layer security.
What QHx is responsible for
- Workload identityCryptographically verifiable identity bound to a running workload, conditioned on attestation evidence.
- Identity-bound communicationMutually authenticated channels between attested workloads, resistant to spoofing, replay, and lateral movement.
- Policy on identity, not locationAuthorization decisions operate on workload identity and runtime context rather than IP adjacency.
- Durable provenanceSigned records of request, response, and identity that remain verifiable after the credential expires.
What QHx is not responsible for
- Software supply chainQHx does not substitute for build integrity, artifact signing, or release pipeline controls.
- Host and endpoint hardeningQHx cannot protect assets within a fully compromised host. Host security is a prerequisite, not an output.
- Organizational identity governanceQHx does not manage human identity, role assignment, or access reviews.
- Application-layer vulnerabilitiesVulnerabilities in application code above the proxy remain outside QHx's scope.
002 · Adversary model
Seven attacker classes, named.
These are not hypothetical. They are the attacker classes operationally present in distributed, multi-tenant, and coalition environments. QHx is designed against this set deliberately.
Compromised node
Host or hypervisor compromise enabling credential extraction, workload spoofing, or attestation manipulation.
Malicious operator
Over-privileged or adversarially controlled administrator abusing legitimate access paths.
Network adversary
On-path attacker capable of interception, downgrade attempts, replay, or traffic manipulation.
Supply-chain adversary
Compromise introduced through the build, release, or distribution pipeline before deployment.
Cross-domain or coalition threat
Trust confusion across federated domains, coalition boundaries, or stale trust data in degraded operations.
Cryptanalytic and harvest risk
Forward-looking adversary harvesting encrypted traffic now for decryption once quantum capability matures.
003 · Threat matrix
What QHx mitigates. What must come from the surrounding system. What remains.
Every row is a concrete scenario. The middle column names what only QHx can do. The right columns name what QHx alone cannot finish.
| Threat | Primary QHx mitigation | Compensating control required | Residual risk |
|---|---|---|---|
| Workload impersonation | Cryptographic SVID identity, attestation-gated issuance | Secure boot, host hardening, image signing | A compromised node can impersonate workloads running on it. |
| Unauthorized credential issuance | Node attestation precedes workload attestation; selectors enforced | Protected PKI material, RBAC on Manager | PKI compromise or insider with issuance authority. |
| East-west interception | Mutually authenticated mTLS bound to identity | Segmentation, DNS hygiene, monitoring | Application-layer vulnerabilities above the tunnel. |
| Replay and credential reuse | Short-lived SVIDs, certificate-bound identity, rotation | Time synchronization, rate limiting | Replay within the short validity window if clock drift exists. |
| Unauthorized lateral movement | Identity-aware policy, namespace-scoped authorization | Network segmentation, RBAC | Misconfigured policy permitting overbroad access. |
| Policy tampering | Trust-domain boundaries, federation controls, attested issuance | Datastore integrity, access control on policy engine | Insider with legitimate policy authority. |
| Supply-chain compromise | Attested build path, notarization where applied | Artifact signing, secure CI/CD, integrity checks | Compromise prior to attestation or notarization point. |
| Operator abuse | Separation of duties across Manager, PKI, Notary, Policy | PAM, access logging, review workflows | Collusion, or a single operator with unconstrained authority. |
| Repudiation of handling | Notarization of request and response, signed receipts | Log retention, forensic pipeline | Notarization not applied universally to all workloads. |
| Harvest-now-decrypt-later | Post-quantum mTLS path (ML-DSA, ML-KEM, hybrid) | Migration of remaining endpoints to PQ | Endpoints not yet migrated retain classical-only exposure. |
004 · Identity and attestation
What can go wrong at issuance, and what holds.
Threat surface
- Rogue workload seeking valid SVIDAttempting to obtain a credential without legitimate attestation evidence.
- Compromised node minting credentialsNode-level compromise abusing the workload credential issuance path.
- Selector mis-bindingConfiguration errors that bind credentials to the wrong identity context.
- Attestation bypassWeak or absent bootstrap path allowing issuance without verification.
- Stolen short-lived credentialsExtracted SVIDs replayed within their validity window.
QHx mitigations
- Node-first attestationWorkload identity is not issued until the hosting node has been attested.
- SPIFFE / X.509-SVID modelCryptographic binding of identity to workload — portable and verifiable.
- Short-lived rotationAutomatic SVID rotation constrains the utility of any extracted credential.
- Selector-based bindingNamespace and policy constraints gate which workloads may request which identities.
Residual: full host compromise allows an attacker to extract and reuse credentials for the window before revocation. QHx does not claim to defend assets inside a compromised trust boundary.
005 · Communication and traffic
Identity-bound channels, not encrypted pipes.
An encrypted channel without verified endpoints is an encrypted channel to anywhere. QHx makes peer identity a precondition for the channel rather than a property optionally checked above it.
- Mutually authenticated tunnelsBoth endpoints prove workload identity before data flows. A stolen credential without the workload that earned it cannot complete the handshake.
- No silent downgradeHeterogeneous endpoints do not produce a quiet plaintext fallback. Either the policy permits the protocol, or the channel does not open.
- Identity-aware authorizationPolicy operates on SPIFFE ID, namespace, and label, not on IP address or port.
- Post-quantum pathML-DSA signatures and ML-KEM key establishment, with hybrid modes during migration. Recorded classical-cipher traffic stops being a deferred liability.
006 · Control plane, federation, supply chain
QHx is strongest inside a disciplined operational system.
Deployed in isolation, the control-plane trust assumptions become the primary attack surface. The list below is what QHx contributes and what must come from elsewhere.
What QHx contributes
- Separation of dutiesManager, PKI, Notary, and Policy roles are distinct and individually scoped.
- Trust-domain boundariesFederation is explicit and negotiated, not assumed across organizations.
- Attested issuanceThe chain from measured platform to issued credential is intact and auditable.
- Provenance receiptsNotary signs request, response, and identity into a verifiable record.
What must come from outside QHx
- Pipeline integrityBuild signing, secure CI/CD, and artifact provenance.
- Root key protectionHSM or KMS storage for CA and root attestation material.
- Privileged access governancePAM, audit, separation of administrative authority.
- Datastore integrityBackup, recovery, and verification of policy and trust state.
007 · Residual risks
What still remains after the controls work as intended.
These are operational realities, not design failures. A complete security model names them.
Full host compromise
A compromised node grants access to credentials of workloads running on it. QHx cannot defend assets inside a fully compromised trust boundary.
Compromised root of trust
Compromise of the PKI root, HSM, or attestation root collapses the issuance model. This is a dependency, not something QHx resolves internally.
Insider with legitimate authority
Operators with access to the policy engine, Manager, or PKI can abuse it. Separation of duties reduces this surface; it does not eliminate it.
Weak attestation evidence
Without TPM, measured boot, or equivalent, attestation quality drops. Issuance assurance degrades accordingly.
Federation misconfiguration
Cross-domain trust scoped incorrectly can accept foreign credentials. QHx provides the controls; correct use requires disciplined configuration management.
Stale trust in disconnected operation
Disconnected nodes may apply expired policy or stale trust bundles. Freshness cannot be forced without connectivity to the control plane.
Application-layer vulnerabilities
Code above the transport remains outside QHx’s scope and must be addressed through other controls.
Pre-deployment supply-chain compromise
Malicious artifacts introduced before QHx’s attestation or notarization point are not retrospectively detectable by QHx.
// Security
Narrow the paths. Strengthen the attribution. Name what remains.
QHx is one disciplined layer in a larger security architecture. Its effectiveness depends on the quality of the environment it is deployed into and the rigor of the controls that surround it.
Talk to us