GuardianMesh – AI Agent Security Orchestrator

GuardianMesh is a security gateway for LLM‑powered agents.
It sits between AI agents and real systems (databases, APIs, file stores) and decides, for every action, whether it should be allowed, blocked, or require human approval before execution.

It combines:

• A config‑driven static rules engine for fast, deterministic policy checks.
• An optional LLM‑based safety layer that reviews risky actions, classifies their severity, and can reinforce or override decisions with reasoning.

---

1. Problem & Motivation

LLM agents can generate powerful actions:

• SQL queries on production databases.
• API calls to internal services.
• File writes, shell commands, and more.

Without guardrails, a single prompt can cause:

• Destructive operations (e.g. DELETE or DROP TABLE on production tables).
• Leakage of PII or sensitive data to external LLM APIs.
• Bulk reads on sensitive customer data without any approval.

GuardianMesh solves this by acting as a policy and safety orchestrator:

• Every agent action is sent to GuardianMesh first.
• GuardianMesh evaluates the action against configurable security policies and optionally an LLM “security analyst”.
• Only vetted, low‑risk actions are allowed to reach production systems.

---

2. High‑Level Architecture

Conceptual flow:

1. Agent / Application decides to perform an action.
2. It sends a JSON description of the action to GuardianMesh via POST /guardrail/action.
3. GuardianMesh:
   • Evaluates the action against a JSON rules config (config/rules.json).
   • Optionally calls an LLM safety API (OpenAI) for medium / high‑risk or ambiguous actions.
4. GuardianMesh returns a structured decision:
   • allow: true / false
   • riskLevel: low / medium / high / critical
   • reason, message, optional requiresApproval
   • flags like llmUsed and piiDetected
5. All decisions are logged and surfaced via /logs and /summary.

Simple diagram (conceptual):

LLM Agent / App → GuardianMesh (Config Rules + LLM Safety) → Databases / APIs / Services

---

3. Tech Stack

• Backend: Node.js, Express
• Language: JavaScript
• APIs: REST (JSON over HTTP)
• Policy Engine: Config‑driven rules in config/rules.json
• AI Integration: Optional OpenAI API for LLM safety analysis
• Testing / Demo: Postman (collection with safe vs dangerous scenarios)
• Logging & Analytics: Log store + /logs and /summary endpoints

---

4. Key Features

4.1 Config‑Driven Static Rules Engine

Static guardrails are defined in config/rules.json, not hard‑coded if‑else blocks.
Examples of rules:

• No DROP on production databases

  {
    "id": "no_prod_drop",
    "match": {
      "action_type": "sql_query",
      "target_prefix": "prod_"
    },
    "conditions": [
      { "type": "payload_regex", "pattern": "DROP" }
    ],
    "decision": {
      "allow": false,
      "riskLevel": "critical",
      "reason": "rule:no_prod_drop",
      "message": "Cannot execute DROP commands on production databases"
    }
  }
  

Block sending PII to external LLM APIs

json { "id": "external_llm_pii_blocked", "match": { "action_type": "llm_query", "target": "external" }, "conditions": [ { "type": "payload_has_pii" } ], "decision": { "allow": false, "riskLevel": "high", "reason": "rule:external_llm_pii_blocked", "message": "Cannot send PII to external LLM APIs", "piiDetected": true } } SELECT * on sensitive tables requires approval

Safe SELECT queries are allowed

Safe updates on non‑prod environments are allowed

Because rules are JSON‑based, security teams can add new policies without touching application code.

4.2 LLM‑Based Safety Layer (Optional) For medium / high‑risk or ambiguous actions, GuardianMesh can call an LLM safety reviewer:

Input: agent_id, action_type, target, payload.

Output (JSON):

recommendation: "allow" | "block" | "require_approval"

riskLevel: "low" | "medium" | "high" | "critical"

confidence: 0.0–1.0

risksDetected: e.g. ["destructive_sql", "prod_access"]

reasoning: one‑sentence explanation

The /guardrail/action endpoint then combines static and LLM decisions:

Static rules quickly block obvious violations (e.g. DELETE without WHERE).

LLM analysis refines the risk level and can recommend block or human approval for tricky cases.

The response includes llmUsed (boolean) and, when applicable, llmAnalysis.

4.3 Guardrail Evaluation API POST /guardrail/action

Evaluates an agent action and returns a decision.

Example request (dangerous):

json { "agent_id": "devops-bot", "action_type": "sql_query", "target": "prod_db", "payload": "DELETE FROM customers" } Example response:

json { "allow": false, "reason": "rule:delete_without_where", "riskLevel": "high", "message": "DELETE without WHERE clause could delete all records", "requiresApproval": false, "timestamp": "2026-03-06T12:48:40.504Z", "processingTime": 2975, "llmUsed": true } 5. Health, Logs & Summary 5.1 Health Check GET /health

Returns basic service and configuration status:

json { "status": "healthy", "service": "GuardianMesh", "version": "1.0.0", "timestamp": "2026-03-06T12:00:00.000Z", "llmEnabled": true } 5.2 Logs GET /logs – recent guardrail decisions (optional ?limit=).

GET /logs/:agentId – decisions filtered by agent_id.

Each log entry can include:

action metadata (agent, type, target),

static decision,

LLM analysis (when used),

final decision, risk, and timestamps.

5.3 Summary Dashboard GET /summary

Aggregated view of decisions, for example:

json { "totalActions": 123, "allowed": 80, "blocked": 30, "requiresApproval": 13, "llmEnabled": true, "generatedAt": "2026-03-06T12:05:00.000Z" } This makes GuardianMesh useful as a mini monitoring dashboard for AI agent behavior.

6. Test Utilities 6.1 PII Detection POST /test/pii-detection

Tests PII detection logic:

json { "text": "My name is John Doe and my SSN is 123-45-6789." } Response:

json { "text": "My name is John Doe and my SSN is 123-45-6789.", "piiDetected": true, "timestamp": "2026-03-06T12:10:00.000Z" } 6.2 Rules Engine Test POST /test/rules

Directly tests the static rules engine without full logging/LLM:

json { "agent_id": "devops-bot", "action_type": "sql_query", "target": "prod_db", "payload": "DROP TABLE customers" } Response (example):

json { "action": { "agent_id": "devops-bot", "action_type": "sql_query", "target": "prod_db" }, "decision": { "allow": false, "reason": "rule:no_prod_drop", "riskLevel": "critical", "message": "Cannot execute DROP commands on production databases" }, "timestamp": "2026-03-06T12:15:00.000Z" } 7. Installation & Setup 7.1 Prerequisites Node.js (LTS recommended)

npm or yarn

(Optional) OpenAI API key for LLM safety layer

7.2 Clone & Install bash git clone https://github.com//.git cd npm install 7.3 Environment Variables Create a .env file in the project root:

text PORT=4000 ENABLE_LLM_SAFETY=true

Optional: real key for LLM safety

OPENAI_API_KEY=your-real-openai-key .env is included in .gitignore and should never be committed.

8. Running the Server Development / Local bash npm start or

bash npm run dev You should see logs like:

Server running on http://localhost:4000

Dashboard: http://localhost:4000/summary

Logs: http://localhost:4000/logs

LLM Enabled: YES/NO

9. Demo Usage (Postman or any REST client) 9.1 Health Check Method: GET

URL: http://localhost:4000/health

9.2 Safe Action (Allowed) Method: POST

URL: http://localhost:4000/guardrail/action

Headers: Content-Type: application/json

Body:

json { "agent_id": "report-bot", "action_type": "read_only_query", "target": "analytics_db", "payload": "SELECT COUNT(*) FROM sales WHERE date >= '2026-01-01'" } Expected: allow: true, low risk.

9.3 Dangerous Action (Blocked) Method: POST

URL: http://localhost:4000/guardrail/action

Headers: Content-Type: application/json

Body:

json { "agent_id": "devops-bot", "action_type": "sql_query", "target": "prod_db", "payload": "DELETE FROM customers" } Expected:

allow: false

riskLevel: high or critical

reason like "rule:delete_without_where"

llmUsed: true if LLM safety is enabled

Use /logs and /summary to see the effects over time.

10. Why This Project Matters GuardianMesh demonstrates:

Backend engineering: Express API design, structured logging, error handling, config‑driven rules.

AI + security thinking: LLM guardrails, PII protection, production vs non‑production separation.

Real‑world patterns: Health checks, monitoring endpoints, JSON policy engine, secret management (.env / .gitignore).

It’s designed as a portfolio‑grade project that can be extended into a full AI security gateway.

11. Future Enhancements Richer rule types (rate limits, time windows, per‑agent roles).

UI dashboard for logs and summary charts.

Support for multiple LLM providers and ensemble safety checks.

Integration with external SIEM / monitoring tools.

12. License Add your preferred license here (e.g. MIT).

13. Author Name: Pavani

GitHub: https://github.com/pavani-n-hash

LinkedIn: https://www.linkedin.com/in/pavani-chowdary-54a62a343/