Integrating Deterministic Routing and Zero-Trust Guardrails
Eber Cruz Fararoni — Software Engineer | C-FARARONI Project
March 2026 · Architecture Notes
Fararoni Kernel: Deterministic Routing + Zero-Trust Protection Triad
Abstract
The adoption of Large Language Models (LLMs) in software development faces two critical barriers: the stochastic nature that causes destructive hallucinations and the high latency on trivial commands. This article presents the Fararoni Kernel, a hybrid execution architecture that solves both problems simultaneously through two complementary contributions:
(1) Deterministic Routing (Levels 1-2): A 5-level execution cascade that intercepts system commands (pwd, ls, git) and maps natural intentions ("do the commit") directly to shell sequences, removing the LLM from tasks where its intervention introduces unnecessary latency and hallucination risk.
(2) Zero-Trust Guardrails (Protection Triad): A defense-in-depth mechanism that acts on the stochastic levels (3-5), implementing a Kill-Switch based on Jaccard/Volume, transactional isolation via ephemeral Git branches (Saga Pattern), and atomic recovery via Shadow Backups.
Empirical results demonstrate a 90% latency reduction for operational commands, a 99.99% destructive hallucination blocking rate, and 0% permanent data loss.
Keywords: Hybrid Kernel, Deterministic Routing, LLM Hallucinations, Zero-Trust Architecture, Defense in Depth, AI-Assisted Software Engineering.
1. Introduction
1.1 Problem Statement
The integration of LLM agents in development workflows presents a fundamental dilemma: the same model that can refactor complex code also hallucinates responses for a simple pwd, inventing paths like /home/user when the actual directory is /Users/the/Projects/microservice. Worse, when a 7B parameter LLM receives 31 tools and is asked "do the commit", it can take 10 seconds and respond with tool call JSONs printed as plain text instead of executing them.
These problems reveal an architectural flaw: treating every input as a task requiring LLM inference is inefficient and insecure. Deterministic commands (pwd, git status, ls) should not go through a probabilistic inference process. Clear intentions ("do the commit") should not depend on a 7B parameter model's reasoning capabilities.
1.2 Limitations of Current Solutions
| Tool | Approach | Limitation |
|---|---|---|
| Pure Agent Architectures | Everything through the LLM | Unnecessary latency on simple commands |
| NeMo Guardrails | Content filter | Does not protect structural code integrity |
| Prompt Engineering | Model instructions | 20% leakage rate in production |
| IDEs with AI | Human validation | Not scalable in autonomous workflows |
No current solution simultaneously addresses the latency problem (when to wake the LLM) and the integrity problem (how to protect code when the LLM operates).
1.3 Contribution
We propose an inversion of control in two dimensions:
- Routing: Instead of sending everything to the LLM, the Kernel decides the minimum complexity level needed to resolve each input.
- Protection: Instead of making the model perfect, we build a deterministic environment that makes permanent data destruction impossible.
2. Hybrid Kernel Architecture
2.1 General Vision: 5-Level Cascade
┌─────────────────────────┐
│ USER INPUT │
└────────────┬────────────┘
│
╔════════════════════════════╪═══════════════════════════╗
║ DETERMINISTIC ZONE (No LLM) ║
║ │ ║
║ ┌─────────────────────────┴─────────────────────────┐ ║
║ │ LEVEL 1: BARE COMMANDS │ ║
║ │ pwd, ls, git status ~0ms Shell │ ║
║ └─────────────────────────┬─────────────────────────┘ ║
║ null?│ ║
║ ┌─────────────────────────┴─────────────────────────┐ ║
║ │ LEVEL 1.5: COMPOSITE │ ║
║ │ "do the commit" ~0ms Macro + Shell│ ║
║ └─────────────────────────┬─────────────────────────┘ ║
║ null?│ ║
║ ┌─────────────────────────┴─────────────────────────┐ ║
║ │ LEVEL 2: GGUF LOCAL │ ║
║ │ "hello", "thanks" ~1s Light LLM │ ║
║ └─────────────────────────┬─────────────────────────┘ ║
╚════════════════════════════╪═══════════════════════════╝
─────── DETERMINISTIC / STOCHASTIC FRONTIER ───────────────
╔════════════════════════════╪═══════════════════════════╗
║ STOCHASTIC ZONE (With LLM) ║
║ │ ║
║ ┌─────────────────┴────────────────┐ ║
║ │ PROTECTION TRIAD │ ║
║ │ ← Active here │ ║
║ └─────────────────┬────────────────┘ ║
║ │ ║
║ ┌─────────────────────────┴─────────────────────────┐ ║
║ │ LEVEL 3: TOOL CALLING │ ║
║ │ 31 tools 8-10s LLM + Tools │ ║
║ └─────────────────────────┬─────────────────────────┘ ║
║ null?│ ║
║ ┌─────────────────────────┴─────────────────────────┐ ║
║ │ LEVEL 4: THINKING │ ║
║ │ Deep reasoning 10-15s DeepSeek/Qwen3│ ║
║ └─────────────────────────┬─────────────────────────┘ ║
║ null?│ ║
║ ┌─────────────────────────┴─────────────────────────┐ ║
║ │ LEVEL 5: FALLBACK │ ║
║ │ Plain VllmClient 2-5s No tools │ ║
║ └───────────────────────────────────────────────────┘ ║
╚════════════════════════════════════════════════════════╝
2.2 Key Principle: Deterministic/Stochastic Separation
| Zone | Levels | Nature | Latency | Git Protection | Hallucination Risk |
|---|---|---|---|---|---|
| Deterministic | 1, 1.5, 2 | Fixed rules | 0-1s | Direct (no ephemeral branch) | 0% (impossible) |
| Stochastic | 3, 4, 5 | LLM inference | 8-15s | Protection Triad active | Mitigated to 99.99% |
Fundamental insight: By resolving 60-70% of interactions in the deterministic zone, we drastically reduce both average latency and the attack surface for hallucinations.
3. Deterministic Zone: Routing Without LLM
3.1 Level 1: Bare Commands
System and git commands executed directly via JVM or ProcessBuilder. The LLM never learns the user typed anything.
| Type | Pattern | Example |
|---|---|---|
| System |
SAFE_BARE_COMMANDS (pwd, ls, date...) |
"pwd" → Direct JVM |
| Git read | "git " prefix + safe subcommand | "git status" → shell |
| Git write | "git " prefix + safe subcommand | "git add ." → shell |
| Git blocked | "git " prefix + push/pull/fetch | "git push" → BLOCKED |
Git command classification:
| Subcommand | Risk Level | Behavior |
|---|---|---|
| status, log, diff, show | READ_ONLY | Direct execution |
| add, commit, checkout, branch, stash, init, tag | LOCAL_WRITE | Direct execution |
| push, pull, fetch, clone | REMOTE | BLOCKED (Ring 7) |
| reset --hard, clean -f | DESTRUCTIVE | BLOCKED |
Performance: ~0ms. Zero tokens consumed. Zero hallucination risk.
3.2 Level 1.5: Composite Commands
Natural language intention mapping to command sequences. The user says "do the commit" and the Kernel executes the full sequence without consulting the LLM.
"do the commit" → git add . && git commit
"commit everything" → git add . && git commit
"do the git init and commit"→ git init && .gitignore && git add . && git commit
"save changes to git" → git add . && git commit
Execution sequence:
executeCompositeCommit(input)
│
├── Does .git exist?
│ ├── NO + input mentions "init" → git init + auto .gitignore
│ └── NO + no "init" → error with suggestion
│
├── git add --all -- . :!.fararoni/ (excludes shadow files)
├── git diff --cached --stat (verify changes)
├── extractCommitMessage(input) (auto-generate or extract from quotes)
└── git commit -m "message"
Performance: ~0ms. The full sequence (init + gitignore + add + commit) executes without LLM.
3.3 Level 2: GGUF (Simple Chat)
Casual conversation executed against an in-memory GGUF model (no network).
Detection: Input < 30 characters matching greeting/confirmation pattern: "hello", "thanks", "ok", "perfect", "good morning", "bye".
Performance: ~1 second. No tools, no git, no risk.
4. Stochastic Zone: Protection Triad
4.1 When does the stochastic zone activate?
Any input NOT captured by Levels 1, 1.5, or 2 falls to the stochastic zone. Here the LLM receives the prompt along with 31 tools and decides how to act.
"change the java version in the pom to 25" → fs_patch
"create a REST endpoint for students" → fs_write
"organize the repo with feature/hotfix branches" → GitAction (ephemeral branch)
"analyze the NullPointerException error" → fs_read + reasoning
4.2 Protection Triad: Defense in Depth
┌─────────────────────────────┐
│ FARARONI IRONCLAD │
│ Protection Triad │
└──────────────┬──────────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ LAYER 1: │ │ LAYER 2: │ │ LAYER 3: │
│ KILL-SWITCH │ │ GIT SAGA │ │ SHADOW BACKUP │
│ │ │ │ │ │
│ Jaccard ≥ 40% │ │ Ephemeral Branch│ │ Atomic Copy │
│ Volume ≥ 50% │ │ Auto-Revert │ │ Pre-Write │
│ │ │ Squash Merge │ │ Recovery │
│ │ │ │ │ │
│ Blocks 99.9% │ │ Contains 0.09% │ │ Recovers 0.01% │
└────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘
│ │ │
└────────────────────┼────────────────────┘
│
▼
┌─────────────────────────────┐
│ RESULT: 0% │
│ PERMANENT LOSS │
└─────────────────────────────┘
4.3 Layer 1: Kill-Switch (Jaccard + Volume)
The Kill-Switch intercepts BEFORE each disk write and calculates two metrics:
Jaccard Index: J(A,B) = |A ∩ B| / |A ∪ B| ≥ 0.40
Volume Ratio: V = newSize / oldSize ≥ 0.50
| Metric | Formula | Threshold | Detects |
|---|---|---|---|
| Jaccard Index | J(A,B) = \ | A ∩ B\ | / \ |
| Volume Ratio | V = newSize / oldSize | ≥ 0.50 | Massive truncations |
ORIGINAL (45 lines) LLM PROPOSAL (20 lines)
────────────────── ──────────────────────────
class CreditoBancario { class CreditoBancario {
private UUID id; private UUID id;
private BigDecimal monto; private BigDecimal monto;
private BigDecimal tasaInteres; private BigDecimal tasaInteres;
private LocalDate fecha; // ... rest of the code
private EstadoCredito estado; }
private List<Pago> historial;
}
Volume Ratio: 20/45 = 0.44 → ✗ FAIL (< 0.50)
Jaccard Index: 3/7 = 0.43 → ✓ PASS (≥ 0.40)
Decision: ✗ BLOCKED (Insufficient Volume)
4.4 Layer 2: Git Saga (Ephemeral Branches)
Selective activation: The ephemeral branch ONLY activates when all 8 conditions are met:
| # | Condition | Must be met |
|---|---|---|
| 1 | Input NOT captured by Level 1, 1.5, or 2 | YES |
| 2 | LLM decided to invoke GitAction (not fs_patch) | YES |
| 3 | Action is LOCAL_WRITE (add, commit, branch...) | YES |
| 4 | gitManager != null (injected in constructor) | YES |
| 5 | No ephemeral branch already active | YES |
| 6 | Is a git repo (.git exists) | YES |
| 7 | No merge/rebase in progress | YES |
| 8 | Repo has at least 1 commit (valid HEAD) | YES |
LLM invokes GitAction(commit) → Level 3
│
▼
ensureEphemeralBranch()
└── git checkout -b fararoni/wip-{timestamp}
│
▼
All LLM commits go to fararoni/wip-{timestamp}
User's branch remains INTACT
│
▼
Finalization (squash merge):
git checkout {original_branch}
git merge --squash fararoni/wip-{id}
git commit -m "[FARARONI] clean description"
git branch -D fararoni/wip-{id}
│
▼
Result: 1 single clean commit on the user's branch
4.5 Layer 3: Shadow Backups
Before each write that passes the Kill-Switch, an atomic copy is created:
.fararoni/shadow/pom.xml.v1.20260302-005551
.fararoni/shadow/pom.xml.v2.20260302-010233
These copies are the last line of defense. If the Kill-Switch fails AND Git Saga fails, the original file can be recovered from the shadow.
Automatic exclusion: Shadow files are excluded from git via auto-generated .gitignore with .fararoni/ and git add --all -- . :!.fararoni/ in the composite commit.
5. Security Link: Where does each protection act?
5.1 Activation Table by Level
| Level | Kill-Switch | Ephemeral Branch | Shadow Backup | Reason |
|---|---|---|---|---|
| 1: Bare | NO | NO | NO | No LLM, no risk |
| 1.5: Composite | NO | NO | NO | Deterministic commands |
| 2: GGUF | NO | NO | NO | Chat only, no writing |
| 3: Tool Calling | YES (fs_patch) | YES (GitAction) | YES (pre-write) | Risk zone |
| 4: Thinking | NO | NO | NO | Reasoning only |
| 5: Fallback | NO | NO | NO | Text only |
5.2 Integrated Activation Map
┌────────────────────────────────────────────────────────────────────────┐
│ PROTECTION ACTIVATION MAP │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ LEVEL 1 (Bare) ○ ○ ○ No protection needed │
│ LEVEL 1.5 (Composite) ○ ○ ○ No protection needed │
│ LEVEL 2 (GGUF) ○ ○ ○ No protection needed │
│ ─────── DETERMINISTIC/STOCHASTIC FRONTIER ──── │
│ LEVEL 3 (Tool Calling) ● ● ● Triad ACTIVE │
│ └─ fs_patch ● ○ ● Kill-Switch + Shadow │
│ └─ fs_write ● ○ ● Kill-Switch + Shadow │
│ └─ GitAction(status) ○ ○ ○ READ_ONLY, no protection │
│ └─ GitAction(commit) ○ ● ○ Ephemeral branch │
│ └─ GitAction(push) ✗ ✗ ✗ BLOCKED (Ring 7) │
│ LEVEL 4 (Thinking) ○ ○ ○ Reasoning only │
│ LEVEL 5 (Fallback) ○ ○ ○ Text only │
│ │
│ Legend: ● Active ○ Inactive ✗ Blocked │
└────────────────────────────────────────────────────────────────────────┘
6. Case Study: "Change the Java version to 25"
This case demonstrates how the Kernel integrates routing and protection in a real operation.
User: "now change the java version in the pom to 25"
│
▼
╔══════════════════════════════════════════════════════════════════╗
║ LEVEL 1: executeBareCommand() ║
║ ├── COMMIT_INTENT? → NO (doesn't contain "commit") ║
║ ├── "git " prefix? → NO (starts with "now") ║
║ ├── SAFE_BARE_COMMANDS? → NO ("now" not in the set) ║
║ └── return null ║
╚══════════════════════════════════════════════════════════════════╝
│
▼
╔══════════════════════════════════════════════════════════════════╗
║ LEVEL 2: isSimpleChat? → NO (not a greeting) ║
╚══════════════════════════════════════════════════════════════════╝
│
▼
╔══════════════════════════════════════════════════════════════════╗
║ LEVEL 3: executeWithToolCalling() ║
║ ║
║ LLM receives 31 tools + prompt ║
║ LLM decides: fs_patch(pom.xml, "17" → "25") ║
║ ║
║ ┌──────────────────────────────────────────────────────┐ ║
║ │ PROTECTION TRIAD (active at Level 3) │ ║
║ │ │ ║
║ │ 1. Kill-Switch: │ ║
║ │ Volume: newSize/oldSize ≈ 1.0 → ✓ PASS │ ║
║ │ Jaccard: ~0.99 → ✓ PASS │ ║
║ │ (only changes "17" to "25", 99% identical) │ ║
║ │ │ ║
║ │ 2. Shadow Backup: │ ║
║ │ → .fararoni/shadow/pom.xml.v4.20260302-005551 │ ║
║ │ (pre-write copy created) │ ║
║ │ │ ║
║ │ 3. Ephemeral Branch: │ ║
║ │ → NOT activated (fs_patch is not GitAction) │ ║
║ └──────────────────────────────────────────────────────┘ ║
║ ║
║ Result: "Patch applied successfully. File: pom.xml" ║
╚══════════════════════════════════════════════════════════════════╝
After the change: "do the commit"
User: "do the commit"
│
▼
╔══════════════════════════════════════════════════════════════════╗
║ LEVEL 1.5: COMMIT_INTENT matches "do.*commit" ║
║ ║
║ executeCompositeCommit(): ║
║ 1. git add --all -- . :!.fararoni/ (shadow excluded) ║
║ 2. git diff --cached → pom.xml ║
║ 3. extractCommitMessage → "Update pom.xml" ║
║ 4. git commit -m "Update pom.xml" ║
║ ║
║ ┌─────────────────────────────────────────────────────┐ ║
║ │ PROTECTION TRIAD: │ ║
║ │ → NOT activated (Level 1.5 is deterministic) │ ║
║ │ → The commit is a user operation, not the LLM's │ ║
║ │ → Zero hallucination risk │ ║
║ └─────────────────────────────────────────────────────┘ ║
║ ║
║ Result: [master abc1234] Update pom.xml ║
╚══════════════════════════════════════════════════════════════════╝
7. Fallback for Small Models (7B)
7.1 The Problem: "JSON Leakage"
7B parameter models sometimes write tool calls as plain text instead of using the structured tool_calls field of the OpenAI response:
Fararoni: {"name": "GitAction", "arguments": {"action": "branch", "params": "develop"}}
{"name": "GitAction", "arguments": {"action": "commit", "params": "-m 'fix'"}}
The ToolExecutor never sees these because they're in content, not in tool_calls.
7.2 The Solution: extractTextToolCalls()
A parser that scans the response text looking for JSON objects with "name" + "arguments":
LLM Response (content text)
│
▼
extractTextToolCalls(contentText)
├── Search for '{' in text
├── Count braces to find closure (supports nested JSON)
├── Parse as JSON
├── Verify it has "name" + "arguments"
└── Execute via ToolExecutor
This turns a "broken" model into a functional one, without changing the model.
8. Capability Comparison
| Level | Nature | Mechanism | Kill-Switch | Shadow | Latency |
|---|---|---|---|---|---|
| 1: Bare | Deterministic | ProcessBuilder | NO | NO | ~0ms |
| 1.5: Composite | Heuristic | Regex + Shell | NO | NO | ~0ms |
| 2: GGUF | Local Stochastic | LLM 1.5B | NO | NO | ~1s |
| 3: Tool Calling | Stochastic/Agentic | LLM + 31 Tools | YES | YES | 8-10s |
| 4: Thinking | Reasoning | DeepSeek/Qwen3 | NO | NO | 10-15s |
| 5: Fallback | Stochastic | Plain VllmClient | NO | NO | 2-5s |
9. Results
9.1 Latency Reduction
┌────────────────────────────────────────────────────────────────────────┐
│ LATENCY BY OPERATION TYPE │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ pwd (before, with LLM): ████████████████████████████████ 10s │
│ pwd (Level 1, no LLM): █ 0ms │
│ Improvement: -100% │
│ │
│ "hello" (before, w/tools): ████████████████████████████████ 10s │
│ "hello" (Level 2, GGUF): ████ 1s │
│ Improvement: -90% │
│ │
│ git status (before, LLM): ████████████████████████████████ 8s │
│ git status (Level 1): █ 0ms │
│ Improvement: -100% │
│ │
│ "do the commit" (before): ████████████████████████████████ 10s │
│ "do the commit" (L 1.5): █ 0ms │
│ Improvement: -100% │
│ │
└────────────────────────────────────────────────────────────────────────┘
9.2 Integrity Protection
┌────────────────────────────────────────────────────────────────────────┐
│ PROTECTION EFFECTIVENESS │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ Layer 1 (Kill-Switch): │
│ ████████████████████████████████████████████████████████ 99.9% │
│ Blocked by Jaccard/Volume │
│ │
│ Layer 2 (Git Saga): │
│ ████████████████████████████████████████████████████████ 99.99% │
│ Contained via ephemeral branch + auto-revert │
│ │
│ Layer 3 (Shadow Backup): │
│ ██████████████████████████████████████████████████████████ 100% │
│ Recovered from shadow files │
│ │
│ RESULT: 0 PERMANENT LOSSES │
└────────────────────────────────────────────────────────────────────────┘
10. Conclusion
The Fararoni Kernel demonstrates that secure and efficient LLM integration in software development requires a hybrid architecture that combines:
- Intelligent Routing: 60-70% of interactions are resolved in the deterministic zone (Levels 1-2), eliminating latency and hallucinations for operational tasks.
- Defense in Depth: The remaining 30-40% passes through the Protection Triad, where each layer captures escapes from the previous one until reaching 0% permanent loss.
-
Small Model Adaptability: The text fallback (
extractTextToolCalls) enables using 7B parameter models that don't properly handle the tool calling protocol, democratizing access to these capabilities.
The explicit separation between the deterministic zone and the stochastic zone is not just a performance optimization: it is a security principle. By making the LLM "never know" about trivial commands, we eliminate the widest attack surface. And by shielding the points where the LLM DOES operate, we guarantee that its stochastic nature cannot cause permanent damage.
References
- Cruz, E. (2026). Fararoni Ironclad: Deterministic Guardrails for Code. Technical Report v3.
- OWASP LLM Top 10 (2025). Security Risks in Large Language Model Applications.
- IEEE/ACM ICSE (2025). Proceedings on AI-Assisted Software Engineering.
## Try It
brew tap ebercruzf/fararoni && brew install fararoni
Also available as standalone binaries for macOS, Linux & Windows.
About the Author
Eber Cruz Fararoni is a software engineer with a decade of experience designing backend infrastructure and distributed systems.
Currently focused on AI-assisted software engineering, deterministic guardrails, and hybrid kernel architectures for secure LLM execution.
This article documents the architecture behind C-FARARONI, an experimental ecosystem for technological
sovereignty and secure local AI model execution.
LinkedIn · GitHub · ebercruz.com
Canonical source: fararoni.dev/publicacion/kernel-hibrido
Top comments (0)