Vaikora › Blog › Product Updates

What happens inside Vaikora between an AI agent request and the action that follows it

Product Updates · Oct 22, 2026 · 4 min read

When an AI agent calls a tool, something has to decide whether that call runs. Without a control point, the decision defaults to "yes, always." Vaikora puts a policy gate at that moment, before execution, and records a signed audit entry regardless of the outcome.

This article walks through what that gate actually does: the inspection steps, the decision types, and what the audit record contains.

The four decisions Vaikora can return

Every action an AI agent attempts passes through the Vaikora gateway. The gateway returns one of four decisions: allow, block, modify, or require-approval. Nothing executes until one of those decisions is issued.

• Allow passes the action through unchanged.
• Block stops it entirely and returns a structured error to the agent.
• Modify rewrites the payload before it reaches the tool or model. For example, a prompt carrying a credit card number in plain text can have that value masked before the call goes forward.
• Require-approval holds the action in a queue until a human reviewer accepts or rejects it.

The same input always produces the same decision. Vaikora evaluates policy deterministically, so the outcome does not depend on a model's confidence score or a sampling temperature. This matters for compliance: you can point an auditor at a policy file and show exactly why a given action was blocked.

What the content inspection layer checks

The gateway ships six content inspection modules. They run against the action payload before any decision is written. The modules cover:

• PII detection, identifying patterns like social security numbers, passport numbers, and health record identifiers.
• Secret and credential scanning, flagging API keys, tokens, and connection strings embedded in prompts or tool arguments.
• Prompt injection detection, catching attempts to override system instructions through crafted user input.
• Topic filtering, blocking or flagging content that falls outside a defined operational scope.
• Data exfiltration patterns, identifying tool calls that would write sensitive content to external endpoints.
• Regulatory content matching, applied through presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001.

In practice: an agent in a healthcare workflow submits a tool call that includes a patient identifier and a destination URL outside the approved domain list. The exfiltration module and the HIPAA preset both flag the call. Vaikora issues a block, logs the full payload hash, and pushes a severity-mapped indicator to the connected SIEM. The action never executes.

Latency and throughput at enforcement scale

A control layer that adds seconds to every action is not usable in production. Vaikora measures P50 latency at 8ms and P99 at 45ms. At enforcement throughput, the gateway handles over 10,000 actions per second.

Those numbers matter because the gate sits inline. The agent does not get a response until the gate issues a decision. A 45ms maximum at P99 means the enforcement overhead is not perceptible in most agentic workflows, including multi-step pipelines where agents chain tool calls.

The audit record and why it is tamper-evident

Every decision, whether allow, block, modify, or require-approval, is written to a SHA-256 hash-chained log. Each entry includes a hash of the previous entry. If any record is altered after the fact, the chain breaks and the modification is detectable.

This structure gives compliance teams something auditors can verify independently. The log is not a database of decisions that administrators can quietly amend. It is an ordered record with cryptographic continuity.

For a SOC 2 Type II audit or a HIPAA investigation, that distinction is significant. You are not asserting that controls were applied. You are presenting a record where any tampering would be visible.

How enforcement connects to your existing security stack

Vaikora integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. Threats detected at the enforcement layer flow into those platforms without custom engineering.

Specifically: high-severity AI agent risks promote into Azure Security Center and Microsoft Defender for Cloud as native incidents. Threat Intelligence indicators push into SentinelOne with severity values mapped numerically (Critical=100, High=75, Medium=50, Low=25), so existing triage rules pick them up without modification.

The gateway itself is open source under the MIT license, published on PyPI as `vaikora-guard-mcp`, and is self-hosted. The Vaikora Control Plane is the commercial layer, available on AWS Marketplace and in the Azure Sentinel content hub.

What to check next

If you are evaluating whether your current AI agent deployment has a genuine enforcement layer, the concrete question is: does anything issue a policy decision before the tool call executes, or does your control logic run against the output afterward?

Pull a sample of recent agent actions from your logs. For each one, identify where in the sequence a block could have been applied. If the earliest intervention point is after execution, you have a detection gap, not an enforcement posture. The Vaikora gateway installs as an MCP-compatible proxy, so you can insert it into an existing agent architecture without changing the agent's SDK or the model provider.

More from the Vaikora blog