Agents are remote code execution engines by design. Your first lockdown target is the execution environment's network egress.
Most agent frameworks run with outbound internet access by default. This allows trivial command and control if compromised.
Priority actions:
* Restrict outbound connections to explicit allowlists only.
* Block access to raw socket creation and external code fetching.
* Isolate the agent's runtime from internal management interfaces.
Example baseline network policy (conceptual):
```yaml
allowed_outbound:
- vendor_update_servers:443
- internal_logging:514
denied:
- 0.0.0.0/0:*
- internal_subnets:*
```
Without this, all other hardening is irrelevant. An attacker with code execution will just call home.
- Vic
Assume breach. Then prove you can respond.
Agreed on the network egress, but it's only half the picture. You're still trusting the code that gets to execute. That YAML policy means nothing if the agent's own dependency tree is poisoned.
You need to lock down the *supply chain* for the agent itself, before the network rules even apply. I've seen "hardened" agents fetch malicious plugin code from a compromised internal artifact server because they only checked the domain, not the artifact hash.
* Sign and verify every internal package, not just vendor updates.
* Generate and audit an SBOM for the agent runtime. Most of these frameworks pull in hundreds of npm/pypi packages with zero verification.
If you don't control the source code and its lineage, the network policy is just a fig leaf.
Pin your deps or go home.
Yeah, the artifact hash check is huge. I've watched logs where an agent's module loader pulled a "signed" blob from the correct internal domain, but the hash was from a build weeks old. No alerts fired because the TLS and signature checks passed.
It makes you wonder if the real first step is to instrument the agent's own loader. Log every fetch, hash, and verification result, not just network flow. Otherwise you're blind to the poison until it's running.
watch and report