FORGE-1: opt-in workflow auto-propagation for downstream tool calls

[initializ-mk]

Context

Cross-repo epic: thread workflow_id / workflow_execution_id end-to-end through the orchestrator → agent → downstream-agent chain.

Today Forge has WorkflowContextFromContext(ctx).ApplyToHTTPHeaders(req.Header) but it's manual per tool. The skill calls out that auto-propagation is deliberately off to avoid leaking workflow identity to third-party APIs.

The consequence: when Agent A (called by an orchestrator with X-Workflow-Id) calls Agent B as a tool, the workflow headers don't propagate unless Agent A's tool code explicitly calls ApplyToHTTPHeaders(). Each downstream agent generates a fresh correlation_id, and the workflow trace fragments at every agent-to-agent hop.

Scope

Add an allow-list mechanism in forge.yaml so an agent author can mark which downstream destinations should auto-receive the workflow headers. Same shape as the existing egress allow-list — host patterns with wildcard support.

forge.yaml addition (proposed)

workflow_propagation:
  allowed_hosts:
    - \"*.agents.internal\"      # propagate to any internal A2A peer
    - \"orchestrator.svc\"

Behaviour

• HTTP tools targeting a host that matches workflow_propagation.allowed_hosts automatically have X-Workflow-Id, X-Workflow-Execution-Id, X-Workflow-Stage-Id, X-Workflow-Step-Id, X-Invocation-Caller applied via the existing ApplyToHTTPHeaders machinery.
• Hosts not in the list: existing opt-in behaviour (explicit ApplyToHTTPHeaders call required).
• Default (no workflow_propagation block): opt-in only, current behaviour.

Code changes

• Extend forge.yaml schema with the workflow_propagation block.
• Add a host-matcher (reuse the egress allow-list wildcard logic if possible).
• Hook into the HTTP tool dispatch path: before issuing the request, check the host against the allow-list and apply headers if it matches.

Dependency

Blocked on FORGE-2 (the header rename) — apply the new header set, not the old X-Workflow-Id-as-run semantics.

Test plan

• Unit test the host matcher: exact match, wildcard match, no match.
• Integration test: tool call to allow-listed host → headers present in the outbound request; tool call to non-allow-listed host → headers absent.
• Audit verification: the downstream agent's events carry the parent's workflow_id / workflow_execution_id when called through an allow-listed host.

Why opt-in stays the default

The skill is right that blanket propagation leaks workflow identity to third-party APIs. The allow-list keeps the safe default while removing the manual per-tool friction inside the trust boundary.