Vaikora › Blog › Product Updates

When an AI agent takes a wrong action, audit logs tell you what happened. Policy enforcement stops it.

Product Updates · Nov 7, 2026 · 4 min read

An AI agent that calls the wrong API, reads a file it should not touch, or posts data to an external endpoint causes harm before anyone reviews a log. The question is not how quickly you can detect that afterward. The question is whether the action was allowed to run at all.

That distinction is what AI runtime control is built on. Detection is a response to failure. Enforcement is a condition of execution.

What inline enforcement actually means

Vaikora sits between an AI agent and whatever it calls next: an LLM, a tool, an API, a file system. Before the action executes, Vaikora evaluates it against policy and returns one of four decisions: allow, block, modify, or require approval. If the action is blocked, it never reaches the target. The agent receives a structured refusal and the decision is logged.

This is not a firewall that inspects traffic after a session. The gate is at the action level, evaluated per call, in real time. Policy runs at P50 8ms and P99 45ms, so the latency added to any individual action is small enough that it does not change how agentic workflows are designed.

The decisions are deterministic. Identical input always produces identical output. That matters for compliance: a system that sometimes allows an action and sometimes blocks it, depending on model temperature or prompt wording, cannot be audited reliably.

What the policy layer evaluates

Each action Vaikora evaluates carries context: the agent identity, the tool being called, the payload content, and the action type. Policy rules match against those fields.

A concrete example: an agent is processing insurance claims and has access to a document retrieval tool. A policy rule blocks any tool call that includes a Social Security Number in the query parameter, unless the calling agent holds an explicit data-access permission. If the agent passes a raw SSN, the action is blocked and flagged. If it passes a tokenized reference, the action proceeds. The agent never touches the raw value downstream.

That kind of rule is not achievable by reviewing logs after the fact. The SSN would have already been sent.

Audit chain and compliance presets

Every decision Vaikora writes to a SHA-256 hash-chained, tamper-evident audit log. The chain gives you an ordered, signed record: each entry references the hash of the previous one, so any modification to a past entry breaks the chain and is detectable.

For compliance programs that require demonstrating control over data handling, that log is the evidence. Vaikora ships presets for HIPAA, PCI-DSS, GDPR, SOC 2, and ISO 27001. Each preset loads a baseline policy aligned to the relevant control requirements. Teams can extend the preset rules or override them, and all changes appear in the audit record.

Where Vaikora fits in an existing stack

Vaikora does not replace IAM. It adds a runtime gate on top of Azure RBAC, AWS IAM, and Snowflake roles. An agent that holds an IAM permission to read an S3 bucket will still be blocked by a Vaikora policy that says no agent may read that bucket during off-hours, or no agent may read that bucket and also write to an external endpoint in the same session.

The IAM layer controls what a principal is permitted to do at the infrastructure level. The Vaikora layer controls what an AI agent is permitted to do given the specific action, context, and data involved.

For security operations teams, Vaikora integrates natively with Microsoft Sentinel, Microsoft Defender, SentinelOne, CrowdStrike Falcon, and AWS Security Hub. High-severity AI agent threats are promoted into Azure Security Center and Microsoft Defender for Cloud as native incidents without custom engineering. Threat indicators are pushed into SentinelOne with severity values mapped to a 100-point scale so SOC workflows can triage them alongside other signal sources.

How to scope a deployment

Start with the agents that have the most external reach: anything calling third-party APIs, writing to production databases, or handling regulated data. Apply the relevant compliance preset and review the blocked-action log after one week. The pattern of blocked calls tells you where your existing IAM and agent prompt policies have gaps.

From there, tighten or loosen rules based on what you see, add require-approval thresholds for high-risk action categories, and push indicators to your SIEM so the SOC has visibility into AI agent risk alongside endpoint and network telemetry.

The audit log and the enforcement record together give you something that monitoring alone cannot: proof that a control existed and ran at the moment an action was attempted.

More from the Vaikora blog