Why your scanner can't see your AI agents

Short answer: scanners inspect static artifacts — packages, container images, SBOMs. AI agents act at runtime, through prompts and tool calls that leave no package entry to scan. The attack surface is behavioural, not structural, and it needs a different kind of visibility.

Your vulnerability scanner has a mental model: find known CVEs in installed software. It's a good mental model for a lot of threats. But an AI agent doesn't introduce risk by having a dependency with a known CVE. It introduces risk by having access to tools, data, and systems — and by processing inputs that can manipulate it into misusing that access.

The scanner looks at the packages. The agent's risk lives in what it can call.

What the scanner sees — and what it misses

A scanner reads your container image or SBOM, maps packages against a CVE database, and reports findings. That's useful and you should keep doing it. But an AI agent's risk surface is largely invisible to this process:

• Which tools does the agent have access to — and with what permissions?
• Can an injected prompt in a user message cause the agent to exfiltrate data?
• Does the agent's memory persist across sessions in a way that leaks context?
• Can the agent be made to call external endpoints by a malicious document it processes?

None of these appear in a CVE database. They're architecture decisions — identity, tool scope, memory design — that create risk at runtime.

What "AI runtime security" actually involves

Treating the AI runtime as a security layer means answering four questions continuously:

• What can each agent reach? Map tool permissions and data access the same way you'd map a service account's blast radius.
• What inputs can manipulate it? Track prompt injection vectors — user inputs, retrieved documents, web content — that route through the agent before it acts.
• What does it log? Ensure every tool call is observable; silent agents are ungoverned agents.
• Who owns it? An agent without an owner and a rotation policy is an orphaned identity waiting to be exploited.

The shift left argument doesn't quite apply

For traditional software, catching vulnerabilities at design time is dramatically cheaper than at production. The same is true for AI agents — but the design decisions that matter are different. It's not "did we use a vulnerable library?" It's "did we scope this agent's tool access to the minimum it needs?" Those decisions happen in architecture, not in a CVE database.