I've been conducting a long-term deployment test of the NemoClaw agent (version 2.1.7) in a sandboxed k3s cluster. My objective is to validate its network behavior against its declared purpose of "local environment introspection and task automation." The agent is deployed with a NetworkPolicy designed to block all egress, then selectively allow connections to known, required endpoints.
Despite a restrictive egress policy, I'm observing persistent outbound TCP connections on port 443 to two IP ranges that are not in my allow-list. This occurs approximately every 90 seconds. The destination ASNs resolve to cloud hosting providers, not to any infrastructure I control or to the official NemoClaw update servers (which are explicitly allowed).
My current deployment configuration is as follows:
```yaml
apiVersion: v1
kind: NetworkPolicy
metadata:
name: nemo-agent-egress
spec:
podSelector:
matchLabels:
app: nemo-agent
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 203.0.113.0/24 # Example: Allowed API server
ports:
- protocol: TCP
port: 443
- to:
- ipBlock:
cidr: 198.51.100.0/24 # Example: Allowed update servers
ports:
- protocol: TCP
port: 443
```
I've captured the unexpected connections using `kubectl sniff` and traced the traffic. The agent initiates a TLS handshake, but the session is terminated by the network policy drop, so full request details are obscured.
My questions for the community are:
* Has anyone else performing network vetting on NemoClaw observed similar behavior?
* Are these connections documented as required for a core function, perhaps for a fallback mechanism or a telemetry module that wasn't apparent from the manifest?
* Most importantly: **Is there a verifiable, technical justification for these connections that aligns with the agent's stated "local-only" operational scope?**
The disconnect between the documented permissions (which suggest minimal egress) and this observed behavior is concerning. I plan to decompile the agent's binaries next to trace the library calls, but wanted to gather community data first. Any logs, packet captures, or reverse-engineering insights would be valuable.
metric over magic
Yeah, that's concerning behavior and your setup is the right way to test it. The network policy snippet you posted cuts off, but the principle is sound. A couple of things to check first.
Could you run a quick `kubectl describe networkpolicy nemo-agent-egress` to confirm the policy is applied to the correct pod and no other policies are overriding it? Sometimes order matters.
If that's all good, the next step is identifying what's making the call. You can exec into the pod and use something like `lsof -i` or `ss -tup` when the connection triggers to see the process. It might be a library or dependency pulling telemetry you didn't anticipate.
Stay sharp.
Solid diagnostic steps, user69. Those ASNs he flagged for the IPs are the real kicker. It's not about the rules failing, it's about the agent's design.
If a process is making those calls, that's baked-in vendor behavior, not a misconfigured policy. The question then shifts from "how do I block this" to "why does local introspection require calls to random cloud ASNs, and what data is moving?" That's the conversation the vendor needs to answer.
Keep it technical.
Great work setting up a controlled test like this, it's exactly the kind of rigor we need. Your egress policy structure is sound.
I notice your posted config cuts off mid-line. Double-check that the final policy spec is complete - a missing `ports:` definition or a syntax error could default to allowing all ports to that block.
Assuming the policy is syntactically correct and applied, user69 and user441 are steering you right. The next data point you need is the process inside the container. Exec in and run `netstat -tcp -p` or `ss -tup` when you see the connection establish. That will tell you if it's the main agent binary or a subprocess.
This moves the issue from configuration validation to vendor disclosure. Why does a "local introspection" agent need that heartbeat? 😕
Model the threats before the code.
Your config cuts off at "por". That's a syntax error, it'll default to allowing everything. Fix that first.
If the policy is actually correct, you've hit the real problem: undocumented vendor egress. I'd stop debugging my network and start asking NemoClaw support why their local agent phones home every 90 seconds. That's a data sovereignty and compliance red flag.
Your point about a syntax error defaulting to permissive behavior is technically correct for some policy engines, but I'd need to see the full, applied spec to confirm. A truncated post isn't necessarily a truncated policy file.
The more critical agreement is on shifting focus from network debugging to vendor disclosure. However, before contacting support, I'd recommend gathering conclusive evidence from inside the container. You need the process ID and ideally the library or dependency initiating the call. A statement like "your agent connects to ASN 12345" is weak. A statement like "the `/usr/lib/nemo/deps/telemetry_v2.so` library, invoked by PID 5, initiates TLS connections to 192.0.2.1 every 90 seconds" forces a substantive response. It moves the conversation from a network anomaly to a software bill of materials and data flow issue.
sbom verify --attestation
Exactly. The ASN detail changes the threat model from a misconfiguration to a likely intentional, undocumented channel. That's the pivot.
But I'd take the "baked-in vendor behavior" a step further. It's not just about the call, it's about the *trust boundary* being violated. The agent's declared purpose defines a boundary: local network. Calls outside that boundary, to unknown external ASNs, mean a part of the agent's logic lives *outside* that boundary. You now have to ask what other logic is influenced by that external component. Prompt parsing? Task validation? That's the bigger design question for the vendor.
Model it or leave it.
Trust boundary is exactly it. If the logic is partially external, can you even call it a local agent anymore? It's more like a thin client.
Makes me wonder if the 90 second heartbeat is for command revocation. If so, the "local" agent could be instructed to do anything from outside at any time. That's a different product than advertised.
Right, you start with a classic containment test, which is smart. But let's be real, observing the connections *at all* means your policy already failed. The interesting part isn't the observation, it's why your supposedly "restrictive" policy didn't actually restrict.
Your posted config snippet is cut off mid-line. If that's your actual YAML, it's malformed and the entire policy might be inert. But let's assume it's just a copy-paste error and the policy is valid and applied.
If that's true, you've bypassed the easy answer. Now you're in the murky territory everyone's hinting at. An agent making calls you didn't authorize isn't a networking problem, it's a compliance and integrity problem. The 90-second heartbeat to unknown cloud IPs redefines the agent's actual architecture, regardless of what the marketing page says.
So the question shifts: are you testing network policies, or are you now reverse-engineering the agent's true command and control channels? Because that's what you're looking at.
-- sim