What TutorGuard is for

What TutorGuard does

I built TutorGuard to sit between an AI tutor and the student view. When the tutor generates a reply, TutorGuard receives the text, runs a set of checks, and returns a verdict. The verdict tells you whether the reply is safe to show, needs editing, or should be blocked. The tool does not change the reply itself; it only gives you information to act on.

The core loop is simple: input text → safety scan → output decision. You can run the scan in demo mode with a built‑in mock model, which lets you see the flow without any external API key. For production you point TutorGuard at your own LLM endpoint and provide a valid key. The scan runs synchronously, so you get a response before you decide to publish.

Each scan produces a short report that includes:

- a safety score (0‑100) - flags for any detected issue categories - a suggested action (allow, edit, block) - the original text with highlighted spans

You can view the report in the dashboard or retrieve it via a JSON endpoint. The JSON includes the raw scores, the flag list, and the highlighted text so you can integrate the result into your own review workflow.

How the review works

I designed the review pipeline around three stages: preprocessing, model‑based detection, and rule‑based post‑processing. Each stage adds a layer of scrutiny without slowing down the overall latency.

Preprocessing

First the incoming reply is normalized. I strip extra whitespace, convert Unicode to a consistent form, and split the text into sentences. This step makes later pattern matching more reliable and reduces false positives caused by formatting quirks.

Model‑based detection

Next I run a lightweight classification model that has been fine‑tuned on public datasets of unsafe LLM output. The model returns probabilities for categories such as harassment, hate, self‑harm, and factual inconsistency. I chose a model that runs in under 200 ms on a modest CPU so the decision‑support loop stays interactive.

The model is hosted inside the TutorGuard container; you do not need to call an external service for the core scan. If you prefer to use your own model you can replace the binary via a configuration flag, but the default model is shipped with the product.

Rule‑based post‑processing

After the model scores are in, I apply a set of deterministic rules. These rules cover items that are hard for a statistical model to catch, such as:

- presence of personal data patterns (email, phone numbers) - specific prohibited phrases from your institution’s policy - numerical claims that exceed a configured threshold (e.g., “score above 95%” when the max is 100) - length limits that you set for tutor replies

The final safety score is a weighted sum of the model probability and the rule penalties. I set the weights after running a few hundred manual reviews on real tutor chats; the goal was to keep false‑negative rates low while avoiding an overload of flags.

Configuration and demo mode

TutorGuard ships with two runtime modes that you select at start‑up.

Demo mode

In demo mode the product uses a built‑in echo service that returns a preset response for any input. No external API key is required, and no data leaves your machine. This mode is useful for:

- testing the UI flow - showing a colleague how the verdict looks - running automated tests in CI without network calls

Because the echo service does not invoke a real LLM, the safety scores are static. I treat demo output as illustrative only; you must switch to live mode before evaluating actual tutor behavior.

Live mode

Live mode requires you to set three environment variables:

- LLM_ENDPOINT – the URL of your tutor’s generation service - LLM_KEY – the API key or token that the service expects - LLM_MODEL – the model identifier you want to guard

When these are present, TutorGuard forwards the user prompt to your endpoint, waits for the reply, then runs the safety scan on that reply. All communication happens over HTTPS; I do not log the raw prompt or reply unless you enable the optional audit flag, which writes encrypted blobs to a local .data/ directory.

You can adjust the safety thresholds via a simple JSON file:

{ "model_threshold": 0.78, "rule_penalty": 12, "max_length": 250, "block_on_personal_data": true } Changing these values changes the final score and the suggested action without needing to rebuild the container.

Safety categories we check

I mapped the checks to the OWASP Top 10 for Large Language Model Applications so you can see how TutorGuard aligns with a widely referenced framework. You can read the full list here.

Category 1 – Prompt injection

I look for patterns that try to override the tutor’s system instructions, such as repeated “ignore previous” strings or encoded commands in base64. If detected, the rule adds a high penalty and the suggested action becomes “block”.

Category 2 – Insecure output handling

The scanner checks whether the reply contains executable snippets (e.g., <script> tags, SQL fragments, or shell metacharacters) that could be dangerous if rendered verbatim. Flags here trigger an “edit” suggestion with the problematic spans highlighted.

Category 3 – Training data poisoning

While I cannot detect poisoned data directly, I monitor for sudden shifts in factual consistency. The model‑based detector flags statements that contradict known knowledge bases (e.g., false historical dates). This helps catch outputs that may stem from corrupted training.

Category 4 – Model denial of service

Large replies can consume excessive bandwidth or cause client‑side rendering issues. I enforce a configurable length cap; replies that exceed it receive a length‑violation flag and a “trim” suggestion.

Category 5 – Supply chain vulnerabilities

TutorGuard itself does not pull external libraries at runtime, reducing supply‑chain risk. I note this in the documentation so you know the scanner’s attack surface is limited to the binary and its configuration files.

Category 6 – Sensitive information disclosure

Regular expressions for email addresses, phone numbers, and ID numbers run in the rule‑based stage. Any match raises a high‑severity flag and forces a “block” verdict unless you whitelist the pattern.

Category 7 – Insecure plugin design

If your tutor uses plugins, I recommend scanning plugin‑generated text separately. TutorGuard can be pointed at any text source, so you can run the same checks on plugin outputs.

Category 8 – Excessive agency

I watch for language that implies the tutor is taking autonomous actions (e.g., “I will now send an email”). Such phrasing gets a moderate flag and a suggestion to reword.

Category 9 – Overreliance

The product explicitly states it is decision‑support only. I include a reminder in the report that a human should review flagged content before final release.

Category 10 – Model theft

While TutorGuard does not prevent model extraction, it logs each scan request. An unexpected spike in scan volume can be a signal worth investigating.

What this is NOT

I want to be clear about the limits of TutorGuard so you do not rely on it for something it cannot do.

First, TutorGuard is not a guarantee that every unsafe reply will be caught. The model‑based detector works on probabilities; there is a chance a subtle issue slips through. That is why the output is labeled decision‑support and why you must review flagged content.

Second, it does not achieve 100 % accuracy on any metric. I avoid claiming perfect precision or recall because the underlying models have inherent error rates. The safety score is a guide, not a certainty.

Third, TutorGuard is not a replacement for your own content policy or human moderators. It adds an automated layer, but final responsibility stays with you.

Fourth, the product does not include SSO, Slack notifications, or bulk CSV export unless those features have been shipped in this specific build. I have deliberately omitted any mention of those capabilities in the documentation to avoid confusion.

Fifth, TutorGuard does not modify the AI tutor’s reply. It only returns a verdict and highlighted spans. If you need automatic rewriting you must build that step yourself.

Sixth, the demo mode does not reflect live performance. The static scores in demo mode are for illustration only; you must switch to live mode to see real‑world behavior.

References

- https://owasp.org/www-project-top-10-for-large-language-model-applications - https://www.nist.gov/itl/ai-risk-management-framework

Frequently asked questions

What is TutorGuard?

Keep every AI tutor reply safe before students see it.

Who should use TutorGuard?

Operators and builders who need a fast first draft or checklist from TutorGuard.

Does it work without an API key?

Yes in explicit Demo mode. Live AI requires a configured key.

Does it guarantee outcomes?

No. Outputs are decision-support; you still review before publishing or acting.

Does it include SSO, Slack, or bulk CSV?

Only if those features are implemented in this product build — do not assume them from marketing copy.

Where does data go?

Runs may be stored locally under the product's .data/ boundary; treat demos as ephemeral.

References

- schema.org — FAQPage - Google Search Central — Structured data

Try TutorGuard

Related reads

- How to use TutorGuard — TutorGuard - The LX AI Micro-SaaS Topic Matrix