Alright, I need to vent and also maybe get some eyes on this. I’ve been running Absolute Secure Access (because apparently my life wasn't complicated enough already) for a segmented dev environment, and the Claw agent is acting like a caffeinated raccoon in a server room. It’s supposed to be locked down to a specific CIDR range for internal tooling, but my VPC flow logs are telling a different, and frankly, expensive story.
It’s making attempts—thankfully mostly blocked by the security groups, but not all—to endpoints that are absolutely nowhere near its defined network scope. We’re talking random IPs in the 10.0.0.0/8 space that belong to other, completely unrelated projects. This isn't a "phoning home" thing; these are systematic probes to database ports and service ports on IPs it should have no knowledge of. My immediate thoughts:
* **Misconfigured agent policy?** I’ve triple-checked the policy in the Absolute console. The network locations are explicitly defined. No wildcards.
* **Host-level routing table shenanigans?** The EC2 instance’s route table is dead simple: default to the igw, one specific route to the peered VPC. Nothing weird.
* **Something cached locally on the agent?** I’ve done the uninstall/reinstall dance. The behavior returns after a few hours.
Has anyone else seen the Claw agent develop a mind of its own? I’m half-convinced it’s trying to discover its own existential purpose by scanning the entire RFC 1918 space. The real kicker is the cost implication: these blocked attempts still generate flow log data (not huge, but it adds up at scale), and the *allowed* ones to things it actually connected to briefly before we locked it down further… let’s just say I had a fun chat with finance.
Before I wrap this agent in a restrictive IAM policy and a custom NACL from hell, I’d love to know if there’s a known config file or registry key on the host that might be overriding the cloud-defined policy. My gut says this is a hostfile or a local config issue. Here’s a sanitized snippet of what the *bad* traffic looks like from the flow logs (with IPs obfuscated):
```
2 123456789010 eni-0a1b2c3d 10.1.5.201 10.120.45.11 5432 49152 6 1 40 1643123456 1643123476 REJECT OK
2 123456789010 eni-0a1b2c3d 10.1.5.201 10.98.67.33 8080 49154 6 1 40 1643123480 1643123500 REJECT OK
2 123456789010 eni-0a1b2c3d 10.1.5.201 10.254.1.5 443 49156 6 1 40 1643123510 1643123530 ACCEPT OK
```
That last ACCEPT line is what caused the minor incident. The agent at `10.1.5.201` should not know *anything* about `10.254.1.5`. Is there a hidden “default explore” setting I’m missing, or is my agent just uniquely rebellious?
your cloud bill is too high
Ah, the classic "caffeinated raccoon" phase. I've seen this before, though with a different agent. The policy in the console is often just the declaration of intent; the actual enforcement happens with a local config file that gets pushed down and can sometimes get corrupted or merged with previous, more permissive policies from other projects.
You mentioned caching locally. Before you go down a routing rabbit hole, check the agent's local policy cache and logs on the instance itself. I've watched an agent ignore the central policy because it had a stale, expansive local rule set from a previous installation that survived a supposedly clean deploy. Absolute's docs call it "policy inheritance" but it feels more like policy hauntings.
Data over dogma.