Layered Control
Layered guardrails on three axes
XGEN's controls run on three axes: harm review by an external guard model, PII detection and masking, and blocklist detection and masking. Each axis can be switched on or off independently, and detection events are always logged.
Guard Model
Guardrail model
An external guard model reviews user input for harm before it reaches the LLM, and unsafe requests are blocked before any call is made.
PII Masking
Personal data detection and masking
Regex policies detect phone numbers, national ID numbers, emails, account numbers, and similar data, masking them before the text reaches the LLM or gets embedded.
Forbidden Words
Blocklist detection and masking
Regex policies detect and mask the terms your organization has defined. Applied after PII masking, so nothing already hidden gets processed twice.
Guard Model
Harmful requests stop before they reach the LLM
The guard model activates at the workflow agent node and inspects user input before it goes to the LLM. If the request is judged unsafe, the LLM is never called and a block message is returned instead.
Detection categories
Strict filtering mode
Switched on, borderline (controversial) results also count as blockable. Switched off, only clearly unsafe requests are blocked.
Security-first operation (fail-open)
Choose what happens when the guard model call fails. In a security-first environment you turn the pass-through option off, so requests stay blocked even during an outage.
Data Protection
Personal data and blocked terms, removed from the source text
PII and blocklist policies run on regex and are managed by policy name, pattern, active state, mask string, and version. During workflow execution, PII masking runs first and blocklist masking second, so an area already hidden isn't processed again.
During workflow agent execution
Masking is applied to the user's input text before it goes to the LLM. Where an internal frame exists (system labels, JSON keys), it applies only to the user-supplied values, preserving the structure.
On document upload
A pre-check shows which items match your policies, and only the policies you select are masked before the actual upload and embedding.
When OCR is used
Text pulled out by OCR gets a supplementary pass of personal-data masking as well.
Pre-detection (detect-only)
Before the user sends any text, the server checks whether personal data or blocked terms are present — without exposing the regex patterns — and shows a warning. It flags the risk at the input stage, with no masking and nothing written to the log.
Audit & Compliance
Every control event, auditable
Events detected or blocked by PII, blocklist, or guard-model policies are written to a unified policy event log. You can filter by source, policy type, user, workflow, collection, and period, and policy creation, edits, and deletions are kept as change history with versions.
Workflow agent · execution metadata · Guarder · document upload · OCR supplement
PII · blocklist · Guarder
Matched policy ID and name, detection count, sample source text and masked result
Workflow ID · execution ID · interaction ID · node ID
Collection name · document name
User details · session ID · created at
AI Risk Governance
Managing workflow risk by grade
The AI risk-grading policy is not real-time masking. It is the reference policy for assessing the risk of a workflow or AI service, sorting risk into four levels on four principles and setting the control level accordingly.
Core principles
- Legality — Compliance with applicable law and regulation
- Reliability — Accuracy and consistency of results
- Good faith — Fair and accountable operation
- Security — Data protection and security controls
Four risk grades
- Critical — Highest risk level — requires separate controls and an approval process
- High — High risk level — subject to enhanced monitoring
- Medium — Moderate risk level — standard controls apply
- Low — Low risk level — baseline controls apply
On-Premise Architecture
The controls are completed by the on-premise security architecture
Every control policy above assumes air-gapped, on-premise deployment. An external request reaches internal services, AI models, and data only after passing the authentication gateway and the trust boundary, and every model and every piece of data runs on the internal network.
Trust-boundary access
An external request reaches internal services only after the authentication gateway converts its JWT into trusted headers. Clients cannot inject permission headers themselves.
Internal network and air-gap
From LLM serving, embedding, and guard models through to the vector DB and document storage, every AI model and every dataset runs on internal endpoints.
Policy applied consistently across layers
Guard models, PII masking, audit logs, and risk grading are not bound to one layer — they apply consistently across the whole request path.
FAQ
Frequently asked questions
What layers make up XGEN's guardrails?
Three axes: harm review by an external guard model, regex-based PII detection and masking, and blocklist detection and masking. On top of those sits a governance layer — pre-send detection (detect-only), a unified audit log, and the AI risk-grading policy.
When is PII masking applied?
Before a workflow agent calls the LLM, before a document is uploaded and embedded, and again on text extracted by OCR. Detection runs on regex policies, and actual masking happens when the global feature toggle is on.
What happens if the guard model fails?
A fail-open option lets you choose the operating policy. In a security-first environment you turn it off, so requests are still blocked when the guard model is down.
Can control events be used for audit?
Events detected or blocked by PII, blocklist, or guard-model policies are written to a unified policy event log and can be filtered by source, policy type, user, workflow, collection, and period. Policy creation, edits, and deletions are also kept as change history with versions.
Trusted Enterprise AI
Run AI on controls you can verify
Designed for finance and public-sector environments where data sovereignty and regulatory compliance are the starting point — the same control policies apply on-premise. Get in touch whenever you want to review adoption or work through security requirements.