1–2 days → ~5 min
Transfer-document review that took 1–2 working days (P95) now completes in about 5 minutes, with 12 deterministic and agent checks and human approval for uncertain cases.
Source: Bank (POC), name under NDA
LLM guardrails with PII redaction and human-in-the-loop approval
DocsGPT guardrails check user input, retrieved sources, tool results and the final answer against seven built-in checks, including PII, secrets and prompt injection, and flag, redact or block. Human approval gates can hold any answer or tool call for one-click review, all logged.
Last updated:
Guardrail intervention pointsfig. 1
Text version
A request passes four intervention points in order. (1) The user input is checked before retrieval. (2) The retrieved sources are checked before the model reads them. (3) Tool results are checked before the model uses them. (4) The final answer is checked before the user sees it. At every point a check can take one of three actions: flag the event, redact the matched content, or block the request.
Four intervention points
One request, four places a policy can act.
A guardrail runs at four points in every request: on the user input before retrieval, on the retrieved sources before they reach the model, on tool results before the model uses them, and on the final answer before it reaches the user.
At each point a check takes one of three actions: flag records the event and lets the request continue, redact removes the matched content and continues, block stops the request. Redaction needs a check that reports the character range it matched, so it is available on four of the seven; the rest flag or block. Checks are configured per agent, so a public support agent and an internal legal agent can run different policies.
Point 4 works on a stream. A token cannot be recalled once it is sent, so the output guard withholds a window of the most recent characters, sized from the longest match any enabled check can report. It scans the held text together with the new text and releases only the prefix that is safe. So a streamed answer is checked before it reaches the user too; only the grounding check waits for the finished answer.
input → sources → tool results → answer
| Inspected content | Runs before | Actions | |
|---|---|---|---|
| 1 · User input | The question or instruction as typed | Retrieval starts | flag · redact · block |
| 2 · Retrieved sources | Chunks returned by the retriever | The model reads them | flag · redact · block |
| 3 · Tool results | Output of tool calls (web, API, MCP, remote device) | The model uses them | flag · redact · block |
| 4 · Final answer | The model's response | The user sees it | flag · redact · block |
Seven built-in checks
Seven checks ship in the box: personal information, credentials and secrets, banned terms, link policy, prompt injection, grounding in sources and LLM-judge custom policies. The first four run at all four intervention points; prompt injection runs everywhere except the final answer, and grounding runs only there.
| Looks for | Actions | Notes | |
|---|---|---|---|
| Personal information | Emails, phone numbers, national IDs, card numbers, IPs and IBANs, by pattern; it does not find names | flag · redact · block | All four points · default entities: email, phone, US SSN, card number |
| Credentials and secrets | API keys, access tokens and private keys, by known format | flag · redact · block | All four points |
| Banned terms | A term list you define, whole-word by default | flag · redact · block | All four points |
| Link policy | URLs whose host is outside your allowed list, or on your blocked list | flag · redact · block | All four points |
| Prompt injection (heuristic) | Instruction-override phrasings in user input, retrieved sources and tool results | flag · block | Not the final answer · start in monitor-only to tune |
| Grounding in sources | Answers whose wording is not supported by the retrieved sources, measured by lexical overlap | flag · block | Final answer only · scored once the answer is complete |
| Custom policy (LLM judge) | A policy written in plain language, scored by a judge model | flag · block | All four points · a remote check by default, see below |
Modes per check: monitor-only trial, fail-open or fail-closed (v0.19).
Human-in-the-loop approval
Hold an answer or a tool call until a person says yes.
Approval gates apply to two things: a chat response before it is shown, and a tool execution before it runs. The reviewer sees the proposed content or command and approves or rejects it with one click; the decision, the reviewer and the time are logged.
An approval gate is not one of the four guardrail checkpoints. It pauses the agent loop before the call is made, on the proposed tool and its arguments; the tool-results check above runs afterwards, on what the call returned.
Inside a workflow, the same gate sits on a node, so a document classification that falls under a confidence threshold routes to a person instead of an action. Remote-device commands issued through the CLI daemon are gated by their own approval modes (Ask or Full access) and a denylist.
approve · reject · logged — responses and tool calls
zsh — docsgpt-cli chat, tool approval
Limits and audit
Ceilings on usage, and a record of every intervention.
Token and rate limits apply per user and per agent, and tool iteration limits cap how many times an agent may call tools in one turn. These stop runaway costs and loops independently of any guardrail.
Every guardrail decision is written to the guardrail events audit panel: which check fired, at which point, what action it took. Approval gates are not checks, so they are not in that panel. Each approve or reject is recorded against the run it paused, with the reviewer and the time. Sign-in, provisioning, role and forced-logout events go to the append-only auth_events table described on Admin, Security & Analytics; the full programme is on Security.
tokens · rate · tool iterations — per user, per agent
| Check | Intervention point | Action | |
|---|---|---|---|
| 09:14:02 | Personal information · email | final answer | redact |
| 09:12:47 | Prompt injection | retrieved sources | block |
| 09:11:30 | Banned terms | user input | flag |
| 09:08:15 | Link policy | final answer | block |
| 09:02:51 | Personal information · phone | user input | redact |
Every guardrail decision is logged and exportable.
How it runs privately
All checks run in the DocsGPT backend, next to retrieval and tool execution. Six of the seven are local pattern or heuristic checks and make no network call at all. The LLM-judge check is the exception: it is a remote check by default, so it sends the text it is scanning to whichever judge model you point it at. Point it at a local model and nothing leaves the network in an air-gapped deployment. On Cloud the same checks run inside Arc53's service; nothing else differs.
Operators who would rather remove the choice set GUARDRAILS_CHECKS_ENABLED, a deployment-level allowlist of check keys. It is enforced when a control is written, not only in the UI, so a check left off the list cannot be turned on through the settings screen or the API. That is how an air-gapped instance makes a remote check unreachable rather than merely discouraged. An empty allowlist means everything registered.
Guardrails and approval gates are part of the platform in every deployment posture, not a separate tier; see pricing. Running this in a bank? See banking and financial services.
Example
In this transfer-review deployment a fixed set of checks runs on every document, confident results proceed automatically, and anything below threshold stops for a person. Guardrails give the checks; approval gates give the stop.
Frequently asked questions
What are LLM guardrails?
- LLM guardrails are checks that inspect what goes into and comes out of a language model: user input, retrieved sources, tool results and the final answer. They flag, redact or block content that breaks a policy. In DocsGPT they run at four intervention points with seven built-in checks.
How does PII redaction work in an AI assistant?
- The PII check inspects text at the intervention points you enable. Set to redact, it replaces matched personal data before the content moves on, so a retrieved source reaches the model redacted and an answer reaches the user redacted. Run it in monitor-only mode first to see what it would catch.
Can I require approval before an AI acts?
- Yes. Approval gates hold a chat response or a tool call until a person approves or rejects it with one click, and remote-device commands have their own approval modes and a denylist. Every decision is logged.
How do you protect RAG from prompt injection?
- A prompt-injection heuristics check runs on the user input, on the retrieved sources and on tool results, so instructions hidden inside a document, or returned by a web, API or MCP call, are caught before the model acts on them. It matches instruction-override phrasings, which catches unobfuscated payloads rather than a determined attacker, so start it in monitor-only mode to tune it on your corpus, then switch it to block.
Is every intervention logged?
- Yes. Guardrail events appear in the guardrail events audit panel; an approval or rejection is recorded against the run it paused, with the reviewer and the time; sign-in, provisioning and role events go to the append-only auth_events table described on Admin, Security & Analytics.
See DocsGPT on your documents
A 30-minute demo of guardrails and approval gates on your documents, or a free on-premises review with an engineer.