RemoteA2aAgent enforces HTTPS for agent cards, blocking plaintext A2A inside a service mesh (mTLS)

What happened

RemoteA2aAgent enforces that an agent card's URL — and every RPC target URL inside the resolved card — must be https, unless the host is loopback. This is enforced client-side in src/google/adk/agents/remote_a2a_agent.py (ADK 2.9.1):

• _resolve_agent_card() rejects a non-loopback http:// card source URL with:

  Agent card URL must use https, or http on a loopback host: <url>

• _validate_card_rpc_targets() rejects a resolved card whose RPC target URLs are non-loopback http:// with:

  Agent card RPC URL must use https, or http on a loopback host: <url>

(_is_loopback_host() only permits localhost, *.localhost, and loopback IPs.) There doesn't appear to be an opt-out (flag, config field, or env var).

Why this is a problem: A2A inside a service mesh (mTLS)

A very common production topology for multi-agent A2A is Kubernetes + a service mesh (Istio / Cloud Service Mesh, Linkerd) with STRICT mTLS. In that model:

• The application speaks plaintext http:// to the peer's in-cluster DNS name (e.g. http://research.agents.svc.cluster.local/a2a/app/...).
• The sidecar proxy transparently upgrades every hop to mTLS, and authorization is enforced by mesh identity (SPIFFE) + AuthorizationPolicy.

This is the mesh's entire design: apps stay plaintext, the mesh provides confidentiality + peer authentication. But ADK's client-side gate refuses plaintext to non-loopback hosts, so the first delegation fails at card resolution with AgentCardResolutionError. The security property the https requirement stands in for (no plaintext MITM) is already guaranteed by the mesh — so the gate is redundant here, yet there's no way to say so.

Minimal repro

from google.adk.agents.remote_a2a_agent import RemoteA2aAgent

# Non-loopback http card URL — realistic in-cluster A2A address behind a mesh.
agent = RemoteA2aAgent(
    name="research",
    agent_card="http://research.agents.svc.cluster.local/a2a/app/.well-known/agent-card.json",
)
# On first use -> AgentCardResolutionError:
#   "Agent card URL must use https, or http on a loopback host: ..."

The underlying transport is fine with http — only this ADK-level check blocks it.

Current workaround (and why it's not great)

Passing a pre-constructed AgentCard object (rather than a URL/file source) skips both checks — _validate_card_rpc_targets() returns early when there is no http(s) source, and _resolve_agent_card() is never called — so the plaintext POST then flows and the mesh wraps it in mTLS. But this forces callers to give up ADK's lazy live-card fetch and hand-build/hard-code the card + RPC URL, which is exactly the discovery ADK otherwise does for you.

What we'd like to discuss

Would the maintainers be open to an opt-in escape hatch so operators who know they're inside a trusted transport (a mesh) can allow non-loopback http? A few shapes, from least to most granular:

1. A per-instance flag, e.g. RemoteA2aAgent(..., allow_insecure_http=True) (or on A2aRemoteAgentConfig), applied to both the card fetch and the RPC-target validation.
2. An env / global toggle (e.g. ADK_A2A_ALLOW_INSECURE_HTTP=1) for cluster-wide deployments.
3. A configurable trusted-host / CIDR allowlist that widens the loopback carve-out.

Opt-in (default stays https-only) keeps the secure-by-default behavior while unblocking the mesh use case. Happy to send a PR if you can point me at the preferred shape.

Environment

• google-adk 2.9.1
• Deployment: GKE + Cloud Service Mesh (managed Istio), namespace-wide STRICT PeerAuthentication
• A2A over RemoteA2aAgent with in-cluster DNS peer URLs