Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lasscyber.com/llms.txt

Use this file to discover all available pages before exploring further.

Agnes ships seven analyzers. Each is a self-contained detector with its own implementation (BERT classifiers, LLM-as-judge, Google Cloud APIs, the YARA engine, vector similarity). You compose them inside a combined policy; your code calls the combined policy, never an analyzer directly.

​
The seven canonical analyzers

Canonical nameFriendly nameWhat it detectsImplementation
prompt-injection-jailbreakPrompt Injection & Jailbreak DetectionInjection / jailbreak promptsBERT-family classifiers (Llama Prompt Guard, DeBERTa, ONNX defenders) on the model service
safe-responsible-aiSafety & Responsible AI GuardrailsHate, harassment, dangerous content, sexual contentShieldGemma 2B / 9B / 27B via vLLM
sensitive-dataSensitive Data ProtectionPII, PHI, credentials, financial identifiersGoogle Cloud DLP / SDP
natural-languageNatural Language AnalysisSentiment, entities, topics, moderationGoogle Cloud Natural Language
url-riskMalicious URL DetectionMalware, phishing, unwanted-software URLsURL extraction + Google Web Risk
yaraYara Rule EnforcementCustomer-defined patternsYARA engine, in-process
semantic-threat-intelligenceSemantic Threat IntelligenceParaphrased / novel attacks similar to known onesVertex AI embeddings + pgvector cosine similarity
The canonical name (kebab-case) is what the SDKs and dashboard use. The Python SDK exposes them in snake_case, the TypeScript SDK in camelCase. Server-side keys (e.g. adversarial_detection_analyzer, safety_moderation_analyzer) are an internal detail you’ll only see in raw policy JSON.

​
When to enable each

Reach for analyzers in this order if you are starting from a blank policy:
  1. Always-on cheap signals: yara, url-risk, sensitive-data. They cost milliseconds and catch a large class of attacks before you spend GPU on the classifier.
  2. Adversarial classifier: prompt-injection-jailbreak. The single most valuable analyzer for inbound traffic. Use the 22M model for latency, 86M for accuracy on hard cases.
  3. Safety judge: safe-responsible-ai. Most useful on outbound responses. On inbound it overlaps with the prompt-injection classifier; on outbound it earns its keep catching unsafe model completions.
  4. Threat intel: semantic-threat-intelligence. Fast (vector compare) but adds Vertex embedding cost. Worth turning on once you have ingested known-bad prompts via the Workbench.
  5. Linguistic signals: natural-language. Useful as a flag rather than a block; sentiment and entity counts are noisy termination signals.
The default-inbound policy uses analyzers 1–3; default-outbound swaps the order to weight the safety judge first. See Combined analyzer for both.

​
What each page covers

Every analyzer page below is structured the same way:
  • What it detects — the threat model.
  • How it works — the implementation, model IDs, and external dependencies.
  • Parameters — config knobs you can set in a policy.
  • Outputs and metrics — what shows up in analyzer_results and the metrics map.
  • Termination signals — boolean and match signals available for termination rules.
  • Limits and cost — request budget, tokens, and where the cost goes.
  • When to use it — guidance on inbound vs outbound, latency, noisy categories.

​
Source of truth

The analyzer catalog at api/data/analyzer_catalog.py is the single source of truth for parameters, metrics, model IDs, and limits. The dashboard policy editor and these docs both render from that catalog. If you spot a mismatch, file a ticket — the catalog is canon.