Vaikora › Blog › Product Updates

Vaikora enforces an allow, block, modify, or approve decision on every AI agent action before it executes

Product Updates · Nov 10, 2026 · 4 min read

When an AI agent makes a bad call, the damage is usually done before anyone notices. The agent already wrote the file, already queried the database, already sent the API request. Detection after the fact tells you what happened. It does not undo it.

Vaikora sits inline between the agent and whatever it is calling, whether that is an LLM, a tool, or an external API. Every action passes through a policy gate before execution. That gate produces one of four outcomes: allow, block, modify, or require approval. If the action does not get a decision, it does not run.

Why placement matters

Most agent security approaches operate at the edges. They log what happened, alert on anomalies, or scan outputs after generation. All of that has value, but none of it stops execution.

The difference with an inline, pre-execution gate is determinism. Vaikora checks every action against policy before the action runs, and identical input always produces an identical decision. There is no probabilistic judgment call at enforcement time. The policy says what happens, and that is what happens.

At P50, enforcement adds 8ms of latency. At P99, it is 45ms. At 10,000+ actions per second, the gate does not become the bottleneck in production workloads.

What the enforcement decision covers

Before an action executes, Vaikora runs it through six content inspection modules. These check for things like data classification violations, credential exposure, prompt injection patterns, and policy conditions tied to the specific tool or API being called.

A concrete example: an agent is processing a support ticket and calls a tool to look up customer records. The agent's prompt has been injected with an instruction to exfiltrate results to an external endpoint. Vaikora inspects the tool call before it runs, detects the anomalous destination and the payload pattern, and blocks the action. The injected instruction never reaches execution.

The same gate handles modify decisions, where Vaikora rewrites a request to strip a sensitive field before it leaves, and require-approval decisions, where a human must confirm before the action runs. These are not just logging states. They change what actually executes.

Auditability that holds up

Every decision Vaikora makes is written to a SHA-256 hash-chained, tamper-evident audit log. Each entry is signed into an ordered chain, so you can prove not just what decision was made but that the record has not been altered since.

For compliance purposes, this matters. Audit trails that can be selectively edited are not audit trails. The hash chain means any modification to a past record breaks the chain and is detectable.

Vaikora ships compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001. These are not checkbox labels. Each preset loads a specific policy configuration, so an organization operating under HIPAA does not have to manually map regulation to policy rules.

What it connects to

Vaikora supports 12 LLM providers with no SDK migration. You point your existing agent at the Vaikora gateway instead of directly at the model endpoint. The agent code does not change.

On the SIEM and XDR side, Vaikora integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. AI agent threats push 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, without custom engineering.

Vaikora also adds a runtime gate on top of Azure RBAC, AWS IAM, and Snowflake roles. It does not replace them. It enforces an additional policy layer that those identity controls cannot apply, because they evaluate permissions, not intent or content.

Where to start

The open-source component, Vaikora Guard MCP (published on PyPI as `vaikora-guard-mcp`, MIT-licensed, written in Python), is the fastest path to seeing enforcement in your own environment. Install it, configure a policy, and route a single agent through it. Watch what the audit log produces.

If your agents are already running in production and you have not yet placed a pre-execution gate on tool calls, that is the specific gap to close. Start with the tool calls that touch external systems or sensitive data first. Those are where a blocked or modified action would have had real consequences.

More from the Vaikora blog