Documentation Index
Fetch the complete documentation index at: https://docs.neuraltrust.ai/llms.txt
Use this file to discover all available pages before exploring further.
Not every attack on an AI system looks AI-specific. Application security covers the controls you’d expect from any mature API gateway, now applied to LLM and agent traffic before anything reaches the model or a downstream tool.
These detections focus on the HTTP transport layer — the shape, origin, and content of the request itself — rather than the semantics of the prompt. They pair naturally with Prompt Guard, data protection, and content moderation in layered policies.
Why it matters
| Concern | Impact |
|---|
| Integrity of AI systems | Malicious injections can steer model behavior or corrupt the backends an agent depends on. |
| Data confidentiality | Injection and SSRF attacks can exfiltrate data from services exposed to a tool chain. |
| Regulatory compliance | Most frameworks mandate input validation and transport-level controls on user-provided data. |
| Brand reputation | Security incidents caused by classic web exploits erode trust just as quickly as model-specific ones. |
Where it lives in the picker
Application-security detections live under the Application Security category in Create Policy → When. The category exposes four detections:
| Detection | What it catches | Typical action |
|---|
| Injection Protection | SQL / NoSQL / command / path traversal / SSRF / XML / LDAP / template / XPath / header injection payloads. | Block (403) |
| Code Sanitation | Code-like input (JS, Python, PHP, SQL, Shell, Java, C#, Ruby, HTML) that could trigger RCE or sandbox bypass. | Block (403) or in-place sanitization |
| CORS Control | Cross-origin requests from browsers that violate the configured allow-list. | Block (403) |
| IP Whitelist | Requests from IPs or CIDR ranges outside the allow-list. | Block (403) |
Injection Protection
Protects against payloads that target downstream interpreters (the classic web injection families), not the model itself. Relevant whenever prompts or tool arguments can reach a database, a shell, a template engine, a browser, or any system component that evaluates input.
Attack types detected
| Attack type | Example signatures |
|---|
| SQL | UNION SELECT, DROP TABLE, stacked queries, comment-based injection. |
| NoSQL | MongoDB operators like $where, $regex. |
| Command | system(), exec(), shell metacharacters (;, |, backticks). |
| Path Traversal | ../, ..\\, absolute paths (/etc/passwd), URL-encoded variants (%2e%2e%2f). |
| LDAP | (cn=*), directory query manipulation. |
| XML | <!ENTITY, XXE payloads, SYSTEM declarations. |
| SSRF | file://, dict://, localhost and private-IP references, DNS rebinding. |
| File Inclusion | include(), require() patterns. |
| Template | {{.}}, ${...}, expression-language payloads. |
| XPath | //, contains() and other XPath operators used maliciously. |
| Header | CRLF injection (\r\n, \n\n) in request headers. |
SQL-injection subcategories
| Category | Techniques |
|---|
| Union-based | UNION SELECT, stacked queries, comment-based injections. |
| Error-based | Type conversion, XPATH errors, deliberate syntax errors. |
| Time-based | SLEEP(), BENCHMARK(), heavy queries that reveal info via timing. |
What gets analyzed
Injection Protection dissects the full HTTP request — not just the body — and checks for patterns everywhere structured input can hide:
| Request part | Checks |
|---|
| Headers | Key-value pair inspection, size validation, encoding verification, protocol compliance. |
| Path & query | Parameter inspection, value validation, encoding (and double-encoding) checks, length limits. |
| Body | Content parsing (JSON, form-data), recursive deep-object inspection, array handling, size validation. |
Code Sanitation
Ensures code-like input or instructions don’t trigger remote code execution, sandbox bypass, or unsafe evaluation downstream. Two modes: block the request outright, or sanitize the dangerous fragments in-place and forward the scrubbed request.
Supported languages
| Language | Example patterns |
|---|
| JavaScript | eval(), Function(), setTimeout() with strings, innerHTML, document.write, on* handlers. |
| Python | exec(), eval(), compile(), __import__(), os.system, subprocess.Popen. |
| PHP | eval(), system(). |
| SQL | UNION SELECT, DROP TABLE. |
| Shell | Direct execution, shell metacharacters, command substitution, permission changes. |
| Java | Runtime.exec(). |
| C# | Process.Start(). |
| Ruby | eval(), exec(). |
| HTML | <script>, onerror=, other markup-injection vectors. |
Block vs sanitize
| Mode | Behavior | Typical use |
|---|
| Block | Returns an HTTP error (default 400) with a configurable message. | Strict routes — any code in input is anomalous. |
| Sanitize | Replaces matching fragments with a configurable character (default X) in-place and forwards the scrubbed request upstream. | Tolerant routes — users may include snippets legitimately, you just don’t want them executed. |
CORS Control
Manages Cross-Origin Resource Sharing for browser-facing endpoints. Enforces which domains may call TrustGate APIs from web apps and browser extensions, preventing unauthorized cross-origin access and data leakage via malicious web clients.
How it works
- Runs at the pre-request stage, before routing upstream.
- Validates the
Origin header against the configured allow-list.
- Validates the HTTP method on preflight (
OPTIONS) requests.
- Dynamically sets response headers:
Access-Control-Allow-OriginAccess-Control-Allow-MethodsAccess-Control-Allow-CredentialsAccess-Control-Allow-HeadersAccess-Control-Expose-HeadersAccess-Control-Max-Age
- Rejects violations with
403 Forbidden (origin) or 405 Method Not Allowed (preflight).
Configuration
| Parameter | Purpose | Default |
|---|
allowed_origins | Exact origins or ["*"] for all. | — (required) |
allowed_methods | GET, POST, PUT, DELETE, etc. | — (required) |
allow_credentials | Whether cookies / auth headers travel cross-origin. Must be false if allowed_origins contains "*". | false |
expose_headers | Response headers exposed to the client. | [] |
max_age | Preflight cache TTL (e.g. "12h"). | "1h" |
log_violations | Log denied cross-origin attempts. | false |
Best practices
- Explicit origins — never use
"*" in production unless you absolutely must.
- No credentials with wildcard — the spec forbids it; TrustGate blocks the combination.
- Turn on
log_violations during rollout to catch misconfigured clients.
- Cache preflight — bump
max_age to reduce redundant OPTIONS round-trips.
IP Whitelist
Restricts access to your routes or applications by client IP. Only requests from explicitly allowed IPs or CIDR ranges are permitted; everything else is rejected with 403 Forbidden.
How it works
- Runs at the pre-request stage.
- Extracts the client IP from the connection fingerprint.
- Allows the request only if the IP matches one of the configured entries.
- If the IP can’t be determined, the request is denied.
Configuration
| Parameter | Purpose | Default |
|---|
enabled | Turn enforcement on or off without removing the plugin. | false |
ips | Exact IPv4 / IPv6 addresses to allow (e.g. 203.0.113.5, 2001:db8::1). | [] |
cidrs | Allowed CIDR ranges (e.g. 203.0.113.0/24, 2001:db8::/32). | [] |
enabled is true, at least one of ips or cidrs must be set.
Best practices
- Tight allow-lists — review periodically and remove stale entries.
- CIDR for networks, exact IPs for fixed hosts — don’t list 254 addresses when one CIDR describes them.
- Layer with rate limiting and bot detection for real perimeter protection — IP allow-listing alone isn’t a strategy.
- Log blocked attempts so you can investigate unauthorized access patterns.
Using application security in a policy
Standard Where / When / Then:
- Where — typically the
Gateway surface, scoped to the routes that expose risk (routes backed by tools, codegen routes, browser-facing endpoints, internal-only APIs).
- When —
Input · triggers · Application Security: Injection Protection (and/or)Input · triggers · Application Security: Code Sanitation (and/or)Input · triggers · Application Security: CORS Control (and/or)Input · triggers · Application Security: IP Whitelist.
- Then — usually
Block. Injection, unsafe code, bad origins, and unauthorized IPs rarely have legitimate uses.
Per the policy model, multiple rows in the same policy AND together. Use separate policies if you need OR semantics or different actions per detection.
Common policies
- Block SQL / NoSQL / command injection on tool-enabled routes —
Where: Gateway · Routes /agents/* · When: Input · triggers · Application Security: Injection Protection · Then: Block.
- Sanitize inline code in a data-analysis assistant —
Where: Gateway · Routes /data-copilot/* · When: Input · triggers · Application Security: Code Sanitation · Then: Block (with the plugin’s action set to sanitize if you want pass-through with scrubbing).
- Lock down internal admin routes by IP —
Where: Gateway · Routes /admin/* · When: Input · triggers · Application Security: IP Whitelist · Then: Block. Pair with corporate VPN CIDRs.
- Enforce CORS on the chat widget — configure allowed origins on the widget’s route;
When: Input · triggers · Application Security: CORS Control · Then: Block.
- Layer transport and prompt controls — one policy blocks
Injection Protection, another blocks Jailbreak (Prompt Guard). Each attack surface has a clear owner, and both fire independently.
- Log everything for a week, then enforce — clone any of the above with
Then: Log to establish a baseline before flipping to Block.
