The recent shift in the developer community from cloud-hosted, API-based agent frameworks (e.g., OpenAI's Assistants API, various SaaS offerings) to locally-run alternatives (e.g., LangChain with local LLMs, LlamaIndex, or even bespoke scripts) is often framed purely as a cost or data privacy decision. However, from a supply chain and operational security perspective, the attack surface and associated threat models undergo a fundamental transformation. The trade-offs are not merely about who holds the data, but about the integrity and provenance of every component in the execution pipeline.

When operating a cloud-based agent service, your primary security concerns typically align with the provider's threat model:
* **Data exfiltration** via the provider's infrastructure.
* **Prompt injection** leading to unauthorized API calls or data leakage within the provider's ecosystem.
* Reliance on the provider's **infrastructure security** (secrets management, network isolation).

The moment you switch to a local stack, you inherit the full responsibility for the security posture of a vastly more complex software supply chain. Let's analyze the new threat model.

**Expanded Attack Surface in Local Agent Frameworks:**

1. **Model File Integrity:** The LLM model file (e.g., a `.gguf` or `.safetensors` file) becomes a critical artifact. You must now verify:
* **Provenance:** Did this file come from the original model publisher, or a tampered repository?
* **Build Integrity:** For quantized models, was the quantization process performed by a trusted toolchain? An attacker could embed payloads during quantization.
* **Signing:** Does the publisher use Sigstore or a similar framework to sign releases? Most do not, creating a significant gap.

A minimal verification step using `cosign` for a signed model would be ideal, but is rarely available:
```bash
# Hypothetical – most model hubs don't support this yet
cosign verify ghcr.io/huggingface/text-generation-inference:llama-2-7b
--certificate-identity https://huggingface.co/llama
--certificate-oidc-issuer https://token.actions.githubusercontent.com
```

2. **Framework and Dependency Trust:** Local frameworks pull in dozens of dependencies (Python packages, native libraries). A compromise in `langchain-core`, `transformers`, or even a low-level tensor library could lead to:
* **Arbitrary code execution** during agent inference.
* **Secret leakage** from the local environment (e.g., exfiltrating `OPENAI_API_KEY` used for fallback tasks).
* **Training data poisoning** in future fine-tuning runs.

This necessitates a strict SBOM and SLSA-grade build process for your entire agent environment, which is currently unrealistic for most ad-hoc setups.

3. **Reproducible Builds for the Agent Itself:** Your own agent application—the glue code that uses the framework—must be built reproducibly to detect tampering. If you containerize your agent, can you attest that the image was built from the exact source in your repo, with no injected malware? This is where `in-toto` attestations and `gittuf` for securing the git workflow become relevant.

4. **Local Execution Sandboxing:** Cloud providers often have robust, kernel-level isolation between tenants. Locally, your agent might run with full network access and user permissions. A successful prompt injection could now:
* **Read/write sensitive files** on the local filesystem.
* **Make arbitrary network calls** to internal services or the internet.
* **Execute system commands** via vulnerable subprocess calls in your framework.

**Comparative Security Posture:**

| Control | Cloud-Based (Managed Service) | Local Framework (Self-Hosted) |
| :--- | :--- | :--- |
| **Model Integrity** | Provider's responsibility. | Your responsibility. Largely unverified. |
| **Dependency Hygiene** | Provider's monolithic application. | Your sprawling, dynamic dependency tree. |
| **Build Provenance** | Opaque, but provider's problem. | Must be established and verified by you. |
| **Execution Sandbox** | Provider-managed, strong isolation. | You must implement (e.g., `nsjail`, `seccomp`, user namespaces). |
| **Secret Access** | Limited to provider's key management. | Direct access to host environment variables, credential files. |

The conclusion is not that local agents are inherently less secure, but that the **locus of security responsibility and the required expertise shift dramatically**. You are trading the risk of provider compromise for the risk of supply chain compromise and inadequate local isolation. Without investing in the tools and practices of supply chain security—signing, attestation, reproducible builds, and strict sandboxing—the local agent stack may actually be *more vulnerable* to sophisticated attacks, even as it protects against the provider seeing your data. The community's next challenge is to bring SLSA principles to the local AI/agent development lifecycle.