Security

Why AI features need guards

Every AI feature in OnPagePilot takes text you wrote (a brief, a persona, a sample paragraph, a keyword) and turns it into instructions for a model. Text that carries hidden instructions, invisible characters, or a request to ignore the rules can make a model do something the product never intended. That risk is not theoretical; it is the standard way AI products are attacked.

OnPagePilot treats it as an engineering problem, not a policy note: the input, the logic, the inference and the output each pass through their own guards before anything reaches you or the model.

The guardrail pipeline: four stages

Input Fortress screens what comes in: injections, hidden laundering and rate-limit anomalies are stopped at the door.

Logic Core runs the request in an isolated sandbox and validates the persona it is asked to use.

Inference Guard watches the model while it works: an anomaly engine and behavioral drift detection.

Output Filter checks what goes out: business contracts are enforced, PII leaks are blocked, and every result stays traceable.

Twenty-two layers of defense

Across the four stages the pipeline stacks twenty-two layers, among them sanitization and validation of every input, invisible threat detection (white-on-white text, zero-width characters), traffic governance with rate limiting and quotas, data integrity checks, architecture hardening and persona integrity. No single layer is trusted to catch everything; the stack is designed so that one miss is caught by the next.

What a guard sees in practice

The guards look for the patterns attackers actually use: instructions that try to override the system, attempts to make the model leak its prompt, known jailbreak aliases, HTML injection, fake system tags, delimiter manipulation, role confusion, words assembled from mixed Unicode scripts, excessive repetition meant to exhaust structure, and dangerous token sequences.

Ordinary text passes. A benign brief or a paraphrase of one is accepted as written; only the malicious shape is rejected, and every rejection is recorded with a reference id so it can be traced.

We red-team our own guards

A guard that is never attacked is a guess. We run a red-team suite of known-bad payloads against our own guards on every release, the same way an external red team would: each payload has a documented expected verdict, and the run reports every case where the guard answered differently. Any deviation from the documented verdict is treated as a finding to investigate, not as noise.

The suite covers the attack families above, plus benign and paraphrased controls that must be accepted, so the guards are tested for false rejections as well as for misses.

Every verdict is measured

Guard behaviour is metered in production, not assumed. An operator dashboard shows guard runs, rejections, flags and the rejection rate, the risk mix of what was seen, which validator fired (RegexInjection, LengthAndStructure, TokenAnalysis, LeakPattern) and guard latency per pipeline. The guards answer in under a millisecond at the 95th percentile, so safety adds no waiting time to your work.

Because the red-team run passes through the same guards, it is visible as a spike on the same dashboard operators watch every day. If the guards ever fail silently, the numbers say so.

What this means for your work

Your briefs, personas and content are validated before a model sees them and before the result is shown to you. If a persona or a sample paragraph is rejected, the wording matched one of the patterns above; rephrase it and try again. If you believe a rejection is wrong, the reference id lets us find the exact case.

Where to go next

The Security page presents the four stages and the twenty-two layers in full. The Security FAQ answers the questions we get most often about how your data and your content are handled.

If you have a security question that is not answered there, or you found something we should know about, tell us on the contact page.