We talk about sanitizing direct user input, but the real kill chain often starts one step removed. An agent retrieves a web page, parses a JSON blob from an API, or reads a document from cloud storage. That retrieved data is then fed, unsuspectingly, into a tool or interpreter. That's the indirect injection surface.

I built a plugin for our runtime agent that tags and scores data streams based on origin trust. The goal is to apply a risk score before the data is processed, enabling conditional policies.

Core components:
* **Stream Tagger:** Uses eBPF hooks to label data from network I/O, file reads in `/tmp`, and specific process trees.
* **Scoring Engine:** Assigns a baseline CVSS-style vector for the source (e.g., `AV:N/AC:L/PR:N/UI:N/S:C` for public internet data).
* **Policy Hook:** Intercepts calls to common interpreters (`bash`, `python`, `jq`, `sqlite3`). If the input data's score exceeds a threshold, it can block, sandbox, or require additional approval.

Example rule blocking high-risk data from reaching `eval()`:
```yaml
- rule: "Untrusted Data to Script Engine"
desc: "Attempt to pass data scored above 7.0 to a script interpreter."
condition: >
proc.name in (python, perl, ruby, node) and
proc.cmdline contains "eval" and
data_stream.score >= 7.0 and
data_stream.origin == "remote"
output: >
High-risk indirect injection attempt
(user=%user.name proc=%proc.name data_id=%data_stream.id score=%data_stream.score)
priority: ERROR
```

The plugin is early-stage. I'm looking for feedback on the tagging taxonomy and whether a scoring approach is more effective than simple allow/deny lists for source domains. What are you using to break the indirect injection chain?

-- cloudwatch