# Cloud Metadata Credential Endpoint In Agent Tool Call

- **Severity:** High
- **Signature ID:** `7b3c1f2a-9d64-4e58-b0a7-3f5c8e21d94b`
- **MITRE ATLAS:** AML.T0024 (Exfiltration via AI Inference API)

## Summary

This detects when an AI agent is instructed to make a network request to a cloud provider's instance metadata service, which hosts sensitive credentials. It catches the intent before the request is even sent, including attempts to disguise the target address.

## How the attack works

An attacker (often via prompt injection) gets an AI agent to call a tool that combines two things: a way to make an HTTP request (curl, wget, a URL argument, an HTTP client) and the address of a cloud metadata credential endpoint — for example AWS's 169.254.169.254, GCP's metadata.google.internal, Azure IMDS, ECS/EKS task-credential endpoints, or Alibaba's metadata service. The address may be disguised using decimal, hex, octal, IPv6, or percent-encoded forms so it never appears as the obvious literal string. If successful, the request returns temporary cloud credentials or identity tokens tied to the host or container running the agent. The rule flags this at the moment the agent is told to make the call, before the request goes out, so it still catches attempts that fail, time out, or are blocked downstream.

## Why it matters

If the request succeeds, the attacker obtains live cloud credentials or tokens scoped to the machine or container the agent runs on, which can then be used to access other cloud resources, data, or services under that identity.

## What you can do

- Restrict or block outbound network access from AI agent execution environments to metadata IP ranges and hostnames unless explicitly required.
- Where possible, use metadata service versions or configurations that require session tokens (e.g. AWS IMDSv2) to reduce the value of a bare credential fetch.
- Review agent tool definitions to limit which tools can make arbitrary HTTP requests, and require human approval for tool calls with network arguments.
- Treat any agent instruction to fetch a metadata endpoint as suspicious unless it matches known legitimate operator workflows like host debugging or infrastructure-as-code authoring.

## Known benign look-alikes

- An operator legitimately asking the agent to debug a cloud host, e.g. "curl http://169.254.169.254/latest/meta-data/instance-id" — genuinely common on EC2/GCE and the primary reason this rule is report-only rather than blocking.
- Authoring or editing cloud-init user-data, Terraform, Ansible, Packer or container entrypoint scripts that read instance identity at boot.
- Writing or editing detection content (Sigma, Falco, Suricata) that must embed the metadata address — suppressed by filter_detection_authoring.
- Unit tests and mocked IMDS responses that hard-code the endpoint — suppressed by filter_test_or_docs_path.
- Hardening work that disables IMDSv1 or lowers the hop limit — suppressed by filter_imds_hardening.
- Runbooks or troubleshooting notes in a /docs or /examples tree that quote a metadata curl command.

## References

- https://attack.mitre.org/techniques/T1552/005/
- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
- https://cloud.google.com/compute/docs/metadata/overview

---
Source: https://www.netzilo.com/threats/cloud-metadata-tool-call-obfuscated