chore: AgentSnapshot reference removal from SECURITY.MD (#12033)

This commit is contained in:
David S. Batista
2026-07-17 09:28:35 +02:00
committed by GitHub
parent b67079ad0e
commit b1031bfb69
+1 -1
View File
@@ -29,7 +29,7 @@ Haystack pipelines in YAML are a serialization format for executable pipelines.
**Loading a pipeline from an untrusted source is unsafe by design.** This is not a hidden weakness but the expected consequence of a system that lets users bring their own code. The security responsibility lies with the operator: pipeline definitions must be treated as code, stored and transmitted with the same controls applied to source code, and never loaded from untrusted or user-controlled input without review.
Reports that demonstrate, for example, `import_class_by_name()` can import arbitrary modules given a pipeline that an operator chose to load are out of scope.
The same trust boundary applies to serialized snapshots, including `PipelineSnapshot` and `AgentSnapshot`. A snapshot is operator-controlled state that is intentionally human-readable and editable (for example, to inspect or modify a paused execution before resuming it). Resuming from a snapshot deserializes its contents without integrity verification, by design. Snapshots must therefore be stored and access-controlled as trusted artifacts, exactly as pipeline definitions are. Reports that rely on modifying a snapshot an operator chose to resume from are out of scope.
The same trust boundary applies to `PipelineSnapshot`, which is an operator-controlled state that is intentionally human-readable and editable (for example, to inspect or modify a paused execution before resuming it). Resuming from a snapshot deserializes its contents without integrity verification, by design. Snapshots must therefore be stored and access-controlled as trusted artifacts, exactly as pipeline definitions are. Reports that rely on modifying a snapshot an operator chose to resume from are out of scope.
However, if you find a way to achieve arbitrary code execution that does *not* rely on an operator loading an untrusted pipeline (for example, a memory-safety issue in the parser itself, or a class of pipelines that triggers unintended behaviour in the Haystack runtime), that finding is in scope.