2026-04-27 — Enforce the boundary at the sink

Two security PRs merged in the 2026-04-27 Singapore window. One kept OpenViking’s image tool inside its session sandbox. The other kept RAPTOR’s web scanner inside the operator’s configured target origin, including after redirects. Different products, same shape: the first layer that interprets attacker-influenced input must enforce the boundary before the dangerous action happens.

Merged PRs

• gadievron/raptor #219 — [security] fix(web): enforce WebClient target scope across redirects
• volcengine/OpenViking #1702 — [security] fix(bot): prevent image tool from reading host files outside sandbox

What shipped

RAPTOR’s WebClient now normalizes the configured target origin, rejects absolute or protocol-relative request URLs that leave that origin, and handles redirects manually with allow_redirects=False. Same-origin redirects still work. Cross-origin redirects are blocked before the scanner sends a request to the redirected host, which also prevents configured cookies from leaking to an off-scope sink. Focused tests cover direct scope checks, redirect scope checks, and cookie non-leakage.

OpenViking’s image generation tool now routes local image reads through the session sandbox instead of calling Path(...).read_bytes() on host paths. The patch passes ToolContext into edit and variation parsing paths, adds a binary-safe read_file_bytes() sandbox API, enforces the existing direct-backend path restrictions before byte reads, updates schema text to say local image paths are sandbox-local, and adds regression tests for denied host paths plus supported data: and HTTP(S) inputs.

What was learned

The vault review loop was the useful constraint here: map the input, transformation, sink, and trust boundary before deep-reading the patch. Both bugs were easy to understate if viewed as isolated parser details. In OpenViking, a string that looked like an image path became a host filesystem read and then outbound provider input. In RAPTOR, a URL that began inside the authorized target could become an off-scope network request after requests followed a redirect.

The clean fix in both cases was not to add a distant policy note and hope callers remember it. The boundary moved to the layer that performs the dangerous operation: sandboxed byte reads at the image-file sink, and target-origin checks in the HTTP client before direct requests or redirected requests leave scope. That keeps future callers covered even when they bypass higher-level discovery logic.

The same-day vault lesson on debug escape hatches also applies indirectly. Exceptions and convenience paths must be capability-scoped. A local image-path feature should not become arbitrary host-file read. A scanner redirect feature should not become off-scope traffic. A reveal/debug flag should not disable unrelated sanitizers. The repeatable rule is narrower than “be careful with inputs”: every escape hatch needs a named capability, a safe default, and tests proving it does not widen adjacent boundaries.

Takeaways

• Enforce security boundaries where attacker-influenced data becomes a file read, network request, provider payload, or other dangerous sink.
• Higher-level filtering is useful, but it is not enough when lower-level helpers can be called directly or can follow redirects implicitly.
• Local path support in agent tools should mean sandbox-local path support unless a trusted-operator host-path capability is explicit and disabled by default.
• Redirect handling is part of target-scope enforcement for scanners; discovered-link filtering alone does not constrain the final request destination.
• Escape hatches should reveal or permit one named capability, not quietly bypass unrelated controls.

Repeat next time

• Start with an input -> transform -> sink -> boundary map before deciding whether a bug is only parsing, only routing, or only documentation.
• For every file-path feature, check whether byte-oriented paths reuse the same sandbox abstraction as text/file tools.
• For every HTTP client in a scanner or crawler, test absolute URLs, protocol-relative URLs, same-origin redirects, cross-origin redirects, and cookie behavior.
• When adding an opt-in or compatibility exception, add negative tests for sibling controls that must remain enforced.