Vaikora › Blog › Product Updates

Policy runs before the action, not after: how Vaikora enforces AI agent behavior at runtime

Product Updates · Nov 11, 2026 · 4 min read

The gap in most AI security programs is timing. Detection tools tell you what an agent did. Vaikora decides what the agent is allowed to do before the call goes out.

That distinction matters more than it sounds. Once an AI agent has exfiltrated a file, written to a production database, or run an external API call with sensitive parameters, logging the event is damage control. The question worth asking is: where was the control point, and did it fire before execution or after?

What "inline enforcement" actually means

Vaikora sits between the AI agent and whatever it is trying to reach, whether that is an LLM, a tool, a database query, or an external API. Every action the agent attempts passes through the Vaikora gateway first. The gateway evaluates the action against policy and returns one of four decisions: allow, block, modify, or require approval. The action does not execute until a decision is made.

This is different from an audit log you review later, or a monitoring layer that fires an alert after the fact. The enforcement happens inline, at the moment the agent attempts the action. P50 latency is 8ms; P99 is 45ms. For the vast majority of actions, the agent waits less than 10 milliseconds for a decision it cannot bypass.

Deterministic policy, not probabilistic guessing

One of the practical problems with model-based detection is inconsistency. The same input can produce different outputs depending on temperature, context, or model version. Vaikora policy is deterministic: identical input always produces an identical decision. That is not a minor implementation detail; it is what makes the system auditable.

A concrete example: you have an AI agent with access to a customer database and a file-write tool. You write a policy that blocks any action that includes fields tagged as PII unless the requesting identity has explicit approval. Every time the agent attempts to write customer records to an external path, the policy fires the same way. No drift, no edge cases that slip through on a Thursday afternoon.

Compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001 ship out of the box, so you are not writing policy from scratch for regulated workloads.

The audit chain

Every decision Vaikora makes is written to a SHA-256 hash-chained, tamper-evident audit log. This gives you an ordered, verifiable record of what every agent attempted and what the policy returned. If a decision is ever questioned, whether by an internal reviewer or an external auditor, you can prove exactly what happened and when.

That auditability is what separates runtime enforcement from runtime monitoring. Monitoring tells you what occurred. A tamper-evident audit chain tells you what was decided, what policy applied, and in what sequence, in a form that cannot be quietly edited afterward.

How it connects to your existing security stack

Vaikora integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity AI agent threats surface as incidents in those platforms without custom engineering.

Specific behavior worth knowing:

• Vaikora pushes AI agent threats into SentinelOne as Threat Intelligence indicators, severity-mapped at Critical=100, High=75, Medium=50, Low=25.
• High-severity risk promotes into Azure Security Center and Microsoft Defender for Cloud as native incidents automatically.
• It supports 12 LLM providers with no SDK migration, so you are not rewriting your agent code to add enforcement.

For teams that want to start without committing to a hosted product, Vaikora Guard MCP is the open-source, MIT-licensed, self-hostable component, published on PyPI as `vaikora-guard-mcp`. The enterprise control plane, hosted by Data443, adds centralized policy management, the full audit chain, and the SIEM integrations.

What to check in your current setup

If you are running AI agents in production today, the practical question is not whether you have logging. It is whether your controls run before execution or after.

Start by mapping what tools and APIs your agents can reach. Then ask: for each of those actions, is there a policy decision point that fires before the call goes out? If the answer is "we review logs" or "we have alerts," you have detection, not enforcement.

The enforcement gap is most visible in agentic workflows where the agent chains multiple tool calls autonomously. Each call in the chain is a potential policy decision that either fires before execution or does not fire at all. Check how many of those decisions your current setup actually makes in real time.

More from the Vaikora blog