What IMDS is and why it matters
The Instance Metadata Service runs at169.254.169.254 on EC2 and Lightsail instances. Any process on the VM can request temporary credentials from this address if the instance has an IAM instance profile attached. For a containerized AI operator like Fox, unrestricted access means it could read the VM’s role, call AWS APIs, and perform actions under your cloud account.
What Vulpy installs
Vulpy adds annft reject rule that drops traffic to 169.254.169.254 for the host and for all containers. The lock is active by default because Fox ships without a Docker socket and without cloud credentials of its own. Blocking IMDS closes a path where Fox could otherwise inherit the VM’s identity.
Default behavior and how to check it
The lock is on by default.VULPY_IMDS_LOCK is set to 1 in your environment unless you override it.
Run the doctor command to verify the current state:
When to opt out
You should only disable the lock if Fox needs to use Amazon Bedrock through the VM’s IAM instance profile and you do not want to pass explicit AWS credentials. Set the variable before starting Fox:Preferred alternative: explicit credentials
Instead of opening IMDS to Fox, keep the lock on and pass explicit AWS keys as environment variables. This limits Fox to the exact permissions you define and keeps the metadata endpoint blocked for every other container on the host. See the AI providers page for how to configure Bedrock keys.Host egress lock
The IMDS rule is separate from host egress restrictions.pnpm vulpy hermes doctor reports both. If you see a failure on egress, review your firewall rules independently of the IMDS setting.
AI Providers
Configure Bedrock, OpenAI, and other providers with explicit keys instead of relying on VM roles.
Security
Review firewall rules, access modes, and hardening guidance for production deployments.