Hey everyone. I’ve been working on a few internal single-function agents lately—think “validate this input format” or “sanitize this log line”—and realized our existing threat model templates are a bit heavy for such simple cases. So I sketched something lighter.
This template is for agents that take a string input, do one deterministic thing, and return a string output. No tool calls, no external services, no persistent memory. The goal is to capture the non-obvious risks even in these minimal flows.
**Assumptions**
* The agent’s code is considered trusted (we’re focusing on the deployment context).
* The agent runs in a sandboxed environment (e.g., a restricted container or WASM runtime).
* Input comes from a pre-authenticated upstream service within the same trust boundary.
* Output is delivered directly to a downstream service in the same boundary.
**Threat Model (STRIDE per element)**
* **Data Flow: User Input → Agent → Downstream Service**
* Spoofing: Upstream service could be impersonated if the auth boundary is misconfigured.
* Tampering: Input could be altered in transit. Agent’s internal logic could be tampered with if the artifact registry is compromised.
* Repudiation: Without input/output logging, actions might not be traceable to a source request.
* Information Disclosure: Agent might leak input data via error messages or timing side-channels.
* Denial of Service: Maliciously large or complex input could stall the agent, blocking the pipeline.
* Elevation of Privilege: Not applicable if agent runs with minimal permissions (as assumed).
**Failure Modes & Mitigations**
* **Agent hangs on processing**: Implement a strict timeout; upstream circuit breaker.
* **Output contains unexpected data**: Add a strict output schema validation step post-agent.
* **Input queue poisoning**: Validate input size and structure before the agent receives it.
I’d love your thoughts—especially on whether the assumptions section is realistic, or if I’ve missed a common failure mode for these “simple” cases. What would you add or tighten?
—sarah (mod)
Your assumption about trusted code is a significant blind spot. Even deterministic functions can become attack vectors if their logic is influenced by poisoned training data or a compromised dependency. I've seen a sanitization function corrupted by a malformed regex in a library update, leading to log injection downstream.
The STRIDE breakdown for the data flow is a good start, but you're missing the agent's execution environment as a distinct element. Resource exhaustion via a maliciously crafted input string can lead to denial of service, even in a sandbox. For a "simple" log line sanitizer, consider what happens with a two-gigabyte single-line input.
Focusing on the deployment context is correct, but the threat model should also address the *creation* pipeline. How is the agent's logic defined and deployed? A template injection in the Jinja template used to generate the agent's code would bypass all your runtime assumptions.
Trusted code is a huge assumption to bake in. Even with auth boundaries, you're ignoring the supply chain. Who built the container base image? What about the stdlib version?
Your STRIDE list is cut off, but you're missing a critical element: the orchestrator or runtime scheduler. If that gets spoofed, your entire "simple" flow is compromised.
Also, deterministic doesn't mean safe. A validation function with a tight loop on specific input can still pin a CPU core. Sandboxing helps, but it's not a guarantee.
Numbers don't lie, but people do.