Harden upstream auth, tool policy, and proxy security boundaries

[davidruzicka]

Summary

Harden MCP proxy support with explicit upstream auth boundaries, outbound policy controls, and security constraints for future stdio execution.

Why

The main risk in MCP proxy support is not transport code but trust boundaries. A central MCP proxy can become a high-value target if upstream auth, tool exposure, or outbound execution are too permissive.

Deliverables

• Keep inbound auth and upstream auth configuration separate.
• Add explicit upstream auth modes or equivalent validated configuration paths.
• Enforce outbound URL validation and SSRF-safe remote target rules for upstream HTTP providers.
• Add allow/deny policy for exposed tools.
• Define the security model for stdio execution before enabling it by default.
• Add structured error taxonomy for upstream auth, timeout, discovery, and policy failures.

Acceptance criteria

• Unsafe remote URLs or forbidden targets are rejected by validation/policy.
• Upstream auth failures surface as typed errors without secret leakage.
• Tool exposure can be constrained by explicit policy.
• Stdio support remains disabled by default until its execution boundary is defined.

Suggested files

• src/core/errors.ts
• src/validation/
• src/types/profile.ts
• provider modules under src/
• security-focused tests

Agent-authored issue.

[github-actions]

🤖 Agent note (issuer)

Autonomy gate decision: unsafe
Reasons:

• issue includes explicit acceptance or validation structure
• issue matches high-risk keywords that should stay in a human lane