Vaikora › Blog › Product Updates

AI agents act before you can review them. Here is how runtime enforcement changes that.

Product Updates · Nov 5, 2026 · 4 min read

AI agents do not wait for approval. They call APIs, write files, query databases, and send requests at machine speed, and by the time a human notices something unexpected, the action is already done. The question for security and platform teams is not whether agents will act autonomously, it is whether anything sits between intent and execution.

What "runtime control" actually means

Most agent security discussions focus on detection: logs, alerts, and post-incident review. Runtime control is different. It means a policy decision happens before the action executes, not after.

Vaikora sits inline between an AI agent and the LLM or tool it is calling. Every request passes through the gateway. The gateway evaluates it against configured policy and returns one of four decisions: allow, block, modify, or require-approval. The agent either proceeds, is stopped, gets a sanitized version of the request, or waits for a human. Nothing reaches the target system until that decision completes.

The P50 enforcement latency is 8ms. P99 is 45ms. At 10,000+ actions per second, the control layer does not become the bottleneck in production traffic.

Why deterministic policy matters for AI agents

LLMs are probabilistic. The same prompt can produce different outputs on different runs, which is exactly why a probabilistic model should not be the only thing deciding whether an action is safe. Policy enforcement needs to be deterministic: identical input, identical decision, every time.

Vaikora policy is deterministic. A rule that blocks exfiltration of fields matching a PII pattern will block every matching request, not most of them. Detection accuracy in testing is 99.9%. That is not a probabilistic guardrail built on another model's judgment. It is a rule evaluated at the gateway before the call leaves the agent.

This matters most in regulated environments. HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001 compliance presets ship with Vaikora so teams do not have to write policy from scratch for common requirements.

A concrete scenario: agent with database access

Consider an AI agent that answers internal questions by querying a Snowflake warehouse. The agent has a Snowflake role scoped to read-only access on a specific schema. That RBAC boundary controls what the agent can query, but it does not control what gets returned or where it goes next.

If a user prompt asks the agent to "summarize all customer records including email addresses and payment status," the Snowflake role permits that query. The agent runs it and includes the output in a response or a downstream action. Nothing in Snowflake stops this because the role allows it.

Vaikora adds a gate on top of the existing IAM and RBAC layer. It inspects the tool call before it reaches Snowflake. A policy matching PII field patterns in outbound query results can block the response, strip specific fields, or route the request to a human reviewer before any data leaves the warehouse. The Snowflake role did not change. The enforcement happened above it.

Auditability as a first-class output

An enforcement layer without an audit trail gives you control but not accountability. Vaikora writes every decision to a SHA-256 hash-chained, tamper-evident audit log. Each entry is signed into the chain in order. If a log is modified or entries are deleted, the chain breaks and the tampering is detectable.

For compliance investigations, this means you can produce an ordered, verifiable record of every allow, block, modify, or approval decision the gateway made, and prove the record has not been altered since it was written. That is the difference between logs and auditability.

Where enforcement signals go from here

Enforcement decisions do not have to stay inside Vaikora. The platform integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity AI agent threats push into SentinelOne as Threat Intelligence indicators with severity mapping (Critical=100, High=75, Medium=50, Low=25). High-severity risk promotes into Azure Security Center and Microsoft Defender for Cloud as native incidents with no custom engineering.

If your SOC already works in Sentinel or CrowdStrike, AI agent enforcement events appear in the same queues as your other threat signals.

What to check next

If your environment has AI agents making tool calls today, the first thing to verify is whether anything enforces policy on those calls before execution, or whether your current posture is detection after the fact. Start by mapping which tools your agents can call, what data those tools can reach, and whether any control layer sits between the agent and execution. If the answer to that last question is "just IAM roles," that is the gap to close.

Vaikora Guard MCP is MIT-licensed, written in Python, published on PyPI as `vaikora-guard-mcp`, and self-hostable. You can run it against your existing agent setup without changing your LLM SDK or provider.

More from the Vaikora blog