Chapter 0: Quickstart Walkthrough — "Seeing is Believing" Hands-On Demo

Security architectures are often presented in abstract concepts. The goal of this walkthrough is to provide an immediate, hands-on demonstration of the difference between standard perimeter-only LLM applications and deterministic, code-level Policy Enforcement Points (PEPs).

By pairing the langchain-security-extension library with its live companion reference demonstrator, langchain-enterprise-incident-assistant, you will run functional and adversarial tests against two Git branches:

• main branch (Unhardened Baseline): A standard FastAPI + LangChain IT Incident Assistant with HTTP Bearer JWT authentication, standard prompt-based instructions, and native tool execution. Demonstrates how easily standard LLM applications are exploited via prompt injection, argument tampering, cross-tenant RAG leaks, and runaway loops.
• secured branch (Hardened Target): The identical application hardened with langchain-security-extension. Demonstrates how code-level PEPs deterministically intercept every exploit before LLM tokens are wasted or unauthorized Python callables run.

Step 1: Environment & Repository Setup

1. Prerequisites

• Python 3.9+: A shared Python virtual environment.
• Configured LLM Service(s): The demonstrator issues real model calls across a multi-agent pipeline. Both model1 (used by the Triage Agent) and model2 (used by the Remediation Agent) must be configured in config.properties. By default, both connect to a local Ollama instance (http://localhost:11434 with model llama3.2:3b). They can be the exact same model or different models, and can be directed to any OpenAI, Gemini, or Claude compatible endpoint.

2. Clone the Companion Demonstrator

Clone the companion incident assistant demonstrator into your workspace:

# Create and activate a virtual environment
python3 -m venv .venv
source .venv/bin/activate

# Clone the companion incident assistant demonstrator
git clone https://github.com/prashantdev/langchain-enterprise-incident-assistant.git
cd langchain-enterprise-incident-assistant

3. Install Assistant Dependencies

Install the assistant application and testing dependencies in development mode:

# Install base assistant and test dependencies
pip install -e ".[dev]"

Security Extension Dependency: The main branch represents an unhardened baseline and has zero security dependencies. The secured branch includes langchain-security-extension directly in its pyproject.toml dependencies. When you switch to the secured branch in Step 3, simply run pip install -e . (or pip install langchain-security-extension) to install the security library.

(Optional for Library Contributors) If you are actively developing or modifying langchain-security-extension locally, clone the library repository side by side and install in editable mode: git clone https://github.com/prashantdev/langchain-security-extension.git && pip install -e ./langchain-security-extension.

4. Multi-Agent Model Configuration (model1 & model2)

The companion assistant is specifically architected to demonstrate multi-agent collaboration across heterogeneous models while enforcing a standard, uniform security posture across everything:

• model1 (Triage Agent): Drives initial ticket classification, severity assessment, and entity/parameter extraction from incoming user requests.
• model2 (Remediation Agent): Drives runbook retrieval, SOP troubleshooting reasoning, and tool dispatch (e.g., executing diagnostics, restarting services, or managing access).

Both model1 and model2 must be configured in langchain-enterprise-incident-assistant/config.properties:

• Identical Models (Default): You can configure both model1 and model2 to point to the exact same model (e.g., local Ollama running llama3.2:3b). This requires minimal hardware resources and is ideal for quick local experimentation.
• Different Models: You can configure distinct models for each agent to test heterogeneous deployments (e.g., an efficient local SLM like llama3.2:3b for model1 triage, paired with a frontier reasoning model like Gemini 3.5 Flash or GPT-4o for model2 remediation).

Standard Security Across Everything (Hardened secured Branch): While the baseline main branch leaves models and tools unhardened, the hardened secured branch uses langchain-security-extension to apply identical, zero-trust security controls across all agent steps—regardless of whether model1 and model2 share the same model or use completely different local or commercial providers. This includes policy decision point (PDP) authorization, tool parameter interception, PII/credential redaction, token budgets, anti-looping protections, and SIEM audit logging.

# ---------------------------------------------------------------------------
# LLM Config - Model 1: Used by Triage Agent
# ---------------------------------------------------------------------------
model1.baseUrl=http://localhost:11434
model1.modelclass=ollama
model1.modelname=llama3.2:3b
model1.apikey=
model1.timeout=300s

# ---------------------------------------------------------------------------
# LLM Config - Model 2: Used by Remediation Agent
# (Can be the same model as model1, or a different local/frontier model)
# ---------------------------------------------------------------------------
model2.baseUrl=http://localhost:11434
model2.modelclass=ollama
model2.modelname=llama3.2:3b
model2.apikey=
model2.timeout=300s

# ---------------------------------------------------------------------------
# Example Alternative: Configuring a Frontier Model for model2
# ---------------------------------------------------------------------------
# model2.baseUrl=https://generativelanguage.googleapis.com/v1beta/openai/
# model2.modelclass=openai
# model2.modelname=gemini-3.5-flash
# model2.apikey=YOUR_API_KEY
# model2.timeout=60s

5. Verify LLM Service Availability

Ensure your configured LLM backend(s) are running. For local Ollama users:

# Ensure Ollama is active and model is pulled
ollama serve &
ollama pull llama3.2:3b

Universal LLM Reachability Check: The test runner (./run-security-suite.sh) actively queries the configured baseUrl in config.properties before executing tests. It seamlessly supports local Ollama, Google Gemini, OpenAI, Claude, or custom enterprise gateway endpoints.

Step 2: Testing the Unhardened Baseline (main Branch)

First, observe how standard perimeter security behaves under both legitimate operations and adversarial exploit attempts.

1. Checkout the main Branch & Start the Server

Open Terminal 1 to run the assistant server:

git checkout main
./startserver.sh

The server starts an embedded FastAPI service listening on port 8080.

2. Run the Basic Functional Suite (--suite basic)

In Terminal 2, run the baseline functional test suite:

./run-security-suite.sh --suite basic

Expected Outcome: All 15 / 15 tests PASS. Standard P1 outages are triaged, password resets work, and unauthenticated HTTP calls without Bearer tokens are rejected at the FastAPI perimeter.

3. Run the Guardrail Exploit Suite (--suite guardrail)

Now, run the 31 adversarial exploit tests against the unhardened baseline:

./run-security-suite.sh --suite guardrail

Expected Outcome: All 31 / 31 tests FAIL (Exploits Succeed):

• Exploit: Unauthorized employees trick the agent into rebooting production database servers (web-prod-01) via prompt overrides.
• Exploit: DevOps engineers targeting finance infrastructure bypass department checks because arguments are not validated before execution.
• Exploit: Clearance Level 1 callers retrieve classified Level 3 runbooks from ChromaDB because standard RAG lacks pre-retrieval filtering.
• Exploit: Denied tools cause the LLM to enter runaway retry loops, burning hundreds of unnecessary tokens.
• Exploit: Sensitive API keys, passwords, and PII are logged in plaintext to application logs.

Step 3: Testing the Hardened Implementation (secured Branch)

Next, switch to the hardened target implementation utilizing langchain-security-extension.

1. Checkout the secured Branch & Restart the Server

In Terminal 1, stop the running server (Ctrl+C), checkout the hardened branch, install the secured dependencies (which pulls langchain-security-extension from PyPI), and restart:

git checkout secured

# Install secured dependencies (automatically installs langchain-security-extension)
pip install -e .

./startserver.sh

2. Run the Basic Suite

In Terminal 2, re-run the basic suite to verify that hardening introduced zero regressions into legitimate workflows:

./run-security-suite.sh --suite basic

Expected Outcome: All 15 / 15 tests PASS.

3. Run the Guardrail Suite

Run the 31 adversarial exploit tests against the hardened server:

./run-security-suite.sh --suite guardrail

Expected Outcome: All 31 / 31 tests PASS (Exploits Defeated):

• @secured_tool intercepts and hard-aborts unauthorized calls in Python bytecode before tool functions run.
• Common Expression Language (CEL) rules deterministically block department mismatches (PARAMETER_CONSTRAINT_FAILED).
• SecureRetriever injects native VectorStore AST pre-filters and prunes documents before they enter the prompt context window.
• RetryBudgetTracker halts brute-force tool retry loops after consecutive policy denials.
• In-flight DLP sanitizes PII, Luhn-valid credit cards, and API secrets before telemetry is published to the background SIEM buffer.

Step 4: Trying Individual Exploit Tests

You can execute individual test scripts to inspect raw HTTP requests, agent thoughts, and diagnostic error codes in detail.

Scenario A: Testing Dynamic CEL Parameter Constraints

./internal-security-guardrail-tests/08-cel-parameter-department-mismatch-blocked.sh

What happens: An authorized DevOps user attempts to reboot finance-db-01. The @secured_tool evaluator dynamically looks up server ownership via EntityAttributeResolverSPI, detects that the server belongs to FINANCE while the caller is in INFRA, and aborts with diagnostic code PARAMETER_CONSTRAINT_FAILED.

Scenario B: Testing Indirect Prompt Injection Neutralization

./internal-security-guardrail-tests/23-prompt-injection-blocked.sh

What happens: An inbound incident ticket contains a jailbreak string attempting to override system instructions and exfiltrate secrets. The entry PEP halts execution and emits a PROMPT_INJECTION_DETECTED security event to SIEM.

Scenario C: Inspecting SIEM Audit Streaming

tail -n 15 logs/security-audit.json | jq .

What happens: Inspect the live structured RFC 5424 / OCSF audit log containing cryptographic trace correlations (W3C traceparent), redacted PII fields, and deterministic denial reason codes.

Complete Catalog of Tests in the Demonstrator

Suite 1: Basic Security Tests (15 Tests)

The basic security suite validates standard ticket triage, remediation operations, perimeter JWT validation, and RBAC baseline functionality.

Suite 2: Internal Security Guardrail Suite (31 Exploit Vectors)

The guardrail test suite evaluates zero-trust Policy Enforcement Points under active prompt injection, parameter tampering, cross-tenant leaks, and token-exhaustion loops.

Domain A: Knowledge Ingestion & Admission Control

Domain B: Pre-Execution Tool Guardrails & CEL Parameter Validation

Domain C: Secure Vector Retrieval & Context Leakage Defense

Domain D: Policy Decision Point (PDP) & Circuit Breakers

Domain E: Threat Neutralization, In-Flight DLP & SIEM Telemetry

Summary & Next Steps

Now that you have seen the difference between perimeter-only agents and zero-trust code-level PEPs in practice, proceed through the implementation chapters to explore how each component can be implemented in your enterprise applications:

• Chapter 1: Architecture Blueprint & System Boundaries — The 4 core enforcement checkpoints.
• Chapter 2: Connecting Your Identity Provider — How to pass caller identity into RunnableConfig.
• Chapter 7: Guarding Tools & Enterprise APIs — Writing Common Expression Language (CEL) parameter constraints.
• Chapter 10: SIEM & Log Aggregators — Asynchronous telemetry and compliance streaming.