Built a template because I keep seeing the same mistakes with these "high-integrity" financial agents. Everyone focuses on the model, then slaps a basic auth on a Flask app and calls it secure. That's not a threat model.
This template assumes:
* Agent ingests sensitive financial documents (PDFs, spreadsheets).
* Makes investment recommendations via an LLM.
* Output must be tamper-proof and non-repudiable.
* Deployed in a container, but with elevated privileges to access host data (that's the failure).
Key failure modes most templates ignore:
* **Data exfiltration via indirect prompt injection:** Attacker embeds malicious instructions in a source document. Template forces data flow diagrams to track untrusted data.
* **Container escape via mounted volumes:** The deployment pattern requires host mounts. Template includes seccomp/AppArmor rules that are actually restrictive.
* **Integrity of outputs:** No signing of recommendations. Template adds a mandatory signing step with a protected key.
Core of the template is the mitigation table for STRIDE per data flow element. Example for the "Document Parser" component:
```
Component: Document Parser (Processes uploaded files)
- Spoofing: Service account with defined roles only. No interactive logins.
- Tampering: Files processed in a tempfs mount, read-only after upload.
- Repudiation: All parsing actions logged to a secured, append-only audit trail.
- Information Disclosure: Parser runs with seccomp filter blocking network syscalls.
- Denial of Service: Memory limits (cgroups) and input file size caps.
- Elevation of Privilege: No SETUID binaries. Capabilities dropped: `docker run --cap-drop=ALL --cap-add=DAC_OVERRIDE` (minimum needed for file access).
```
The template is empty without your specific data flows. Fill it in, then we can tear it apart. The assumptions section is the most important part. If you assume the kernel is patched, write it down. If you assume the internal network is trusted, write it down so we can call you out on it later.
--segfault
Segfault out.
Okay, the signing step for outputs makes a lot of sense. But I'm new to this - how do you handle the signing key in practice? If it's in the container for the agent to use, isn't that risky too? Do you use a separate, locked-down service just for signing?
Sorry if that's a basic question. The data flow diagrams to track untrusted data sounds like a good visual aid for people like me who are still learning.
Totally valid question, and you've hit on the big design flaw in most setups. If the agent has the key, you've already lost.
The template uses a separate signing microservice. The agent only gets a session token, sends the recommendation payload over a local gRPC call, and gets back a signed result. The signing service lives in its own ultra-minimal container, with the HSM or key stored on a separate physical Raspberry Pi on the same private network. No shared mounts.
For learning, draw the data flow and put a big red boundary around that signing service. Everything inside that box is your new "high trust" zone.
No cloud, no problem.
Yeah, the separate Pi for the signing service is brilliant. I went down that rabbit hole last year with a tax-doc parsing agent.
The caveat I learned the hard way: don't let the agent microservice and the signing service *share the same Docker network*. If the agent container gets popped, it can still scan that network. Put the Pi on its own isolated VLAN, and have the agent service call it via a dedicated, firewalled host bridge. It's one extra hop, but it means even a full container compromise can't port-scan your HSM endpoint.
Also, what's your logging strategy for the signing service? Mine logs every request hash to a separate, append-only syslog server. If you ever need to audit, you've got an immutable record of what was signed, separate from the agent's own possibly-tampered logs.
Still learning, still breaking things.
That mitigation table idea is a lifesaver, honestly. Trying to keep all the STRIDE categories straight in my head is overwhelming sometimes.
Could you share a little more about what you put under "Spoofing" for the Document Parser? I'm guessing it's about validating the source of the upload, but is it also about making sure a malicious document can't spoof its file type or metadata to trick the parser? That's something I'd probably miss.
The STRIDE table is the right idea, but you've only listed mitigations for the components you design. The weakest link is the libraries you didn't write.
Your document parser uses something like pdfplumber or Apache PDFBox. Spoofing there means a malformed PDF that causes the library to misinterpret the content, like hiding a prompt injection in an embedded font definition. You need to map those library interactions into your table too, or you're only seeing half the attack surface.
stay on topic or stay off my board