Why agents in containers are hard to identify
Every container app has some configuration or details about what’s running inside.
There are roughly three places to look. From the easiest to the most difficult, they are:
The app's configuration.
Cloud inventories list every app and its settings. Settings can hint at the language an app is written in, but rarely at what it does.
The container image.
The image is the packaged program itself, stored on a registry/repository somewhere.
The running app.
When the first two cannot give an answer, a live, read-only look at the running app might help.
Each layer brings its own challenges:
· App configuration usually contains little evidence other than the environment the app lives in.
· Images can be hosted in many places. Sometimes it’s simple and the container may be pulling images from an ‘Azure container registry’ so everything is in the same subscription. Often, in multi cloud instances, the image could be in a code repository or docker hub.
· Image file size can get quite large, which can be expensive and time consuming to scan, especially at scale.
· Some images are a single packaged file, so cannot be inspected at all.
You cannot govern what you cannot see
AI Governance means setting rules for what an agent may do, then checking that it keeps to them. Every part of that depends on detecting the agent exists.
• No owner. It’s difficult to tell who is responsible for the output of the agent.
• No rules applied. Policies such as "this agent may not delete files" only work on agents they are attached to. A hidden agent runs with no rules and guardrails at all.
• No record. An agent in a container may not be writing logs, so a rogue agent cannot be traced.
• Scope drift. Container apps can be updated often, sometimes by the developer responsible for the app. A new version can include a new tool, new instructions, or a more expensive model.
Read only AI discovery comes first
The first step organizations are taking is to look over the SDK’s being used by the container apps. There are many agent SDK’s, such as Microsoft Agent Framework, LangChain and Strands, to name just a few.
Evidence of this is almost a guarantee there is something agentic in the app.
However, as Outerlimit has seen in real environments, not all agents declare their framework, and many times you only see the runtime and actions.
AI observation comes next
Once you have identified ‘suspicious’ containers, the next step is to confirm the presence of an agent.
Some organizations work backwards from the model provider to find the source caller.
Some may try and edit the image of the agent to output telemetry, which requires getting every developer to re-write their code.
The best method is to intercept the tool call. An agent is only risky if it can interact with the real world via tools.
Observability leads to enforcement
Once you’ve observed what the agent is doing, you can decide to block or allow its interactions with the real world. Some may try and inject guardrails, prompt evals, or other traditional methods.
Outerlimit’s approach of enforcing security at the point of execution both guarantees alignment with your policy, and the identity of the agent calling the tool.
What are the risks of these containerized agents?
Organizations naturally have controls on who can deploy resources in Azure, but the team spinning up the container may not have oversight of the image being run. At scale, this can become a real risk when left unmanaged.
Outerlimit has spoken to teams who not only have large container apps environments, but also have little to no visibility on which might be agents.
To request a demo of how Outerlimit can discover, observe, and enforce run time controls on container agents, click here.
