Konsep · Guardrails Pipeline

Defense-in-depth pada setiap request.

6 guardrail berjalan dalam urutan tetap sebelum dan sesudah panggilan upstream. Fail-fast saat diblokir. Hasil pass-through pada setiap response yang berhasil.

Pipeline

Alur request

┌────────────────────────────────────────────────────────────────┐
│  Request arrives at /v1/chat/completions                       │
└────────────────────────────────────────────────────────────────┘
              │
              ▼
   1. Auth + rate limit       ← 401/402/403/429 fail fast (~1 ms)
              │
              ▼
   2. PRE-CALL GUARDRAILS     ← fail-fast on any block (~30-80 ms)
       ┌────────────────────┐
       │ a. Injection        │  ML-based classifier
       │ b. PII              │  PII detection engine
       │ c. Content          │  Keyword + classifier
       │ d. Policy (tools)   │  policy-engine allow/deny lists
       └────────────────────┘
              │
              ▼ (if all pass)
   3. Cache check             ← semantic cache hit returns 200 (~5 ms)
              │
              ▼ (miss)
   4. Routing decision        ← realtime or batch?
              │
              ▼
   5. Upstream LLM call       ← provider latency (~500ms-5s typical)
              │
              ▼
   6. POST-CALL GUARDRAILS    ← (~20-40 ms)
       ┌────────────────────┐
       │ e. Response content │  Filter unsafe completions
       │ f. Response PII     │  Mask leaked PII in output
       └────────────────────┘
              │
              ▼
   7. Token metering + trace  ← event stream + analytics store
              │
              ▼
        Response to client

Setiap request melewati pipeline dalam urutan tetap ini. Tidak ada cara untuk melewatinya; master toggle untuk mem-bypass guardrails (jarang dipakai, tercatat di audit) adalah pengaturan per-policy-group yang harus diaktifkan secara eksplisit oleh admin.

Guardrail pre-call

Apa yang dilakukan masing-masing

a. Prompt injection

Classifier injeksi-prompt berbasis ML menilai setiap pesan ber-role user. Score > 0.85 (dapat dikonfigurasi) mengembalikan 403. Menangkap prompt jailbreak, ekstraksi system prompt, dan pembajakan tool-call. Berjalan ~40 ms di CPU.

b. Deteksi PII

Mesin deteksi PII kami mengenali 9 tipe entitas (email, phone, credit card, SG NRIC, ID NIK, IP, URL, person, address). Perilakunya bergantung pada mode PII policy group: redact (ganti dengan <EMAIL> placeholder), tokenize (ganti dengan token yang reversibel dan pulihkan di response), synthetic (ganti dengan nilai palsu yang realistis), atau block (kembalikan 403).

c. Moderasi konten

Denylist keyword (dapat dikonfigurasi admin) plus classifier multibahasa yang mencakup EN + Bahasa Indonesia. Sensitivitas per-kategori (sexual, hate, self-harm, dll.). Mengembalikan 403 saat terpicu.

d. Penegakan policy / tool

Saat request menyertakan tools, setiap nama tool dicek terhadap policy group milik API key (allow/deny list). MCP tool RBAC juga berlaku di sini untuk MCP server yang terhubung.

Guardrail post-call

Setelah upstream mengembalikan hasil

e. Filter konten response — classifier yang sama dengan pre-call tetapi diterapkan pada output model. Menangkap completion tidak aman yang tak sengaja dihasilkan model meski prompt-nya aman.
f. Pemindai PII response — me-masking PII apa pun di response. Berguna saat upstream mungkin memantulkan kembali sesuatu yang sensitif meski prompt-nya bersih.

Jika guardrail post-call memblokir, response diganti dengan 403 — pelanggan tetap membayar token (upstream sudah berjalan) tetapi tidak melihat konten yang tidak aman.

Membaca hasil

Pass vs block pada respons aktual

Pada response 200, hasil setiap guardrail ditampilkan di _anoman.guardrails dan sebagai header berawalan x-anoman-guardrail-*. Berguna untuk mencatat tingkat false-positive tanpa menyimpulkannya dari block.

{
  "choices": [...],
  "_anoman": {
    "guardrails": {
      "injection":        { "status": "pass", "score": 0.02 },
      "pii":              { "status": "pass" },
      "content":          { "status": "pass" },
      "policy":           { "status": "pass" },
      "response_content": { "status": "pass" }
    }
  }
}

Saat block, response berupa 403 dengan type: "guardrail_error" dan sebuah code spesifik yang menandai guardrail mana yang terpicu:

// Response body
{
  "error": {
    "type": "guardrail_error",
    "code": "prompt_injection",
    "message": "Request blocked by prompt injection detector (score 0.94 > threshold 0.85)."
  }
}

// Headers
x-anoman-guardrail-injection: blocked score=0.94

Anggaran latensi

Berapa biayanya dalam waktu?

Pre-call guardrails (target p95):
  Injection (ML model)       ~40 ms
  PII (detection engine)     ~25 ms
  Content (keyword + ML)     ~5 ms
  Policy (allow/deny)        ~10 ms
                            ────────
  Total pre-call             <100 ms

Post-call guardrails (target p95):
  Response content           ~15 ms
  Response PII               ~20 ms
                            ────────
  Total post-call            <40 ms

Anoman total overhead:       <150 ms p95
  (vs typical LLM call latency of 500ms – 5s — negligible)

Pipeline pre-call berjalan sekuensial dengan fail-fast — saat injection memblokir, kami tidak repot menjalankan PII / content / policy. Pada pass biasa, pipeline penuh menambahkan <100 ms sebelum panggilan upstream dimulai.

Konfigurasi

Override per-key + per-policy-group

Setiap API key ditetapkan ke sebuah policy group dengan: mode PII, threshold injection, tingkat moderasi konten, allow/deny list tool, dan master enable toggle. Override per-key dapat menonaktifkan guardrail tertentu (tercatat di audit) — berguna untuk layanan internal tepercaya yang tidak ingin redaksi PII mengubah prompt.

Lihat halaman pengaturan Guardrails di dashboard, atau referensi /docs/guardrails untuk seluruh permukaan konfigurasi.

Lihat setiap guardrail aktif secara live.

Live Feed menampilkan hasil pre/post-call pada setiap request saat terjadi.

Buka Live Feed Semua konsep