Summary
Two related gaps in output validation:
-
Foundry API requests bypass domain blocklist (routes.rs:815-836) — blocklist checks the upstream endpoint domain, but the agent controls the project ID and resource paths. An agent could access unauthorized datasources via /knowledgebases/{evil-kb}/search.
-
Egress fetch responses returned unvalidated (routes.rs:1836-2017) — response body is capped at 2MB but no content inspection. An allowlisted domain could return malicious payloads (script injection, oversized JSON, binary exploits).
Proposed Fix
For Foundry API: Validate request body before proxying:
if let Some(datasource) = req_body.get("datasource_id") {
if !policy.is_approved_datasource(datasource) {
return Err("Datasource blocked by policy");
}
}
For egress fetch: After receiving response, validate content:
let body = resp.bytes().await?;
validate_response_content(&body, expected_content_type)?;
// Check: max nesting depth, no embedded scripts, size within policy
AGT's output validation middleware handles both patterns.
References
- routes.rs lines 815-836 (foundry_proxy)
- routes.rs lines 1836-2017 (egress_fetch)
Summary
Two related gaps in output validation:
Foundry API requests bypass domain blocklist (routes.rs:815-836) — blocklist checks the upstream endpoint domain, but the agent controls the project ID and resource paths. An agent could access unauthorized datasources via
/knowledgebases/{evil-kb}/search.Egress fetch responses returned unvalidated (routes.rs:1836-2017) — response body is capped at 2MB but no content inspection. An allowlisted domain could return malicious payloads (script injection, oversized JSON, binary exploits).
Proposed Fix
For Foundry API: Validate request body before proxying:
For egress fetch: After receiving response, validate content:
AGT's output validation middleware handles both patterns.
References