We Secured an AI Inference Gateway. Our Threat Model Still Missed Two Things

A rigorous threat model tells you what protects your assets. It names the controls, defines the trust boundaries, and enumerates the attack vectors at each boundary crossing. Done well, it is the most valuable security activity in a deployment project.

What it does not automatically tell you: whether those protections are correctly specified at the implementation level, and whether they hold across every path a sensitive credential actually travels — not just during normal operation.

We encountered both gaps on the same project. We added a gate to close each one. This is what we added, why, and what each gate found.

The project context

The system was a sovereignty-constrained LLM inference node — a regional gateway serving engineers with access to large language model services, with a hard requirement that all confidential and NDA content remain inside a jurisdictional boundary. The security requirements were not casual. The deployment ran inside a managed cloud environment with customer-managed encryption keys, network egress enforcement, workload identity federation, and a structured secure development lifecycle with a formal threat model, gap decision log, and explicit human review and sign-off at each phase gate.

The threat model was thorough. It identified assets, defined trust boundaries, enumerated attack vectors, and recorded explicit gap decisions with rationale. It was not a checkbox exercise.

It still missed two things. Both were found by gates we added after recognising the gaps, not by the threat model itself.

Gate 1 — CBOM as a mandatory pre-implementation checkpoint

The pain point

The threat model listed cryptographic controls for each asset. The TLS certificate was documented as a protected asset. The session management layer was documented as using an authenticated mechanism. Both statements were true in intent.

What the threat model did not verify: whether the implementation matched the intent.

During a CBOM review run before implementation opened, two findings surfaced that the threat model had not caught.

The certificate management component was issuing RSA-2048 keys. Not because anyone chose RSA-2048 — because no one had specified a key algorithm. The component uses its built-in default when the algorithm parameter is absent. There was no wrong line in the code. There was an absent line. The component was initialised correctly by every functional measure, and its default happened to be a deprecated algorithm.

The session management layer was signing session cookies with HMAC-SHA1. Same pattern: the web framework’s built-in session middleware uses HMAC-SHA1 unless explicitly overridden. No explicit override had been made. No wrong line. An absent specification.

Neither finding was visible to a network scan of the deployed system. The deployed system presented valid certificates and functioning session management. The weaknesses existed not in what was deployed but in what was not specified during construction.

Why the threat model did not catch this

The threat model named the control — “TLS certificate,” “authenticated session management” — and moved on. It had no gate that asked: is this control explicitly specified in code and configuration, or is it the library’s built-in default?

That question is not part of standard threat modelling practice. STRIDE and related methods identify what needs protecting and what attack vectors exist at each boundary. They do not audit whether the listed cryptographic control is explicitly chosen or silently inherited.

The implicit default is the failure class that falls between threat modelling and implementation review. The threat model assumes correct specification. The code review sees no wrong line. The gap lives in the absence of an explicit decision.

What we added

A Cryptographic Bill of Materials produced at threat model completion, before any implementation begins.

The CBOM is not a post-deployment scan. It is a pre-implementation inventory: every component that touches encryption, signing, key derivation, or session authentication is enumerated. For each, the question is whether the algorithm is explicitly specified in code or configuration, or inherited as a library default. Any default is a finding. Any finding requires an explicit gap decision before implementation proceeds.

The diagnostic question for every cryptographic component:

If you deleted the algorithm parameter from the code, would the behaviour change? If not — the algorithm is implicit. It needs to be named, evaluated, and owned before implementation opens.

Sign-off on the complete CBOM inventory is required before the implementation phase gate opens. Any primitive discovered during implementation that was not in the pre-implementation CBOM is a gate violation: stop, document, decide, then proceed.

The two findings above were caught by this gate and remediated before deployment: the certificate algorithm was explicitly specified as ECDSA P-256, and the session middleware was subclassed to enforce HMAC-SHA256. Neither required architectural change. Both required a conscious decision that the implicit default had been making silently.

Gate 2 — Three-path credential lifecycle analysis

The pain point

The same threat model that missed the implicit defaults also missed something structurally different: not what algorithm a credential used, but where the credential went.

The master administrative credential — the root of the entire system’s access control — was correctly protected at rest inside encrypted cluster storage under a customer-managed key. During normal operation it never left the cluster. The threat model had assigned it the correct security properties and documented appropriate controls. On the operational data flow diagram, it was handled correctly at every step.

What the threat model had not traced was the administrative path: what happened when an operator needed to perform a management action.

The administrative tooling read the master key from encrypted storage, decrypted it, held it in process memory on the operator workstation, and used it to authenticate an API call — on every administrative invocation.

The workstation is not the cluster. Encrypted cluster storage provides managed encryption at rest, platform-managed memory isolation, and tamper-evident access audit logging. The operator workstation provides OS-level process isolation, no equivalent access audit, no managed encryption at rest, and no memory encryption. The administrative path was silently breaking the isolation and least-privilege invariants the cluster environment had been specifically architected to enforce — not through a misconfiguration, but through a completely routine operator action that the threat model had not traced. A compromised workstation — via a malicious dependency, a supply chain attack, or physical access — does not require a malicious operator to expose the credential.

Six attack vectors were opened by this path. None of them were in the threat model, because the threat model had not been asked to trace the administrative path. It traced what the system does during operation. It did not trace what happens to the credential when a human operates the system.

Where this thinking comes from

This gap and its resolution draw directly on how embedded security practitioners are trained to think about credentials and keys.

Threat models for hardware security modules, PSA-certified firmware, and secure elements require tracing a credential across three distinct phases of a device’s life: provisioning at manufacture, operation in the field, and administrative access during maintenance or update. Each phase involves different actors, different physical environments, and different trust boundaries. A key that is correctly protected inside a secure element during field operation may transit a manufacturing jig with weaker controls during provisioning. A technician’s laptop during a firmware update is not the tamper-resistant device in the field. Security architects in embedded systems are trained — and evaluated — on whether they have traced all three phases explicitly.

Cloud deployment threat modelling comes from a different tradition: application security, data flow diagrams, STRIDE at network boundaries. That tradition produces thorough analysis of the operational path. It does not naturally ask what happened before the system was deployed, or what happens to its credentials when an operator manages it. Those phases are not on the data flow diagram.

What we applied on this project was the embedded security lifecycle discipline, imported into a cloud deployment context. The three-path structure — provisioning, operational, administrative — is not new. We borrowed it from a domain where it is mandatory and applied it where it was absent.

What we added

For every sensitive asset in the threat model, three paths are now explicitly required:

Provisioning path: how the credential comes into existence, in which domain, under which protections, with which algorithm committed at creation time.

Operational path: how the credential is used during normal system operation — which components read it, in which domains, across which trust boundaries. This is the path standard threat models already trace.

Administrative path: what happens to the credential during management operations — rotation, revocation, diagnostic, break-glass. Which domains does it enter? What security properties does each domain provide? What attack surface opens at each trust boundary crossing that does not exist on the operational path?

For every trust boundary crossing on the administrative path, the analysis requires: source domain and its security properties, destination domain and its security properties, the delta between them, and for each degraded property, either a control or an explicitly accepted residual risk recorded in the threat model.

The administrative path analysis of the master key found the workstation transit, enumerated the six attack vectors the delta opened, and produced an architectural resolution: the administrative tooling was redesigned as an in-cluster job. The master key reads from an in-cluster environment variable inside the cluster boundary. It never decrypts outside that boundary under any operational or administrative path. The attack surface that the workstation transit had opened was closed architecturally, not by hygiene controls.

What both gates have in common

Neither gate is a new analytical method. CBOM inventory exists as a concept. Lifecycle path analysis exists in embedded security practice. What both gates share is a specific position in the security process: between threat model completion and implementation opening.

Standard threat modelling produces a set of controls and accepted residuals. Standard implementation then executes against those controls. The gap between them — where algorithm defaults get committed silently and where credential paths cross boundaries the threat model did not trace — is where both findings lived.

Both gates close that gap by requiring explicit verification before implementation proceeds: verify that every cryptographic control is specified, not assumed; verify that every sensitive credential’s full lifecycle is traced, not just its operational path.

The threat model tells you what should be true. The gates verify that what should be true is actually what gets built.

A practitioner note on overhead

Both gates are lightweight in proportion to the risk they close.

The CBOM inventory for this project covered fourteen cryptographic components. Producing it required one structured review session before implementation opened. The two findings it caught would have required CA rotation and session key rotation post-deployment — significantly more expensive than the pre-implementation fixes.

The three-path analysis for the master key took one design session. The architectural resolution it produced — in-cluster execution — was more elegant than the original design and eliminated an entire class of operational risk permanently.

Neither gate requires specialised tooling. Both require deliberate discipline: a structured checklist, a human review and sign-off gate, and a commitment not to open implementation until both are complete.

The author works on embedded security architecture, PSA certification engineering, and sovereignty-constrained cloud deployment.