Vaikora › Blog › Product Updates

What actually happens between an AI agent request and tool execution when Vaikora is inline

Product Updates · Nov 13, 2026 · 4 min read

An AI agent that can call tools, write files, query databases, or invoke APIs is a process that can cause real harm before any human reviews what it did. The question is not whether to control that process, but where the control sits and what it does when a policy condition is met.

Vaikora sits inline between the agent and whatever it calls. Every action passes through the gateway before it executes. The gateway returns one of four decisions: allow, block, modify, or require-approval. Nothing proceeds until a decision is issued.

What "inline" means in practice

Most agent observability tools record what an agent did. That is useful for investigation. It does not stop the action.

Vaikora's enforcement point is before execution, not after. When an agent issues a tool call, the request hits the Vaikora gateway first. The gateway evaluates it against policy, writes the decision to the audit log, and either passes the request through or stops it. The underlying tool never receives a blocked request.

This matters most in agentic chains where one action feeds the next. If the first tool call exfiltrates data or touches a restricted resource, reviewing logs afterward does not undo the damage. The enforcement has to happen at the call, not at the report.

How the policy decision is made

Policy in Vaikora is deterministic. Identical input produces an identical decision every time. That is different from a probabilistic filter that might block the same prompt 90% of the time. For compliance purposes, the difference is significant: a control that is not deterministic cannot be audited cleanly.

The gateway ships six content inspection modules. Each one checks a specific category of risk (data type, intent classification, tool scope, credential presence, and similar signals) and feeds the final allow, block, modify, or require-approval decision.

Enforcement latency is P50 8ms, P99 45ms, at a throughput of 10,000 or more actions per second. For most agent workflows, that overhead is not perceptible. For high-frequency pipelines, the numbers matter: a gate that adds seconds of latency to every tool call will get disabled. One that adds single-digit milliseconds will not.

What the audit log gives you

Every decision Vaikora writes is entered into a SHA-256 hash-chained audit log. Each entry is signed against the previous one. Altering or deleting a record breaks the chain, which makes tampering detectable.

This design serves two purposes. First, it gives security operations a complete ordered record of every agent action and the policy outcome applied to it. Second, it satisfies the auditability requirements that come with compliance presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001.

A concrete example: an agent operating in a healthcare workflow attempts to write patient records to an external endpoint. Vaikora evaluates the action against the HIPAA preset, blocks it, and writes the blocked decision to the audit chain with a timestamp, the matched policy rule, and a hash linking it to the prior entry. The record is immutable and sequenced. An auditor or incident responder can replay exactly what the agent attempted and what the system did about it.

Where Vaikora fits in your existing stack

Vaikora does not replace your IAM layer. It adds a runtime gate on top of Azure RBAC, AWS IAM, and Snowflake roles. The underlying permissions still apply; Vaikora adds a policy evaluation step that runs before the request reaches those systems.

On the SIEM and XDR side, Vaikora integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity AI agent threats are pushed into SentinelOne as Threat Intelligence indicators with severity mapped numerically (Critical=100, High=75, Medium=50, Low=25). Incidents are promoted into Azure Security Center and Microsoft Defender for Cloud as native incidents without custom engineering.

The gateway itself is open source under the MIT license and self-hosted. The control plane is the commercial product, hosted by Data443, and is available on AWS Marketplace and in the Azure Sentinel content hub as the Vaikora-AzureSecurityCenter solution.

What to check next

If you are evaluating agent control, start with the enforcement model, not the feature list. The question to ask any vendor is: at what point in the execution lifecycle does enforcement happen, and what is the evidence that a blocked action was actually blocked and not just flagged?

Install `vaikora-guard-mcp` from PyPI, run it against a test agent workflow, and look at what the audit log produces before you configure a single policy. The log structure tells you more about whether the control is real than any documentation will.

More from the Vaikora blog