Introducing AI agent policy enforcement

Today we are bringing policy enforcement to Kodem Runtime AI Security.

Kodem already shows you every agent running inside your applications and everything it can reach. Now you can decide what each one is allowed to do, and Kodem holds it there: per agent, per tool, at runtime.

When an agent or tool steps outside its policy, the action is denied. The rest of the service keeps running. Every block comes with the evidence to explain it, down to the line of code that made the attempt.

Agents need identities, not just inventories

Most controls see one workload with one identity. Agentic applications do not work that way. A single service can hold an orchestrator, several sub-agents, deterministic code, and tools that arrived at runtime over MCP. The same API call carries different risk depending on which of them made it.

A gateway sees the call. It cannot see who inside the process made it. So teams are left with two bad options: let the whole service do everything, or switch the capability off for everyone.

Kodem reconstructs the agent hierarchy from process memory. That gives every action an origin: the agent that started it, the delegation chain behind it, and the tool that executed it. Identity is the missing control signal. Kodem has it.

Policy starts from evidence

You do not write policy from a blank page. Kodem combines AI runtime discovery, which shows what is loaded and how it is wired, with code analysis, which shows what each tool was written to do. Together they produce an intended-behavior envelope for every tool, model binding, and network destination.

From there, you scope three surfaces:

• Models. Which models each agent may bind. The model allow-list becomes an enforced control, not a report.
• Network destinations. Where each tool may connect.
• Tools. Which tools each agent may invoke, and under what conditions.

Policies express what no inventory can. The refund agent may issue a refund after approval. A summary agent, or an unknown sub-agent, making the same call is denied.

Enforcement works by envelope, not by signature

Here is what that looks like. A tool called summarize_ticket reads support tickets and passes them to a model. Its policy allows no outbound network. One day it tries to open a connection to an endpoint it was never meant to reach. Kodem denies it.

The connection is denied because it falls outside the tool's policy, not because Kodem recognized an attack. There is no signature to be missing and no earlier sighting to depend on. Every other tool keeps its approved access, and the service keeps answering customers.

That granularity is the point. A per-workload control can only say a service reaches the internet or it does not. Kodem can take one destination away from one tool.

Every block explains itself

A block nobody can explain is a block that gets turned off. Each denied action carries:

• A timeline linking the request, the tool call, the attempted connection, and the policy that applied
• A block reason, stated as the rule that was broken
• A call stack pointing to the code responsible, so engineers fix the cause instead of re-tuning the control

The call stack is the piece a gateway cannot produce. Kodem can, because it sits inside the process, the same position that makes discovery work.

Built to be trusted with production

Enforcement only matters if teams are willing to turn it on. Every policy is validated against observed runtime state before it enforces. It is scoped to a single agent, tool, or destination. It is reversible. And it is authored and approved by your team. An action inside a permitted envelope is permitted.

This is a control model, not a promise that nothing can go wrong. It narrows what each agent can do to what it should do, and shows its work every time it acts. It also sits alongside runtime application defense, which does a different job: detecting exploit behavior in progress.

Available now

Policy enforcement is available in Kodem Runtime AI Security, alongside AI runtime discovery and AI Risk issues mapped to the OWASP Top 10 for LLM applications. It runs on the same in-host sensor and the same runtime intelligence Kodem already uses across your applications. No code changes, no SDK, no gateway.

See every agent. Decide what it may do. Know when it tries something else.

To see it on your own workloads, book a session with a security engineer.