ZentriqGuard — Hermes Agent-Powered Zero-Trust Access Auditor

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent
What I Built
ZentriqGuard is an adaptive zero-trust access auditing system powered by Hermes Agent, built as an extension of my ongoing project Zentriq Cloud — a quantum-resilient shard management system.
The core problem: traditional zero-trust systems are static. They check credentials at the point of request, then forget everything. They can't reason about why an access pattern is suspicious — they can only match it against rules someone wrote in advance.
ZentriqGuard flips this. Hermes Agent acts as the persistent trust reasoning layer — it monitors shard access events, builds behavioral baselines in memory, flags anomalies, and generates human-readable audit reports. The longer it runs, the better it gets at knowing what "normal" looks like for your system.
Demo
Architecture Flow
Shard Access Request
↓
[Hermes Orchestrator]
↓ reads persistent memory (behavioral baselines)
↓ evaluates request context
↓ delegates to sub-agents
↓ ↓
[Identity Verifier] [Anomaly Detector]
PQ signature check Pattern vs. memory
Credential freshness Risk scoring
↓ ↓
[Trust Decision Engine]
ALLOW / DENY / ESCALATE
↓
Audit log + memory update

Sample Hermes session output
‘‘‘
[ZentriqGuard] Evaluating access: node_7 → shard_alpha_3
[MEMORY] Baseline for node_7: avg 2.1 requests/hour, business hours only
[ANOMALY] Current: 3 AM access, 14 requests in last 30 min
[RISK SCORE] 87/100 — ESCALATE
[ACTION] Access denied. Human review flagged. Memory updated.
‘‘‘

Code

1. Install Hermes Agent
   curl -fsSL https://hermes-agent.org/install.sh | bash

2. config.yaml — ZentriqGuard profile
   profile: zentriqguard

model:
provider: openrouter
model: nous/hermes-3-405b

memory:
provider: built-in

tools:
web_search:
enabled: false
execute_code:
enabled: true

skills:
external_dirs:
- ~/.hermes/skills/zentriq/

3. Zero-Trust Anomaly Detector Skill (SKILL.md)

name: shard-access-auditor
description: ">"
Activate when evaluating shard access requests, auditing
access logs, detecting anomalies, or generating trust

decisions for zero-trust systems.

Behavior

1. Read persistent memory for the requesting node's baseline
2. Compare current request against baseline (time, frequency, volume)
3. Score risk from 0–100
4. Return: ALLOW / DENY / ESCALATE with justification
5. Update memory with this event outcome

Risk Scoring

• Off-hours access: +30
• Frequency spike (>2x baseline): +25
• New node (no baseline): +20
• Failed PQ signature: +50 (auto-DENY)
• Consistent with baseline: -10

Output Format

RISK SCORE X/100 — DECISION
[REASON] One-line justification
[ACTION] What was done

1. Spawning the auditor agent
   hermes -p zentriqguard chat -q \
   "Evaluate access: node_12 requesting shard_beta_7 at 03:14 AM. \
   14 requests in last 30 minutes. PQ signature valid."

2. Setting a persistent monitoring goal
   hermes -p zentriqguard goal \
   "Continuously monitor shard access logs at \
   ~/.zentriq/logs/access.log and flag anomalies every 15 minutes"

3. Scheduled daily audit report
   hermes -p zentriqguard cron add \
   --schedule "0 8 * * *" \
   --task "Generate daily zero-trust audit summary from yesterday's access logs"

My Tech Stack
Hermes Agent (Nous Research) — persistent memory, skill system, sub-agent delegation
Hermes 3 / Llama 3.1 — base model via OpenRouter
CRYSTALS-Kyber / CRYSTALS-Dilithium — post-quantum signature verification layer
Python — log ingestion and preprocessing scripts
SKILL.md — custom zero-trust auditor skill
How I Used Hermes Agent
Hermes Agent is doing the heavy lifting at three layers:

1. Persistent Memory as Behavioral Baseline
   Every access event updates Hermes's memory. Node_7 accessing shard_alpha at 2 PM on weekdays becomes the baseline. A 3 AM spike gets immediately flagged — not because a rule says so, but because Hermes remembers what normal looks like for that specific node.

2. Sub-Agent Delegation for Isolated Trust Checks
   The orchestrator spawns isolated sub-agents per access request — one for identity verification, one for anomaly detection. Each runs with a restricted tool set. No sub-agent has full system access. This maps directly to zero-trust's least-privilege principle.

3. Self-Improving Skill via GEPA
   The shard-access-auditor skill improves with every flagged event. After a few weeks of operation, it's not just matching rules — it's reasoning from accumulated experience specific to your infrastructure.

Why Hermes specifically?
Every other agent framework resets between sessions. For a zero-trust system, that's fatal — behavioral baselines are meaningless if they disappear at restart. Hermes's persistent memory isn't an add-on, it's the architecture. That's what made it the right tool for ZentriqGuard.