Policies

Overview

Policies adalah aturan governance deklaratif yang dievaluasi terhadap setiap permintaan inference yang melalui Monago Gateway. Setiap policy ditulis dalam DSL JSON dengan field utama: name, when (kondisi), effect (allow / deny / log_only / redact / require_approval / require_hitl), dan priority. Policy engine merupakan komponen governance fondasi pada Monago.

Relevansi policy engine pada konteks regulator:

• Enforcement runtime — policy engine memblokir permintaan yang melanggar aturan sebelum mencapai upstream AI.
• Keputusan auditable — setiap policy decision menghasilkan entri audit chain, sehingga regulator dapat menelaah baik aturan governance maupun keputusan aktual.
• Template siap pakai — pola umum seperti perlindungan PII, model allowlist, token budget, time restriction, prompt injection scoring, dan premium model approval gate.
• Pencocokan multi-dimensi — kondisi dapat mereferensikan user.team, user.role, request.model, estimated tokens, data classification, dan field lainnya.

Audiens halaman ini: administrator tenant atau workspace_admin yang menetapkan dan memelihara aturan governance.

Concepts

Anatomi policy

Contoh policy yang memblokir penggunaan LLM external untuk data finance klasifikasi confidential:

{
  "name": "Finance Team External LLM Restriction",
  "description": "Block external LLM untuk data finance klasifikasi confidential/restricted.",
  "when": {
    "operator": "and",
    "conditions": [
      {"field": "user.team", "operator": "in", "value": ["finance", "treasury"]},
      {"field": "request.model_provider", "operator": "equals", "value": "external"},
      {"field": "context.data_classification", "operator": "in", "value": ["confidential", "restricted"]}
    ]
  },
  "effect": {
    "type": "deny",
    "deny_reason_code": "FINANCE_EXTERNAL_LLM_CONFIDENTIAL",
    "deny_user_message": "Data finance klasifikasi confidential/restricted tidak boleh diproses via external LLM."
  },
  "priority": 90,
  "framework_mapping": [
    {"framework": "ISO_42001", "clause": "A.7.4"}
  ]
}

Saat permintaan datang dari pengguna pada team finance dengan data classification confidential ke external provider, policy engine mengembalikan deny dengan reason code dan user-facing message. Audit log mencatat keputusan dengan policy version dan matched conditions.

Setup

Prasyarat

• Peran admin di tenant (atau workspace_admin untuk policy workspace-bound).
• Use case governance yang jelas (penggunaan model, restriction per tim, cost cap, dan sebagainya).
• Familiar dengan struktur DSL JSON, atau gunakan template.

Membuat policy dari template (direkomendasikan)

Versi pertama otomatis aktif setelah pembuatan.

Membuat policy custom (tanpa template)

Kondisi (when)

Fields: user.id, user.email, user.role, user.team, request.model, request.model_provider, request.estimated_tokens, request.action, context.data_classification, context.workspace_id, context.tenant_id.

Operators: equals, not_equals, in, not_in, contains, greater_than, less_than, regex_match.

Combinators: and, or. Nested group didukung untuk ekspresi kompleks.

Effects

Usage

Daftar policies

Halaman Kebijakan menampilkan seluruh policy rule pada scope tenant dan workspace. Empty state dengan quickstart muncul saat tenant belum memiliki policy.

Detail policy dan log keputusan

Klik row untuk membuka detail page (/policies/{id}):

• Metadata: nama, slug, deskripsi, framework mapping, priority.
• JSON viewer untuk active version.
• Tabel keputusan terbaru (20 entri): action, status, matched conditions, pengguna, model, timestamp.
• Tombol Buat versi baru dan Cabut (admin).

Membuat versi baru (menyunting policy)

Policy bersifat versioned — perubahan menghasilkan versi baru.

Priority dan resolusi konflik

Saat beberapa policy match pada satu permintaan:

Rekomendasi pembagian priority:

• 0-30: log_only atau policy observasional.
• 40-60: governance standar.
• 70-90: governance ketat.
• 91-100: emergency override.

Integrasi NER untuk redaction

Policy dengan effect redact dapat secara opsional memanggil NER kontekstual untuk entitas yang tidak cocok dengan pola regional. Konfigurasi terdapat pada effect.redact_config.

Compliance mapping

Detail mapping per-clause dan evidence package disampaikan dalam dokumen procurement terpisah — hubungi support@monago.io.

Troubleshooting

"Format DSL kebijakan tidak valid"

Backend menolak payload dengan pesan error rinci. Penyebab umum: field kondisi tidak ada atau strukturnya tidak tepat, typo pada operator, atau effect type di luar enum yang diizinkan. Solusi: salin dari template terdekat dan sunting seperlunya.

Policy match tetapi permintaan gateway berhasil

Periksa status policy — bila dinonaktifkan atau diarsipkan, engine melewatinya. Aktifkan kembali melalui UI atau buat versi baru.

Beberapa policy match, policy yang salah yang menang

Resolusi priority: tertinggi menang. Periksa priority seluruh match candidate pada detail page. Atur ulang dengan membuat versi baru yang menyesuaikan priority.

"Policy not found" saat memperbarui versi

Policy kemungkinan telah diarsipkan oleh administrator lain. Refresh list page.

Redaction tidak terjadi meski policy redact

• Verifikasi effect bernilai redact (bukan log_only).
• Verifikasi effect.redact_config aktif.
• Bila lapisan NER kontekstual tidak tersedia, deteksi tetap berjalan dengan lapisan pola regional; audit log mencatat lapisan mana yang aktif untuk setiap permintaan.

FAQ

Apakah policy decision real-time atau async?

Real-time. Setiap permintaan inference dievaluasi secara synchronous sebelum diteruskan ke penyedia. Overhead latensi minimal karena hasil resolusi disimpan dalam cache per tenant.

Bisakah policy menggunakan custom field di luar built-in?

Pilot scope hanya mendukung field built-in (lihat daftar pada Setup). Custom field melalui ekstensi merupakan bagian dari roadmap pengembangan.

Apakah ada batas jumlah policy per tenant?

Tidak ada hard limit pada pilot. Rekomendasi: pertahankan jumlah yang manageable (10 hingga 30 per tenant) untuk memudahkan audit dan decision tracing.

Bagaimana cara menguji policy sebelum deploy ke production?

Gunakan pemisahan workspace: deploy ke workspace staging terlebih dahulu, uji dengan workload sampel, kemudian replikasi ke workspace production. Evaluasi policy terhadap sample request tanpa enforcement (mode dry-run) merupakan bagian dari roadmap pengembangan.

Apa yang terjadi bila saya menghapus policy yang aktif?

Soft archive (status menjadi archived). Audit chain dan history keputusan tetap dipertahankan.

Bisakah workspace_admin membuat policy?

Ya — terbatas pada workspace yang mereka kelola (workspace-bound). Policy tenant-wide hanya dapat dibuat oleh administrator tenant.

Apa perbedaan log_only dengan allow?

allow merupakan permit eksplisit tanpa pengayaan audit. log_only merupakan permit dengan tagging audit log menggunakan metadata policy match untuk keperluan compliance reporting.

Related

• BYOK — kredensial penyedia (target matching model_provider).
• Workspaces — scope workspace untuk isolasi policy.
• Risk — policy decision menjadi sumber risk signal.
• Compliance — agregasi framework mapping.