If vLLM already solved LLM serving, why did SGLang appear?
This guide covers everything you need to add LLM Shield to an existing application: what it is, how the ‘two-call’ pattern works, the full API reference, working code in Python and Node.js, and how to configure and tune policies from the dashboard. By the end of this read you will have Shield running on a live endpoint.
Note: If you’re a Neysa Velocis customer, you’re all set! We’ve already handled the integration for you.
What is Neysa Aegis LLM Shield?
If you’re running an LLM in production, you probably have a system prompt and you’re relying on the model’s built-in safety training. Neither of those were designed for policy enforcement. System prompts can be leaked or bypassed. Safety training is the model vendor’s policy, not yours. And nothing gets logged.
LLM Shield is a security layer that wraps your LLM calls. You call it before sending a prompt to the model, and again before returning the model’s response to the user. It blocks prompt injection, redacts PII, enforces topic boundaries, and logs every decision. It doesn’t touch your model or your infrastructure. And this works with any model on any cloud. Get the product overview here.
Before You Start
Before you begin your journey with the LLM Shield, you need three things from the Aegis dashboard to make any API calls:
i. Access token: Authenticates every request. Goes in the Authorization – Bearer <token> header. Keep it server-side.
ii. Instance ID: An instance is a configured deployment of LLM Shield. It stores your policies – which filters are active, at what sensitivity, which topics are allowed, what to return when something gets blocked. When you create an instance in the dashboard, you get an instance Id. You pass this on every call. You can run one instance across multiple apps, or create separate instances if you need different policies per app (stricter for customer-facing, looser for internal).
iii. User group: lets you segment enforcement within one instance. Different user groups can have different rate limits, topic scope, or PII rules. If you don’t need segmentation, pass “default”.
The integration pattern
Two extra API calls in your existing LLM flow. That’s it.
Note: Aegis does not proxy your LLM call. It evaluates and returns a verdict. Your application handles what to do with it.
The API
Single endpoint for both input and output:
POST: https://aegis.neysa.io/api/external/v2/aegisfilters
| Field | Required | Notes |
| instanceId | Yes | Which policy set to apply |
| userGroup | Yes | Which group rules to apply. Use “default” if not segmenting |
| prompt | One or the other | Pass this for input filtering |
| response | One or the other | Pass this for output filtering |
Never pass both prompt and response in the same request.
curl examples
Before calling the model:
Before returning to the user:
The response
Aegis runs multiple filters in parallel. Each one reports its own verdict independently.
Filter prefixes:
| Prefix | Filter | Catches |
| pif_ | Prompt injection | Jailbreaks, instruction overrides, system prompt extraction |
| txg_ | Toxicity / content | Harmful, abusive, or policy-violating language |
| pii_ | PII | SSNs, Aadhaar, IBANs, health data, financial identifiers |
Each filter returns three fields: _api_action (what to do), _response_message (what to show the user on a block), _intensity (confidence level).
Verdicts:
| Value | What it means |
| ALLOW | Clean. Continue. |
| BLOCK | Policy violation. Stop. Return _response_message to the user. |
| REDACT | PII detected. pii_redacted_text has the sanitized version. Use that. |
| TAG | Flagged but not blocked. Log it, proceed. |
Precedence when multiple filters fire:
BLOCK > REDACT > TAG > ALLOW
If any filter returns BLOCK, block. If no BLOCK but a REDACT, use the redacted text. If only TAG, log and continue.
On REDACT: pii_redacted_text contains the original input with sensitive values swapped for placeholders like [REDACTED-SSN]. Pass that to your model instead of the raw input. Same logic applies to output: show the user the redacted text, not the original model response.
Python
import requests
Node.js
What Gets Checked
On prompt:
- Prompt injection and jailbreak attempts
- PII: SSNs, Aadhaar, IBANs, health data, financial identifiers (US, UK, India, Singapore, Europe)
- SQL and DML injection
- Out-of-scope queries based on topic boundaries you configure
- Rate limits per usergroup, app, and endpoint
On response:
- System prompt leakage
- PII in model output
- Policy-violating or harmful content
- Nonsensical or incoherent output
Every decision is logged with a filter name, confidence level, and a verdict. PII is masked in logs by default. Each request returns a trackingId so you can trace any decision back to a specific interaction.
Secure Every LLM Interaction
Protect LLMs against prompt injection, unsafe outputs, and data leakage.
Configuring policies
Policies are set in the Aegis dashboard, not in code. Set them once per instance; they apply to every API call using that instanceId.
Per instance, you configure:
- Which filters are active (PII, prompt injection, toxicity)
- Sensitivity per filter. False positives are common with AI detection; dial it down per filter from the dashboard without touching your code
- Topic scope: what the model is allowed to discuss. Queries outside that scope get blocked
- Refusal messages: the exact text returned to users on a block, configurable per filter type
- Rate limits per usergroup, app, and endpoint
- RBAC: separate roles for global policy admin and per-instance admin
Changes take effect immediately on the next request.
False positives
Check _intensity when a filter fires unexpectedly:
- “Recommended”: high confidence, likely legitimate
- “Over-sensitive”: lower confidence, worth reviewing
Adjust sensitivity per filter from the dashboard. No redeploy.
Getting started
Request access at neysa.ai/aegis-llm-shield. The self-guided setup covers instance creation, policy config, and live endpoint testing. Takes under ten minutes.
