Skip to main content
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

ConcernImpact
Integrity of AI systemsMalicious injections can steer model behavior or corrupt the backends an agent depends on.
Data confidentialityInjection and SSRF attacks can exfiltrate data from services exposed to a tool chain.
Regulatory complianceMost frameworks mandate input validation and transport-level controls on user-provided data.
Brand reputationSecurity 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:
DetectionWhat it catchesTypical action
Injection ProtectionSQL / NoSQL / command / path traversal / SSRF / XML / LDAP / template / XPath / header injection payloads.Block (403)
Code SanitationCode-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 ControlCross-origin requests from browsers that violate the configured allow-list.Block (403)
IP WhitelistRequests from IPs or CIDR ranges outside the allow-list.Block (403)
All four run at the pre-request stage — before the request is forwarded to the upstream LLM or tool.

​
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 typeExample signatures
SQLUNION SELECT, DROP TABLE, stacked queries, comment-based injection.
NoSQLMongoDB operators like $where, $regex.
Commandsystem(), 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.
SSRFfile://, dict://, localhost and private-IP references, DNS rebinding.
File Inclusioninclude(), require() patterns.
Template{{.}}, ${...}, expression-language payloads.
XPath//, contains() and other XPath operators used maliciously.
HeaderCRLF injection (\r\n, \n\n) in request headers.

​
SQL-injection subcategories

CategoryTechniques
Union-basedUNION SELECT, stacked queries, comment-based injections.
Error-basedType conversion, XPATH errors, deliberate syntax errors.
Time-basedSLEEP(), 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 partChecks
HeadersKey-value pair inspection, size validation, encoding verification, protocol compliance.
Path & queryParameter inspection, value validation, encoding (and double-encoding) checks, length limits.
BodyContent parsing (JSON, form-data), recursive deep-object inspection, array handling, size validation.
The engine uses pre-compiled regex patterns, case-insensitive matching, and custom-pattern registration for workspace-specific rules.

​
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

LanguageExample patterns
JavaScripteval(), Function(), setTimeout() with strings, innerHTML, document.write, on* handlers.
Pythonexec(), eval(), compile(), __import__(), os.system, subprocess.Popen.
PHPeval(), system().
SQLUNION SELECT, DROP TABLE.
ShellDirect execution, shell metacharacters, command substitution, permission changes.
JavaRuntime.exec().
C#Process.Start().
Rubyeval(), exec().
HTML<script>, onerror=, other markup-injection vectors.

​
Block vs sanitize

ModeBehaviorTypical use
BlockReturns an HTTP error (default 400) with a configurable message.Strict routes — any code in input is anomalous.
SanitizeReplaces 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.
Particularly important for codegen agents, MCP tools that run code, and routes that accept inline scripts.

​
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-Origin
    • Access-Control-Allow-Methods
    • Access-Control-Allow-Credentials
    • Access-Control-Allow-Headers
    • Access-Control-Expose-Headers
    • Access-Control-Max-Age
  • Rejects violations with 403 Forbidden (origin) or 405 Method Not Allowed (preflight).

​
Configuration

ParameterPurposeDefault
allowed_originsExact origins or ["*"] for all.— (required)
allowed_methodsGET, POST, PUT, DELETE, etc.— (required)
allow_credentialsWhether cookies / auth headers travel cross-origin. Must be false if allowed_origins contains "*".false
expose_headersResponse headers exposed to the client.[]
max_agePreflight cache TTL (e.g. "12h")."1h"
log_violationsLog 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

ParameterPurposeDefault
enabledTurn enforcement on or off without removing the plugin.false
ipsExact IPv4 / IPv6 addresses to allow (e.g. 203.0.113.5, 2001:db8::1).[]
cidrsAllowed CIDR ranges (e.g. 203.0.113.0/24, 2001:db8::/32).[]
When 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.