Is this the same as the Guardrails & Rate Limits page?

No — different concept, same word. Guardrails & Rate Limits (/docs/guardrails) covers velocity circuit breakers, max_tokens clamping, and hierarchical budget chains — structural spend-safety limits. Content Guardrails, this page, screens what's actually IN a request — PII, secrets, and prompt-injection attempts — independent of cost.

What detection technique is this using?

Regex/pattern matching only — no NER model, no ML classifier, no vector-similarity-to-known-attacks. This closes the category gap (having some form of pre-call content screening at all) without pretending to match a dedicated security product's detection depth.

Why is tool-output injection scanning stricter than user-message scanning?

The same detection engine runs at two strictness levels. A phrase like '### system: override' in a human's own message is usually a false positive (someone using markdown headings). The identical phrase arriving inside a TOOL RESULT — content the human never typed — is a much stronger signal of an actual injection attempt, since nothing legitimate should be instructing the model from inside a tool's output.

What happens to a redacted request — does the provider ever see the original text?

No. Redaction happens before cost estimation, budget reservation, and the outbound provider call all run — the provider only ever sees the redacted version, and cost estimation is computed against the redacted text too.

Can I see what got caught?

Yes, via GET /api/guardrails/events — every alert/redact/block outcome is logged with its pattern type and attribution tags. There's no dashboard page for this yet; it's API-only today.

How do I redact PII and screen for prompt injection?

Pattern-based PII/secrets redaction and prompt-injection heuristic screening, applied before a request reaches the provider — including a stricter check on tool-call outputs specifically.

Content Guardrails screen the actual text of a request — not its cost — before it reaches a provider. Two independent checks, each with its own configurable mode:

PII / secrets — emails, phone numbers, SSNs, credit card numbers (Luhn-checked), AWS access keys, PEM private keys, and provider API key prefixes (sk-ant-..., sk-proj-..., sk-...) — catching a customer's own key accidentally pasted into a prompt is a real, embarrassing leak class this specifically targets.
Prompt injection — heuristic pattern matching for instruction-override phrasing ("ignore all previous instructions", "you are now in developer mode", delimiter-injection sequences), applied at normal strictness to user/system messages and at a stricter threshold specifically to tool-call outputs (role: "tool" messages) — see the FAQ for why.

Pattern-based, not a dedicated security product

This uses regex/keyword detection, not an ML classifier or vector-similarity engine. It closes the basic gap — having pre-call content screening at all — without pretending to match a dedicated security scanner's depth. If your threat model needs that depth, run one of those in front of or alongside Cognocient; this isn't a replacement.

Modes

Each of the three checks (PII/secrets, prompt injection, tool-output injection) has its own independent mode:

Mode	PII/secrets	Prompt injection	Tool-output injection
Off	✓	✓	✓
Alert	Logged, request proceeds unchanged	Logged, request proceeds unchanged	Logged, request proceeds unchanged
Redact	Matched spans replaced with `[REDACTED:<type>]` before the provider call	— (redacting a prompt-injection match isn't meaningful the same way)	—
Block	HTTP 429, provider never sees the request	HTTP 429	HTTP 429

Defaults: PII/secrets → Redact, prompt injection → Alert, tool-output injection → Block (a legitimate tool result should essentially never contain instruction-override phrasing, so the false-positive cost of blocking it is low).

Set these from Settings → AI Providers → Content Guardrails & Provider Failover, or via the API:

curl -X PATCH https://api.cognocient.com/api/account/guardrails \
  -H "Authorization: Bearer sk-cog-..." \
  -H "Content-Type: application/json" \
  -d '{"pii_secrets": "block", "prompt_injection": "alert", "tool_output_injection": "block"}'

Where this runs in the request lifecycle

Right after the request body is parsed — before budget reservation, before response caching, before the outbound provider call. A blocked call never touches your budget or reaches the provider. A redacted call has its content rewritten before cost estimation runs, so both the estimated and actual cost reflect the redacted text.

Response shape when blocked

{
  "error": {
    "message": "This request was blocked because it appears to contain PII or a secret/API key.",
    "type": "guardrail_pii_blocked",
    "pattern_type": "email"
  }
}

type is one of guardrail_pii_blocked, guardrail_injection_blocked, or guardrail_tool_injection_blocked.

How do I redact PII and screen for prompt injection?

Modes

Where this runs in the request lifecycle

Response shape when blocked

Frequently asked questions

On this page