Vaikora › Blog › Product Updates

Eight milliseconds to block or allow: how Vaikora makes an enforcement decision before an AI agent acts

Product Updates · Nov 6, 2026 · 4 min read

The practical question for any team deploying AI agents in production is not whether a bad action is possible. It is whether you can stop it before it executes. Vaikora sits inline between the agent and every LLM call or tool invocation, and it completes an allow, block, modify, or require-approval decision at P50 in 8ms and P99 in 45ms.

That timing matters because the alternative is detection after the fact. Post-execution detection tells you what happened. Inline enforcement at those latencies tells the agent what it may do next.

What "inline enforcement" actually means

When an AI agent issues a tool call or sends a prompt to an LLM, that request hits the Vaikora gateway before it reaches the model or the downstream API. The gateway runs six content inspection modules against the payload. It checks the request against the policies configured in the control plane and returns one of four verdicts: allow, block, modify, or require-approval.

The agent either gets its result or it gets a denial. It never touches the resource it was not supposed to touch.

This is deterministic: identical input always produces the same decision. There is no probabilistic scoring that might go differently on a retry. The policy is a policy, not a suggestion weighted by confidence.

What can trigger a block

Policy conditions can be as specific as your threat model requires. Common examples:

• An agent prompt containing PII that is about to be sent to an external model endpoint not in your approved list
• A tool call attempting a database write when the session context indicates read-only should apply
• A request pattern matching a known prompt injection signature
• An action that would exfiltrate data to an IP or domain outside your defined perimeter

Vaikora ships compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001, so teams with regulatory obligations can start from a baseline rather than writing every rule from scratch.

A concrete scenario

Say an AI agent is processing customer support tickets. It has access to a CRM tool, an email-send tool, and a document retrieval tool. A prompt injection arrives inside a ticket, instructing the agent to forward all retrieved documents to an external address.

Without inline enforcement, the agent reasons through the injected instruction, calls the email-send tool, and the data moves. Detection fires afterward.

With Vaikora inline, the tool call hits the gateway. The gateway inspects the destination against policy. The external address is not in the approved list. The call is blocked and logged before the email is sent. The agent receives a denial response and continues with the legitimate workflow.

What the audit log captures

Every decision the gateway makes is written to a SHA-256 hash-chained, tamper-evident audit log. Each entry records the request, the matched policy, the verdict, and a timestamp. Because the entries are chained, any modification to a prior record breaks the chain, which is detectable.

This matters for incident investigation and for compliance attestation. When an auditor or an IR team asks what an agent did and why a decision was made, the log provides an ordered, verifiable record. The log is not a summary. It is a decision-by-decision account.

How it reaches your existing security tooling

Vaikora integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. When the gateway detects a high-severity AI agent risk, it promotes that into Azure Security Center and Microsoft Defender for Cloud as a native incident, without custom engineering. Threats flagged against SentinelOne are pushed as Threat Intelligence indicators with severity mapped numerically: Critical at 100, High at 75, Medium at 50, Low at 25.

This means AI agent violations are visible in the same console your SOC already uses for endpoint and network alerts. There is no separate pane to monitor.

Throughput and deployment

The gateway supports 10,000 or more actions per second, so enforcement does not become a bottleneck in high-volume agentic workflows. It supports 12 LLM providers with no SDK migration required on your end.

The gateway itself, Vaikora Guard MCP, is open source under the MIT license, written in Python, and published on PyPI. The commercial product is the Vaikora Control Plane, hosted by Data443, which manages policy configuration, audit log access, compliance presets, and the SIEM integrations. The package is also available on AWS Marketplace and in the Azure Sentinel content hub.

What to check next

If you are already running AI agents in production, the first step is mapping every tool call those agents can make and identifying which ones touch regulated data, authenticated APIs, or external destinations. That list is your enforcement surface. Once you have it, you can define policy against it. Start with the highest-risk tool calls: writes, external sends, and anything that touches PII or credentials. Those are the ones where post-execution detection is not an acceptable control.

More from the Vaikora blog