Mapping production AI agents to IAM roles, tools, and network exposure

Mapping production AI agents to IAM roles, tools, and network exposure | Cartography Blog ← Back to blog Mapping production AI agents to IAM roles, tools, and network exposure March 12, 2026 · Alex Chantavy Everyone is excited about AI agents because of what they can do on their own, but if you look at what an agent actually is at the infrastructure level, it looks a lot like a microservice : It reads and writes to storage It's connected to the network It runs on compute It executes tools using permissions tied to an identity It talks to other agents As an industry we've mostly solved microservice visibility with cloud APIs, service meshes, distributed tracing, and SBOMs. However, things are still incredibly early with AI. Most teams aren't tracking which of their services run AI agents, what tools those agents have declared, what IAM roles they assume, or whether they're exposed to the internet; The capabilities to do this broadly just aren't there yet. This means that when there is an incident, there's no fast way to enumerate the agents that are affected or what they can reach. We're thrilled to share that open source Cartography can now answer all of these questions . We scan container images for AI components - agents, models, tools, memory, prompts - and map them directly into the infrastructure graph alongside everything else Cartography already tracks. Because this is built in open source, teams can inspect the schema, run the queries themselves, and extend the data model as the agent ecosystem evolves. The query If you skip through the rest of this post, just read this. This single query answers the question: which AI agents are reachable from the internet, at what DNS name, using what IAM role, using which LLM and tools? MATCH (agent:AIAgent) - [: DETECTED_IN ] -> (img:ECRImage) <- [: HAS_IMAGE ] - (:ECSContainer) <- [: HAS_CONTAINER ] - (task:ECSTask) - [: HAS_TASK_DEFINITION ] -> (:ECSTaskDefinition) - [: HAS_TASK_ROLE ] -> (role:AWSRole) MATCH (task) - [: NETWORK_INTERFACE ] -> (:NetworkInterface) - [: PRIVATE_IP_ADDRESS ] -> (:EC2PrivateIp) <- [: EXPOSE ] - (lb:AWSLoadBalancerV2) <- [: DNS_POINTS_TO ] - (dns:AWSDNSRecord) OPTIONAL MATCH (agent) - [: USES_TOOL ] -> (tool:AITool) OPTIONAL MATCH (agent) - [: USES_MODEL ] -> (model:AIModel) RETURN agent.name, agent.framework, dns.name AS fqdn, role.arn AS iam_role, collect ( DISTINCT tool.name) AS tools, collect ( DISTINCT model.name) AS models This traverses from the AI agent detected inside a container image , through the ECS task running it, to the IAM role it assumes and the load balancer and DNS record that expose it to the internet. We use scanners to find the agent, AWS APIs to find the surrounding infrastructure, and Cartography to connect them in the same graph. Why this matters The agent discovery ecosystem today feels a lot like container security in the 2010s. The EU AI Act and NIST AI RMF are pushing organizations toward maintaining inventories of the AI systems they operate. You can't govern what you can't see, and you can't assess the blast radius of an agent you don't know exists. Agents in production are different from traditional apps because they are designed to be helpful and adaptive, so they may make use of whatever resources, permissions, and tools available to them. On the other hand, a traditional application is constrained by the logic its devs explicitly coded into it. For it to go off the rails, it would have to be compromised by an attacker; I talked about this in this video . We're paying a lot of attention to this space because so little of the security and governance infrastructure exists yet. The goal is straightforward: help organizations adopt AI with more confidence because they can understand and control what they're running. We're using old graph techniques to get a handle on modern problems :). How this works The first step is figuring out what's inside the container. We use Cisco's AIBOM scanner to analyze container images and detect agents by framework ( pydantic_ai , langchain , openai , and others), down to the file path and line number - special thanks to the maintainers! It picks up declared tools, models, memory, embeddings, and prompts. Each component becomes an AIBOMComponent node in the Cartography graph, with agents getting an additional AIAgent label, connected to ECRImage nodes via manifest digest. The second step is figuring out where the image is running, and this is just stock Cartography: ECR images link to ECS containers ECS containers link to ECS tasks ECS tasks link to network interfaces, subnets, VPCs, security groups, load balancers, and DNS records The third step is figuring out what the agent can actually do from an infra perspective. This is also stock Cartography: ECS tasks link to task definitions Task definitions link to IAM roles and their attached policies On the AI side, agents link to their declared tools, models, and multi-agent workflows. The combination of IAM permissions and declared tool integrations is the agent's real capability set. The key join is manifest_digest between AIBOM scan results and ECR images. This forms a bridge between "what's in the image" and "where it runs in your cloud". Notably, this doesn't require adopting any specialized infrastructure like AI gateways or similar. This approach works against container images you've already built and cloud infra you've already deployed. Queries this unlocks Which agents are reachable from the internet, and have access to read from a storage bucket? MATCH (agent:AIAgent) - [: DETECTED_IN ] -> (:ECRImage) <- [: HAS_IMAGE ] - (c:ECSContainer { exposed_internet : true } ) <- [: HAS_CONTAINER ] - (task:ECSTask) - [: HAS_TASK_DEFINITION ] -> (:ECSTaskDefinition) - [: HAS_TASK_ROLE ] -> (role:AWSRole) - [: CAN_READ ] -> (bucket:S3Bucket) RETURN agent.name, role.arn, bucket.name Show me all agents reachable at *.mycompany.com: MATCH (dns:AWSDNSRecord) - [: DNS_POINTS_TO ] -> (lb:AWSLoadBalancerV2) - [: EXPOSE ] -> (:EC2PrivateIp) <- [: PRIVATE_IP_ADDRESS ] - (:NetworkInterface) <- [: NETWORK_INTERFACE ] - (task:ECSTask) - [: HAS_CONTAINER ] -> (:ECSContainer) - [: HAS_IMAGE ] -> (img:ECRImage) <- [: DETECTED_IN ] - (agent:AIAgent) WHERE dns.name ENDS WITH '.mycompany.com' RETURN dns.name, agent.name, agent.framework Things are early and we are excited We're quickly adding support to discover agents and correlate them to more pieces of infrastructure beyond AWS ECS. Now that the data is in the graph, we can also build Cartography security rules that alert when an agent violates governance policies, such as an agent with no tool restrictions or one using an unapproved model provider. Try it out on your environment - Cartography is here , and PRs are always welcome. Join the Slack community . This space is still early, and we think open source is the right place to build this. We’d love feedback, contributions, and help shaping where it goes next! 2025 © Cartography Project Authors. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page .