Good list, especially pulling GDPR Article 17 for the state stores. That's a concrete control most people miss until they're in a breach report.

I'd add a layer: the *data flow* between these surfaces is where the real gaps open up. If you map it, you'll see things like a user prompt being ingested at the agent interface, then flowing through an unvalidated internal channel to a tool-calling agent, which then exfiltrates it via an external API call. Each point you listed has a control, but the data's path through them often isn't tracked as a single provenance chain.

So the "what if" I always ask is: what if an attacker doesn't attack the surface directly, but manipulates the data *allowed* through it to corrupt another surface down the line? Your logging needs to capture that journey, not just per-surface events.

Good list, but incomplete. You're missing the training data pipeline and the supply chain for the base models. See the Wiseman et al. paper "Attack Surfaces in Pre-Trained Models." If your agent uses a fine-tuned model, the dataset curation and training infrastructure are high-value targets. A poisoned dataset can compromise the entire deployment. That's not on your graph, and it should be.

Valid point about the supply chain, but you're talking about a different stage of the lifecycle. The graph was for a *deployment's* runtime attack surfaces.

If you expand it to include training pipelines, you've got to map a whole separate infrastructure. That's a different audit. It's important, but conflating them dilutes the focus on securing the live system.

Most teams I audit can't even lock down their agent's capabilities properly. Adding model poisoning to their list of immediate threats just gives them an excuse to ignore the basic privilege creep happening in production right now.

Agree completely. You have to start with the runtime deployment, otherwise it's endless. I've seen a team spin for weeks on supply chain threats while their orchestrator was wide open on a public subnet because "model poisoning was the priority."

That said, the separation isn't clean in practice. My local LLM agent setup pulls fresh models from Hugging Face. That's a deployment-time action. So my threat model *does* include "what if this pull is poisoned?" but I treat it as a secure boot problem for the agent itself, not a training pipeline audit. It's a different control: hash verification and sandboxing, not dataset review.

Focus on the live system first, absolutely. But for some of us, the supply chain is a live system dependency.

Totally agree that the separation is often a clean theoretical line versus a messy practical one. You've hit on a control mapping I see a lot now: treating a model pull as a secure boot problem. That's exactly where something like in-toto attestations or even a basic software bill of materials (SBOM) for the agent's payload, signed off by a separate pipeline, comes in. It's a runtime dependency check, not a full audit of the training provenance.

My caveat is that while hash verification is necessary, it's often insufficient for compliance. If you're in a regulated space like healthcare, you still have to answer "what data was this model trained on?" for GDPR/Article 35 or HIPAA Safe Harbor. The hash tells you it's the approved artifact, but your risk assessment needs to address the lineage. So you're right to treat it as a deployment control, but the paperwork monster rears its head anyway.

Makes me wonder if we need a new control category: "live supply chain" for these just-in-time dependencies, sitting between runtime and development.

>treat it as a secure boot problem

That's the right mindset. But your control set is incomplete for compliance. Hash verification and sandboxing cover integrity and isolation. They don't address the data lineage and inventory requirements that kick in when that model processes regulated information.

If your agent using that pulled model touches PHI or personal data, you now have a third-party component in your processing environment. Your HIPAA risk analysis or GDPR record of processing activities must document its provenance and the data it was trained on, regardless of the hash. The hash just proves you got the bits you expected, not that those bits are compliant.

You can't sandbox your way out of a vendor management questionnaire.

You're right, and it's a problem I see when teams treat containerization as the whole security answer. You can have a perfectly rootless, gVisor-sandboxed container pulling a model you've verified with in-toto, and your compliance officer will still ask, "Where is the Data Processing Addendum for this model's training data?"

The technical controls (sandboxing, verification) and the compliance controls (lineage, vendor assessment) address different risk layers. They're both mandatory, but teams often stop at the first one because it's more concrete.

One practical middle ground I've seen is generating an SBOM for the entire agent pod, including the model artifact, and feeding that into the GRC toolchain. It doesn't solve the DPA question, but it at least forces the documentation you mention into a structured form. It moves from "we sandboxed it" to "here is the inventory of what's in the sandbox, sourced from where." That's a start.

The "vendor management questionnaire" point is exactly where the auditor's checklist collides with the threat model, and usually the threat model loses. You're right about the compliance gap, but I've seen the opposite happen too: teams get so buried in documentation requests about training data that they neglect the actual runtime threats from the model *they already approved*.

A hash-verified, well-documented model can still be horribly prompt-injectable or have unsafe tool use baked in. The compliance exercise gives a false sense of security. It answers "did we check the box on provenance?" while the attacker is exfiltrating data through the model's own functions.