Vexyl Guard

Vexyl Guard Page
The Architecture
Scoped
Redacted
Later Tool
Privacy Safe
Latest Release Notes

Inspiration

Vexyl Guard started with a problem I kept noticing while working with AI applications. We protect the Linux server one way and the AI application another way, even though they are part of the same system.

Traditional server security can detect things like repeated login attempts, exposed services, exploit probes, and suspicious processes. What it usually cannot see is when an AI agent retrieves a malicious instruction, saves something unsafe to memory, reads sensitive information, or uses a tool in a way the operator never approved.

AI security tools have the opposite problem. They may inspect prompts or model responses, but they often do not understand what is happening on the server underneath the application. Some also require sending prompts and conversations to an outside service.

I wanted Vexyl Guard to connect those two sides.

The goal was to build one local security layer for Linux servers running AI applications, agents, RAG systems, and tool-based workflows. It needed to understand both normal server activity and important AI actions while keeping sensitive application content on the machine.

What it does

Vexyl Guard is an open-source security agent for Linux servers, especially servers that run AI-connected applications.

You install it directly on the host. By default, it works in monitor mode. It watches for suspicious activity, explains what it sees, and leaves enforcement under the operator’s control.

For AI applications that need stronger protection, Vexyl Guard also provides a local decision gateway. The application can check with the gateway before it performs an important action, such as:

Saving information to long-term memory.
Calling a tool or external service.
Sending information outside the application.
Using sensitive data.
Switching models or changing model identity.
Acting outside the current user, task, or tool permissions.

The gateway evaluates the action and returns an allow or deny decision with a safe explanation.

For example, imagine an AI agent retrieves content from a webpage. That content contains an instruction telling the agent to save something to memory and later send information through a tool. Each step might look harmless on its own. Vexyl Guard can connect those events, recognize the sequence, and warn or deny the later action based on the operator’s policy.

The Build Week extension added checks for:

External content that later influences memory or tool use.
Sensitive information being read before an outbound action.
Repeated or unusual tool calls.
Unexpected token usage or cost increases.
Attempts to probe or change the model.
Identity and orchestration problems.
Missing approval or human oversight.
Actions outside the approved task, user scope, or tool policy.
Intelligence updates that fail signature, expiration, revocation, sequence, or rollback checks.

Everything runs locally through an authenticated Unix socket. Vexyl Guard does not need to expose another TCP port.

I also built Python and Node.js clients, along with guards for ASGI, FastAPI, and Express. These integrations make it possible to add Vexyl Guard at the point where an application is about to perform a sensitive action.

Privacy was one of the main design requirements. The gateway does not accept or store raw prompts, messages, tool arguments, or model outputs. It works with a small redacted event format instead. Unknown context fields are rejected so applications cannot accidentally send extra sensitive information.

When Vexyl Guard explains a decision, it uses a limited set of factor codes instead of repeating the original content. The operator can understand why something was allowed, flagged, or denied without turning the security database into a prompt archive.

How I built it

Vexyl Guard already had a monitor-first Linux agent. My Build Week goal was to add AI runtime protection without changing that original behavior or turning the project into a cloud monitoring service.

Most of the extension is built with Python 3’s standard library, dependency-free Node.js modules, Bash, SQLite, systemd, and GitHub Actions.

The Python and Node integrations send events through a shared, versioned contract. The local gateway authenticates and validates each request before passing it to the scoring system.

Some detections need short-term history. Instead of storing the original prompt or tool data, the gateway stores only redacted summaries and derived security facts. This gives it enough context to connect related events without keeping the underlying conversation.

The SQLite state remains local. Identifiers are hashed again on the host, files use restrictive permissions, retention is limited, and status commands return counts instead of sensitive event details.

I used the same conformance fixtures for the Python and Node integrations. That means both languages must reach the same allow or deny decision for the same event. A FastAPI application should not receive a different security result from an Express application just because the integration was written in another language.

I also built package tests for clean Debian and RPM-based environments. The release workflow creates signed checksums and packages, publishes them, and then tests the promoted production repositories.

How I used Codex and GPT-5.6

I used Codex with GPT-5.6 as an implementation partner throughout the Build Week extension.

It did more than generate isolated pieces of code. Codex first inspected the existing repository and traced how the monitor, packaging, installation, testing, and release systems already worked. That helped me extend the project without replacing working parts or breaking its monitor-first design.

From there, Codex helped coordinate changes across Python, Node.js, Bash, systemd, tests, GitHub Actions, package definitions, and documentation.

GPT-5.6 was especially useful when one security rule affected several parts of the project. A field added to the event schema also had to match the Python model, Node client, gateway validation, scoring logic, middleware behavior, redaction rules, tests, and documentation.

Codex helped find places where those contracts had drifted apart. It also created defensive test cases, tightened failure behavior, reran installation tests, and verified the signed release process.

I still made the final product and security decisions. Some of the most important choices were:

Using a local Unix socket instead of a network API.
Keeping raw prompts and tool content out of stored history.
Requiring authorization to come from trusted application policy.
Using fail-closed behavior for sensitive integrations.
Keeping active intelligence private while providing safe public fallbacks.
Requiring signed intelligence updates with rollback protection and recovery.

Challenges I ran into

The hardest problem was giving Vexyl Guard enough memory to recognize a dangerous sequence without creating surveillance.

A single event does not always tell the full story. Retrieved content may influence a memory update several seconds later. A sensitive read may only become dangerous when it is followed by an outbound tool call.

Detecting those patterns requires some state, but I did not want that state to become a hidden collection of prompts, conversations, or tool arguments.

I solved this by storing short-lived, redacted summaries and derived flags instead of the original content. Vexyl Guard remembers the security-relevant fact that something happened without keeping the private data involved.

The other major challenge was consistency.

Vexyl Guard supports different languages and frameworks, but the security policy has to behave the same everywhere. Shared fixtures and cross-language conformance tests now verify that Python and Node integrations reach the same decision for the same input.

Release testing was another important part of the work. A security tool is not useful if it only works inside the development repository. I added clean package installation tests and live repository canaries so the published version is tested through the same path a real user would follow.

Accomplishments that I’m proud of

What I’m most proud of is that the Build Week work became a complete release instead of only a demo.

I added a local AI runtime decision path without changing the Linux agent’s monitor-first default.
I added stateful detection without storing raw prompts, messages, tool arguments, or outputs.
I built an authenticated gateway without opening a TCP port.
I added Python, Node.js, ASGI, FastAPI, and Express integrations.
I created privacy-safe decision explanations with stable factor codes.
I added signature, revocation, expiration, sequence, atomicity, rollback, and recovery checks for intelligence updates.
I released the completed work as Vexyl Guard v0.2.16.
The release includes public source, signed artifacts, APT and DNF packages, CI testing, and live installation canaries.
I created a deterministic 35-case security regression suite covering all 22 public attack-pattern identifiers.

The curated regression fixtures currently produce zero false positives and zero false negatives. Those are controlled test results, not a claim that the project has perfect real-world detection.

What I learned

The biggest thing I learned is that AI runtime security works best at clear application boundaries.

The application already knows when it is about to retrieve outside content, save memory, call a tool, access sensitive information, or change models. Those moments are natural places to perform a security check.

A small redacted event sent at the right time is easier to understand, audit, test, and operate than trying to secretly intercept all application traffic.

I also learned that an AI system cannot be trusted to define its own permissions.

Retrieved content and model output should never be allowed to decide what tools are approved, what user scope applies, whether human approval exists, or what security response should be taken. That information has to come from trusted application policy outside the model.

What’s next for Vexyl Guard

The next step is expanding the evaluation corpus with more defensive boundary cases and more complicated multi-step sequences.

I also want to create practical operator runbooks that explain what to do when Vexyl Guard identifies a specific factor or denies an action.

The public FastAPI, Express, RAG, and MCP examples already run through a shared compatibility harness connected to the real gateway. I plan to keep improving those examples so developers can see exactly where Vexyl Guard fits into an application.

Enforcement will remain optional and controlled by the operator.

Any future automated response feature will continue to require: