🛡 Building Voreenth: Rethinking Runtime Security for LLMs

By Jibril Anifowoshe

Executive Summary

Large Language Models (LLMs) have introduced a new enterprise attack surface that traditional security architectures were never designed to inspect: the prompt itself.

Most organizations already invest heavily in identity, endpoint protection, network segmentation, cloud security posture management, application security, and data loss prevention. Yet many AI applications still forward user prompts directly to the model runtime with little or no preventative inspection.

That architectural pattern assumes the model itself will behave securely.

That assumption is increasingly difficult to defend in enterprise environments.

Voreenth was built to demonstrate a different approach: security decisions should occur before inference—not during or after it.

Rather than relying on the model to determine whether a request is acceptable, Voreenth evaluates prompts against runtime security policies, assigns contextual risk, and enforces allow/block decisions before the request reaches the underlying Large Language Model.

Although implemented as an open-source research prototype, the architectural pattern reflects how runtime AI security can evolve within enterprise environments.

Explore Voreenth

🌐 Live Application

💻 GitHub Repository

🎥 Technical Walkthrough:

🚨 The Architectural Problem

Traditional enterprise security follows a familiar pattern:
User
│
▼
Application
│
▼
Business Logic
│
▼
Database

Security controls exist at nearly every layer:

Identity & Access Management
Authentication
Authorization
API Gateways
Web Application Firewalls
Endpoint Detection & Response
Data Loss Prevention
Cloud Security Controls

Large Language Models introduce an entirely new execution path.
User
│
▼
Prompt
│
▼
LLM
│
▼
Response

The prompt becomes executable intent.

Unlike traditional application inputs, prompts may contain:

prompt injection attempts
system prompt extraction
environment reconnaissance
credential harvesting
sensitive data exposure
policy bypass attempts

If prompts reach the model without inspection, organizations lose an important opportunity for preventative enforcement.

🏗 A Different Security Pattern

Unlike model-native guardrails that rely on the LLM to reject unsafe requests, Voreenth implements a dedicated Policy Enforcement Point (PEP) that evaluates prompts before inference occurs.

This follows a familiar enterprise security principle:

Never allow an execution engine to become its own security control plane.

The model generates language.

The gateway enforces policy.

🔍 Runtime Detection Pipeline

Every submitted prompt passes through multiple inspection stages before any inference occurs.

Prompt Normalization

Before inspection, prompts are normalized to reduce common evasion techniques, including:

Unicode normalization
whitespace normalization
punctuation normalization
common misspellings
basic leetspeak substitutions

This improves detection reliability without modifying the user’s intent.

Security Classification

Voreenth currently evaluates prompts across multiple security domains.

Detection Category	Purpose
Prompt Injection	Detect instruction override attempts
System Prompt Extraction	Prevent disclosure of hidden prompts
Environment Reconnaissance	Identify runtime enumeration attempts
Secret Exposure	Detect API keys, tokens and credentials
Sensitive Data Inspection	Identify regulated information and PII
Oversized Prompt Detection	Flag anomalous prompt length

Each detection contributes to an aggregate runtime risk score.

Contextual Risk Scoring

Rather than relying on a single keyword match, Voreenth aggregates multiple security signals.

For example:
Prompt Injection
+
Secret Exposure
+
Environment Reconnaissance
=
Higher Runtime Risk

This allows enforcement decisions to consider the overall context rather than isolated indicators.

🛡 Policy Enforcement Before Inference

The policy engine ultimately produces one of two outcomes.

            Risk Evaluation

                 │
      ┌──────────┴──────────┐

    Low Risk            High Risk

       │                    │

    ALLOW                BLOCK

       │                    │

 Forward to LLM      Stop Execution

High-risk requests never reach the model runtime.

This distinction is important.

The model is no longer responsible for determining whether execution should occur.

It simply receives requests that have already satisfied enterprise security policy.

📊 Runtime Security Telemetry

Inspection without visibility has limited operational value.

Every evaluated request generates structured telemetry including:

timestamp
risk score
severity
policy decision
detection categories
enforcement reason
model backend
response summary

This enables security teams to establish an auditable runtime history rather than treating AI interactions as opaque transactions.

🌐 Model-Agnostic by Design

One design goal was avoiding dependency on a single model provider.

The runtime gateway sits above the inference layer.

⚙ Current Implementation

The prototype currently includes:

Runtime prompt inspection
Prompt injection detection
System prompt extraction detection
Environment reconnaissance detection
Secret detection
Sensitive data inspection
Risk scoring
Allow/block policy enforcement
Local telemetry
Interactive security dashboard
Cloud-hosted inference
Local Ollama support
Simulation mode

The objective is not feature completeness.

The objective is demonstrating a repeatable runtime security architecture.

🔭 Future Direction

Future iterations may explore:

Policy-as-Code
Adaptive risk scoring
Session isolation
Microsoft Entra ID integration
Azure Key Vault integration
Microsoft Sentinel integration
Agent runtime protection
MCP security controls
Retrieval-Augmented Generation (RAG) inspection
Enterprise RBAC
Multi-provider routing
SIEM integration

Closing Thoughts

Generative AI is rapidly becoming another enterprise execution environment.

Historically, organizations introduced dedicated security layers as new execution environments emerged:

Firewalls for networks
Secure gateways for web traffic
WAFs for applications
EDR for endpoints
CSPM for cloud platforms

Large Language Models deserve the same architectural treatment.

Runtime AI security should not depend solely on model alignment or post-response filtering.

It should begin before inference.

Treat prompts as untrusted input.

Inspect them.

Score their risk.

Enforce policy.

Generate telemetry.

Only then should requests be allowed to reach the model.

As enterprises operationalize generative AI, runtime security should become a first-class architectural control—not an afterthought layered onto the model. Voreenth was built to demonstrate that principle.

✍️ Author: Jibril Anifowoshe — July 2026
Senior Cybersecurity Architect & AI Security Engineer | $900M+ Enterprise Risk Reduction • Zero Trust Architecture • AI Runtime Security • Cloud Security • Advanced Threat Modeling • Agentic AI

💼 LinkedIn

recent posts