Your AI guardrails are only as real as your runtime visibility

Ask a security team what AI is running in production and you get one of two answers. A list of approved vendors, or a spreadsheet assembled from a survey. Both describe intent. Neither describes what is executing.

That gap is where AI governance quietly fails. Not at the policy layer, which is where most of the attention goes, but at the evidence layer underneath it. Teams write down the models they approved, the agents they built, and the guardrails they switched on. Then the application runs, and nobody can confirm which of those things is actually true inside the process.

I made this argument recently in Forbes. The short version: a guardrail you cannot verify is an attestation. A guardrail standing on runtime evidence is a control. The distance between those two sentences is the entire problem.

Documentation describes intent. Runtime describes what executes.

Almost every AI inventory in use today is built from declarations, and declarations go stale the moment the system runs. A manifest shows that langchain is installed. It does not tell you whether an agent was ever instantiated, which tools that agent can call, or which model it binds at startup. A vendor console shows that content filtering is enabled on the account. It does not tell you that one service initializes its client with the filter set to off, which is the only state that matters when the call is made.

This is the same problem runtime intelligence solved for dependencies, arriving one layer up. A critical CVE in a package that never loads is not an operational risk. A guardrail configured in a dashboard but absent from the loaded process is not a control. In both cases the artifact on paper and the artifact in memory have drifted apart, and only one of them is real.

Agentic systems finish assembling themselves after the diagram is drawn.

The reason AI documentation decays faster than normal architecture documentation is that agentic systems are wired at runtime. An orchestrator spawns sub-agents. A tool registry expands through MCP after the process is already up. A capability arrives over a live connection that no code review ever saw, because it did not exist in the repository when the review happened.

Dormant capability is the part teams consistently miss. A refund sub-agent that is wired into production but has never fired is invisible to anything that watches activity, because there is no activity to watch. It is still there. It is still reachable. The first time it runs will not be a planned event. Unused AI capability is not a neutral fact, it is a finding, and it only shows up if you are reading what is loaded rather than what has been observed moving. This is the practical core of agentic AI security, and it is why activity-based tooling keeps producing clean reports for systems that are not clean.

Every current approach stops at the edge of the workload.

The tools most teams reach for are not wrong. They are positioned outside the boundary where agentic risk actually lives.

• Dependency and SBOM scanning detects installed AI frameworks and SDKs. It cannot say whether an agent exists, what its tool surface is, or which model it binds.
• Network and gateway inspection sees traffic to a model provider. It cannot see in-memory delegation between agents, file reads that feed model context, or the tool registry that defines what an agent is permitted to do. A large part of the agentic attack surface never becomes a packet.
• Code review and questionnaires capture intent at a point in time. They do not capture a tool surface that expands after deployment.

Locally served models make the gap concrete. An application running inference through Ollama, vLLM, or LocalAI never crosses the network boundary a gateway is watching, so from the gateway's perspective the model does not exist. In the research behind the Forbes piece, every platform we examined had openly reachable local inference instances, some of them already under automated exploitation. None of that traffic would have appeared in a model-provider log, because there was no provider.

A guardrail you cannot verify is an attestation. A guardrail on runtime evidence is a control.

Runtime visibility for AI means reading what is actually loaded in the running process, not what was declared about it. Five things have to come from evidence rather than from a form:

• Guardrails as loaded, with their category, level, direction, and action, which also exposes the agents that have none.
• The agent hierarchy and tool bindings, reconstructed from the process, including the delegation chain between an orchestrator and its sub-agents.
• Model provenance: where the model is served from, and for local models the file details, license, and digest.
• Running versus dormant state, so capability that is wired but idle is treated as a finding rather than as absence.
• Attribution, so an action belongs to the agent that originated it instead of to the workload as a whole.

This is what Kodem's runtime AI security is built on. AI Discovery reconstructs the live agent hierarchy from process memory and kernel signals, correlates every component back to the repo and image it ships from, and classifies what data can reach the model and where data can leave. The honest boundary matters here, and it is worth stating plainly rather than waiting to be asked: those dataflows describe reachable paths derived from how the agent is wired. They are not recorded traffic. The value is surfacing a path before it fires, not claiming we watched something move through it.

The resulting issues are scored from that evidence and mapped to the OWASP Top 10 for LLM applications, so untrusted content reaching a model reads as LLM01 and unbounded egress reads as LLM06. No CVSS theater, and no separate console for a security team to learn.

Identity is the missing control signal.

Here is what runtime evidence unlocks that an inventory never will. Most controls today see one workload with one identity, even when several decision makers live inside it: an orchestrator, a handful of sub-agents, deterministic application code, and occasionally an agent nobody declared. The same outbound call carries completely different risk depending on which of them originated it.

Once the agent hierarchy is reconstructed from memory, that action can be attributed to its agent of origin and to the delegation chain behind it, and policy stops being blunt. The refund agent may issue a refund after approval. The summarization agent, or an undeclared sub-agent, making the identical call is denied, and the service keeps running. That is the difference between a control that says this workload may or may not touch the refund system and one that says this agent, for this purpose, verified afterward.

The responses that follow are deliberately narrow: per-agent policy, allow and deny at the AI gateway, a targeted kill switch that preserves the rest of the service, and remediation verified by re-inspecting runtime state. Every one of them is validated before enforcement, scoped to the agent, reversible, and under customer control. None of them is prevention, and nobody should sell them that way. Worth being equally clear about the boundary: this replaces AI posture and inventory tooling. It does not replace an AI gateway, and it is not red teaming. It also does not require code changes, an SDK, or repository access, and the sensor deploys in approximately 5 minutes with meaningful runtime intelligence inside the hour.

Agents are not a new layer. They run in the same processes, the same memory, and the same blast radius as the applications you already own, which is why runtime application protection and AI governance are converging rather than splitting into two stacks. For the wider map of where this risk sits across the stack, our researcher's guide to AI application security covers the full picture.

The governance questions are not going to get easier. Boards, auditors, and customer questionnaires are already asking what AI runs in production and whether it is under control, and the surveys that answer them today will not survive contact with a regulator or an incident. The teams that come out of that well will not be the ones with the best-written policy. They will be the ones who can open a process and show which guardrails are loaded, which agents exist, and what each one can reach.

Frequently Asked Questions