Suggestion: Implement Network Boundary Security for Agent Endpoints

[RinZ27]

Ensuring that agents do not inadvertently interact with internal network resources is critical for maintaining a secure deployment environment. The current implementation of send_message_to_agent and AlmanacResolver allows an agent to resolve and attempt connections to any endpoint registered in the registry.

Maliciously registered agents could point to sensitive internal IP addresses (e.g., Cloud Metadata APIs at 169.254.169.254 or local administrative interfaces). Implementing a configurable denylist for internal IP ranges (RFC 1918) and loopback addresses by default would significantly enhance the security posture of the framework. This provides a necessary security boundary for production agents while allowing opt-in for local development.

Proposed improvement:

• Introduce a mechanism to validate and filter resolved endpoints before network requests.
• Add a global or per-agent configuration to enable/disable local network access.

[pshkv]

Good catch on the SSRF vector. Worth noting this is a specific instance of a broader gap: uAgents currently has no authorization layer between what a message says to do and what the agent is permitted to do.

The denylist for internal IPs is the right immediate fix. But the underlying issue is that send_message_to_agent and tool execution have no capability-scoping — any message can trigger any registered handler.

What a capability-based enforcement layer would look like here:

We built SINT Protocol to solve exactly this for physical AI agents, but the core PolicyGateway is framework-agnostic. The pattern:

Incoming message / tool call
        ↓
PolicyGateway.intercept(request)
  ├── Resolve capability token: what is this agent permitted to do?
  ├── Verify token: Ed25519 signature, expiry, resource scope
  ├── Assign tier: T0 (auto-allow) | T1 | T2 (review) | T3 (human sign-off)
  ├── Check constraints: rate limit, physical bounds, geofence
  └── Decision: allow | escalate | deny
        ↓
Handler executes only on "allow"

For uAgents specifically, the integration point would be:

1. A @fetchai/sint-bridge that wraps uAgent message handlers
2. Capability tokens scoped to agentverse://agent-address/protocol/action
3. The SSRF vector becomes: "does this agent's token authorize connecting to 169.254.169.254?" — answer is no by policy, not just by IP denylist

The IP denylist is a quick win — this would be the longer-term architecture. SINT's existing bridge-a2a already does this for A2A protocol messages.

The SINT platform we're building also uses uAgents (sint_chat_agent), so this is a concrete integration we'd be interested in developing. Is there appetite in the Fetch.ai team for a formal security middleware layer for uAgents?

[RinZ27]

While the capability-based layer proposed in #865 looks solid for long-term authorization, we still need the IP denylist as an immediate fix for the SSRF vector. I'd prioritize getting that boundary check in place now so we're not left exposed while the broader middleware architecture is being discussed.

[0xbrainkid]

The denylist for internal IP ranges is the right first-line defense — blocking RFC 1918 and loopback by default prevents the most common SSRF vectors without requiring per-agent configuration.

One layer that IP filtering alone cannot close: identity verification before endpoint resolution. A malicious registered agent can register an external IP that then proxies to internal resources — the denylist sees a clean external IP and allows the connection. This is the classic open redirect variant of SSRF.

A complementary check: before resolving and connecting to any Almanac-registered endpoint, verify that the agent registered at that endpoint has a behavioral trust score above a threshold. An agent that was registered recently with zero interaction history pointing to an unusual endpoint pattern is a risk signal — behavioral trust (not just IP filtering) catches this class of attack.

async def resolve_and_connect(agent_address: str, config: SecurityConfig):
    # Existing: IP denylist check
    endpoint = await almanac.resolve(agent_address)
    validate_ip_not_internal(endpoint)  
    
    # Proposed: behavioral trust gate
    trust = await satp.get_score(agent_address)
    if trust.score < config.min_endpoint_trust:
        raise UntrustedEndpointError(
            f"Agent {agent_address} trust score {trust.score} below threshold. "
            f"Registration age: {trust.registration_age_days}d, "
            f"Interactions: {trust.interaction_count}"
        )
    
    return await connect(endpoint)

The two checks are complementary: IP filtering blocks known-bad destination ranges, trust gating blocks unknown-but-suspicious agents regardless of destination.

[RinZ27]

@pshkv @0xbrainkid Thanks for the valuable insights. I agree that IP denylisting is the most immediate first step we can take. I've submitted a PR (#874) implementing this layer in the AlmanacResolver to handle core SSRF risks while we continue discussing more complex security architectures.