# documentation > AI Governance Operating System — documentation untuk integrasi, BYOK, policies, risk, dan compliance. This document contains the full content of all documentation pages for AI consumption. --- ## Dokumentasi API **URL:** https://docs.monago.io/docs/api **Description:** AI Governance Gateway untuk akses LLM enterprise. Drop-in, kompatibel OpenAI, dengan proteksi PII, enforcement yang dapat dikonfigurasi, visibilitas biaya, dan jejak audit bertanda tangan di setiap permintaan. # Monago Atrium — Dokumentasi API > AI Governance Gateway untuk akses LLM enterprise. Drop-in, kompatibel OpenAI, dengan proteksi PII, enforcement yang dapat dikonfigurasi, visibilitas biaya, dan jejak audit bertanda tangan di setiap permintaan. --- ## Ringkasan Monago Atrium berada di antara aplikasi Anda dan penyedia large language model (LLM) — OpenAI, Anthropic, dan lainnya — sebagai **Policy Enforcement Point**. Setiap permintaan melewati gateway sebelum mencapai penyedia, dan setiap respons kembali melaluinya. Pada titik pemeriksaan ini, Atrium menerapkan governance: mendeteksi dan meredaksi data pribadi (PII), menegakkan kebijakan per-tenant, memindai prompt injection, menghitung biaya, dan menulis catatan audit yang anti-manipulasi. Atrium dirancang mengikuti **prinsip Zero Trust (selaras dengan NIST SP 800-207)** pada lapisan data-governance: tidak ada permintaan yang dipercaya secara implisit, setiap permintaan dievaluasi terhadap kebijakan, dan enforcement keamanan bersifat **top-down** — baseline keamanan yang ditetapkan di tingkat tenant tidak dapat dilemahkan oleh workspace atau pengguna di bawahnya. ### Yang Atrium berikan - **Deteksi PII berlapis** — identifier terstruktur (NIK, NPWP, telepon, rekening bank, email) ditambah named-entity recognition untuk PII tidak terstruktur seperti nama orang, organisasi, dan lokasi. - **Enforcement yang dapat dikonfigurasi** — tentukan bagaimana PII yang terdeteksi ditangani per kebijakan: allow, warn, partial mask, full redaction, atau block. - **Kebijakan top-down** — baseline keamanan tenant adalah *floor* (batas minimum); tim dapat memperketat tetapi tidak pernah melonggarkannya. - **Visibilitas biaya** — estimasi biaya per-permintaan dikembalikan di setiap panggilan dan diagregasi untuk pelaporan. - **Jejak audit** — setiap permintaan menghasilkan catatan audit bertanda tangan, diakses melalui audit ID tingkat-permintaan. - **Kompatibilitas drop-in** — endpoint chat mencerminkan OpenAI Chat Completions API, sehingga klien dan SDK yang sudah ada bekerja dengan perubahan minimal. ### Penyedia yang didukung Satu API Atrium bekerja lintas penyedia — lapisan governance bersifat provider-agnostic, dan routing diturunkan dari identifier model. | Penyedia | Status | |----------|--------| | OpenAI | Tersedia | | Anthropic | Tersedia | | AWS Bedrock | Dalam roadmap | | Google Vertex AI | Dalam roadmap | | Alibaba Cloud Model Studio (Qwen) | Dalam roadmap | Kode Anda tidak berubah per penyedia: gunakan bentuk request yang sama (kompatibel OpenAI) dan ganti field `model`. Penyedia dan model mana yang diizinkan diatur oleh allowlist model pada kebijakan Anda. ### Ditujukan untuk siapa - **Evaluator / reviewer keamanan & compliance** — mulai dari [Ringkasan](#ringkasan), [Header Governance](#header-governance), [Mode Enforcement PII](#mode-enforcement-pii), dan [Compliance](#compliance). - **Developer** — mulai dari [Autentikasi](#autentikasi) dan [Referensi API](#referensi-api). --- ## Memulai ### Base URL ``` https://api.monago.io ``` ### Autentikasi Semua permintaan diautentikasi dengan API key workspace yang dikirim sebagai Bearer token. ``` Authorization: Bearer sk-mng-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` API key diterbitkan dan dikelola di konsol Monago. Sebuah key dilingkupi (scoped) ke sebuah tenant (dan opsional sebuah workspace); kebijakan governance yang berlaku untuk sebuah permintaan diturunkan dari scope tersebut. Jaga kerahasiaan key dan rotasi jika bocor. ### Quickstart (cURL) ```bash curl -X POST https://api.monago.io/v1/chat/completions \ -H "Authorization: Bearer sk-mng-YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o-mini", "messages": [ { "role": "user", "content": "Ringkas kebijakan onboarding." } ] }' ``` ### Quickstart (Python SDK) ```bash pip install monago-atrium ``` ```python from monago_atrium import Monago client = Monago(api_key="sk-mng-YOUR_KEY") result = client.chat( model="gpt-4o-mini", messages=[{"role": "user", "content": "Ringkas kebijakan onboarding."}], ) print(result.content) print(result.audit_id) # referensi audit bertanda tangan print(result.pii_redacted) # tipe PII yang diredaksi sebelum dilihat penyedia print(result.cost_idr) # estimasi biaya untuk permintaan ini ``` --- ## Referensi API ### Membuat chat completion ``` POST /v1/chat/completions ``` Chat completion kompatibel OpenAI, diatur oleh kebijakan Anda. Mendukung respons standar maupun streaming. Coba langsung di bawah — tempel key `sk-mng-` Anda, ubah request, dan contoh kode (cURL / Python / TypeScript) ikut berubah saat Anda mengetik. Panel respons menampilkan header governance `X-Monago-*`. #### Request body | Field | Tipe | Wajib | Deskripsi | |-------|------|-------|-----------| | `model` | string | ya | Identifier model (mis. `gpt-4o-mini`). Harus diizinkan oleh allowlist model pada kebijakan Anda. | | `messages` | array | ya | Pesan percakapan. Setiap item memiliki `role` (`system` / `user` / `assistant`) dan `content` (string). 1–200 pesan. | | `stream` | boolean | tidak | Jika `true`, mengembalikan stream Server-Sent Events. Default `false`. | | `max_tokens` | integer | tidak | Token maksimum yang dihasilkan (1–200000). | | `temperature` | number | tidak | Sampling temperature (0.0–2.0). | ```json { "model": "gpt-4o-mini", "messages": [ { "role": "system", "content": "You are a helpful assistant." }, { "role": "user", "content": "Draft a one-line welcome message." } ], "max_tokens": 256, "temperature": 0.7, "stream": false } ``` #### Response body Bentuk respons mencerminkan format OpenAI Chat Completions. | Field | Tipe | Deskripsi | |-------|------|-----------| | `id` | string | Identifier completion. | | `object` | string | Selalu `chat.completion`. | | `created` | integer | Timestamp Unix. | | `model` | string | Model penyedia yang di-resolve. | | `choices` | array | Choice yang dihasilkan, masing-masing dengan `index`, `message` (`role`, `content`), dan `finish_reason`. | | `usage` | object | `prompt_tokens`, `completion_tokens`, `total_tokens`. | ```json { "id": "chatcmpl-...", "object": "chat.completion", "created": 1779896327, "model": "gpt-4o-mini-2024-07-18", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "Welcome aboard — glad to have you!" }, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 23, "completion_tokens": 11, "total_tokens": 34 } } ``` Hasil governance (deteksi PII, keputusan kebijakan, biaya, referensi audit) dikembalikan sebagai **response header** — lihat di bawah. --- ### Header Governance Setiap respons membawa metadata governance dalam header `X-Monago-*`. Header ini memungkinkan aplikasi Anda mengamati apa yang dilakukan gateway tanpa mem-parsing body. | Header | Selalu ada | Deskripsi | |--------|------------|-----------| | `X-Monago-Audit-Id` | ya | Referensi audit bertanda tangan untuk permintaan ini. Gunakan untuk mencari catatan audit lengkap. | | `X-Monago-Provider` | ya | Penyedia upstream yang melayani permintaan. | | `X-Monago-Latency-Ms` | ya | Latensi yang diukur gateway dalam milidetik. | | `X-Monago-Pii-Detected` | ya | `true` / `false` — apakah ada PII yang terdeteksi. | | `X-Monago-Pii-Redacted` | saat PII ditemukan | Daftar tipe PII (dipisah koma) yang diredaksi sebelum permintaan mencapai penyedia (mis. `nik,phone_id,PERSON`). | | `X-Monago-Policy-Decision` | ya | Hasil kebijakan, mis. `allowed`. | | `X-Monago-Decision-Source` | ya | Sumber keputusan (identifier policy engine). | | `X-Monago-Cost-Idr` | saat terhitung | Estimasi biaya permintaan dalam IDR. | | `X-Monago-Block-Reason` | saat diblok | Ada ketika sebuah permintaan diblokir oleh kebijakan. | > **Redaksi PII terjadi sebelum penyedia melihat permintaan.** Ketika `X-Monago-Pii-Redacted` mencantumkan sebuah tipe, data tersebut telah diganti dengan placeholder pada teks yang dikirim ke upstream — penyedia tidak pernah menerima nilai aslinya. --- ### Mode Enforcement PII Cara PII yang terdeteksi ditangani dikendalikan oleh aksi PII pada kebijakan Anda. Setiap mode adalah satu titik pada tangga tingkat ketat (strictness ladder); mode yang lebih ketat yang ditetapkan di tingkat tenant tidak dapat ditimpa menjadi mode yang lebih longgar oleh workspace. | Mode | Perilaku | Dikirim ke penyedia? | |------|----------|----------------------| | `allow` | Teruskan permintaan tanpa perubahan. | Asli | | `warn` | Teruskan, tetapi catat deteksi di audit log. | Asli | | `partial_mask` | Redaksi PII dengan menyisakan ekor pendek (gaya "nomor kartu" industri, mis. `****-****-****-0123`) agar pengguna dapat mengenali datanya sendiri. | Termasking (ekor disisakan) | | `full_mask` | Redaksi PII sepenuhnya tanpa sisa (mis. `[REDACTED_NIK]`). | Termasking (tanpa ekor) | | `block` | Tolak permintaan. **Tidak** diteruskan ke penyedia. | Tidak | Urutan ketat: `allow` < `warn` < `partial_mask` < `full_mask` < `block`. Ketika sebuah permintaan diblokir, API mengembalikan `403` dengan kode error `PII_BLOCKED` (lihat [Error](#error)). --- ### Streaming Setel `"stream": true` untuk menerima stream Server-Sent Events (SSE). Stream menyelang-nyeling **event governance** dengan **event content**, sehingga Anda dapat mengamati tahap policy, PII, routing, dan provider secara real time, diikuti output model. ```bash curl -N -X POST https://api.monago.io/v1/chat/completions \ -H "Authorization: Bearer sk-mng-YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o-mini", "stream": true, "messages": [{ "role": "user", "content": "Hello" }] }' ``` Tipe event: | Event | Payload | |-------|---------| | `governance` | Pembaruan tahap pipeline: `policy`, `pii`, `routing`, `provider`, `audit`. Mencakup status dan ringkasan metadata singkat. | | `content` | Potongan (chunk) chat completion gaya OpenAI dengan sebuah `delta`. | | `done` | Event final dengan `usage`, `audit_id`, dan `session_id`. | Contoh event governance: ``` event: governance data: {"step": "pii", "status": "flagged", "meta": "3 types · PERSON, nik, phone_id", "detail": {"types": ["PERSON", "nik", "phone_id"]}} ``` > Pada respons streaming, referensi audit selalu tersedia (di event governance `audit` dan event `done` final). Sebagian header non-streaming sengaja tidak diulang pada kanal SSE. --- ### Error Error dikembalikan dengan status HTTP yang sesuai dan `code` machine-readable yang stabil. | Code | HTTP | Arti | |------|------|------| | `PII_BLOCKED` | 403 | Permintaan diblokir karena PII terdeteksi dan kebijakan disetel ke `block`. | | `MODEL_NOT_ALLOWED` | 403 | Model yang diminta tidak ada dalam allowlist kebijakan Anda. | | `OUTSIDE_ALLOWED_HOURS` | 403 | Permintaan dilakukan di luar jam yang diizinkan kebijakan. | | `MAX_TOKENS_EXCEEDED` | 403 | `max_tokens` yang diminta melebihi batas kebijakan. | | `TRIAL_EXPIRED` | 403 | Masa trial tenant telah berakhir. | | `UNKNOWN_MODEL` | 400 | Identifier model tidak dikenali. | | `NO_ACTIVE_CREDENTIAL` | 400 | Tidak ada kredensial penyedia upstream aktif yang dikonfigurasi untuk scope ini. | | `PROVIDER_NOT_CONFIGURED` | 503 | Penyedia target tidak dikonfigurasi. | | `PROVIDER_RATE_LIMITED` | 429 | Penyedia upstream membatasi laju (rate-limit) permintaan. | | `PROVIDER_TIMEOUT` | 504 | Penyedia upstream timeout. | | `PROVIDER_UPSTREAM_ERROR` | 502 | Penyedia upstream mengembalikan error. | Semua respons error menyertakan header audit governance bila tersedia, sehingga permintaan yang diblokir atau gagal tetap dapat dilacak via `X-Monago-Audit-Id`. --- ## SDK Python SDK membungkus API dan memunculkan hasil governance sebagai field kelas-satu (first-class). ```bash pip install monago-atrium ``` ```python from monago_atrium import Monago client = Monago(api_key="sk-mng-YOUR_KEY") result = client.chat( model="gpt-4o-mini", messages=[{"role": "user", "content": "Help me write a customer reply."}], ) # Output model print(result.content) # Permukaan governance print(result.audit_id) # referensi audit bertanda tangan print(result.pii_detected) # bool print(result.pii_redacted) # daftar tipe PII yang diredaksi print(result.policy_decision) print(result.cost_idr) # estimasi biaya, jika tersedia ``` SDK bersifat open-core dan mengikuti kontrak governance dari API. Streaming dan SDK bahasa lain ada di roadmap. --- ## Compliance Atrium dibangun untuk mendukung kewajiban data-governance enterprise, khususnya bagi sektor teregulasi seperti perbankan dan jasa keuangan di Indonesia. - **Minimisasi data di perimeter.** PII dapat diredaksi atau diblokir di gateway, sehingga identifier sensitif tidak perlu meninggalkan batas kepercayaan (trust boundary) Anda menuju penyedia LLM pihak ketiga. Ini mendukung kewajiban di bawah Undang-Undang Pelindungan Data Pribadi (UU PDP) Indonesia. - **Enforcement top-down (selaras Zero Trust).** Kebijakan keamanan ditetapkan di tingkat tenant sebagai floor yang tidak dapat ditawar; tim dapat menerapkan kontrol yang lebih ketat tetapi tidak dapat melemahkan baseline. Ini mengikuti prinsip Zero Trust (NIST SP 800-207) tentang enforcement kebijakan yang eksplisit dan top-down pada enforcement point khusus. *(Atrium selaras dengan prinsip-prinsip ini; "Zero Trust Architecture" adalah framework, bukan sertifikasi.)* - **Auditabilitas.** Setiap permintaan menghasilkan catatan audit bertanda tangan dan anti-manipulasi yang dirujuk oleh `X-Monago-Audit-Id`, mendukung peninjauan setelah-fakta dan pelaporan regulasi. - **Transparansi biaya.** Estimasi biaya per-permintaan mendukung chargeback internal dan governance anggaran. Untuk opsi data-residency dan deployment on-premise, hubungi tim Monago. --- ## Catatan & Konvensi - Endpoint chat sengaja dibuat **kompatibel OpenAI**: pada kebanyakan kasus Anda dapat mengarahkan klien OpenAI yang sudah ada ke base URL Atrium dan menambahkan key `sk-mng-` Anda. - Perilaku governance (model mana yang diizinkan, bagaimana PII ditangani, jam yang diizinkan) ditentukan oleh **kebijakan yang terikat pada scope API key Anda**, dikonfigurasi di konsol Monago — bukan oleh parameter permintaan. - Semua timestamp adalah Unix epoch detik; semua estimasi moneter pada `X-Monago-Cost-Idr` dalam Rupiah dan merupakan **estimasi untuk pelaporan**, bukan jumlah yang ditagih penyedia. --- ## BYOK guide **URL:** https://docs.monago.io/docs/byok-guide **Description:** Panduan self-service untuk mengonfigurasi BYOK (Bring Your Own Key) penyedia AI di Monago. Panduan lengkap bagi administrator tenant yang mengelola kredensial penyedia AI di Monago Governance Gateway. ## 1. Overview Monago menerapkan model **BYOK** (Bring Your Own Key) — pelanggan membawa kunci API penyedia AI sendiri (OpenAI, Anthropic, AWS Bedrock). Monago beroperasi sebagai *governance gateway*: - Menerapkan kebijakan tata kelola pada level tenant, workspace, dan pengguna. - Mencatat audit trail integritas-terjamin untuk setiap permintaan. - Menyediakan observability, cost analytics, dan compliance posture. Konsumsi token ditagih langsung oleh penyedia AI kepada pelanggan; Monago menggunakan model berlangganan terpisah untuk lapisan governance dan audit. ## 2. Prasyarat - Akun Monago dengan peran **admin**. - Akses ke menu **Penyedia AI**. - Plaintext kunci API dari penyedia AI Anda (lihat bagian 3). - Password manager atau secret vault internal untuk menyimpan plaintext setelah dialog tampil-sekali. ## 3. Memperoleh kunci API dari penyedia ### 3.1 OpenAI ### 3.2 Anthropic ### 3.3 AWS Bedrock ## 4. Konfigurasi di Monago ### 4.1 Buka Penyedia AI ### 4.2 Tambah kredensial Monago memvalidasi kunci terhadap endpoint metadata penyedia dengan batas waktu singkat. Indikator *"Memvalidasi kunci…"* ditampilkan selama proses berlangsung. ### 4.3 Dialog tampil-sekali (penting) Setelah validasi berhasil, dialog tampil-sekali (show-once) terbuka. ## 5. Mengelola kredensial ### 5.1 Daftar kredensial Tab **Penyedia AI** menampilkan tabel kredensial dengan kolom: nama, penyedia, tampilan kunci (masked), status, tanggal dibuat, dan aksi. Filter chip di atas tabel memungkinkan penyaringan berdasarkan **penyedia** dan **status**. ### 5.2 Menonaktifkan sementara Untuk menghentikan penggunaan kredensial tanpa mencabutnya secara permanen. Saat kredensial dinonaktifkan, permintaan yang diterima gateway akan: - **Cloud**: menggunakan kunci default platform bila administrator deployment telah mengonfigurasinya. - **On-premise**: dikembalikan dengan error konfigurasi karena tidak ada fallback. Aktivasi ulang: aksi row → **Aktifkan**. ### 5.3 Rotasi kunci **Skenario yang membutuhkan rotasi**: - Compliance policy organisasi Anda (rotasi berkala). - Indikasi kemungkinan kunci kompromis. - Pencabutan kunci dari sisi penyedia. Kunci lama digantikan oleh kunci baru; gateway segera menggunakan kunci baru pada permintaan berikutnya. ### 5.4 Mencabut kredensial Aksi permanen — kredensial tercabut sementara audit trail tetap dipertahankan. Status berubah menjadi *Dicabut*. Kredensial yang tercabut tidak dapat diaktifkan kembali — apabila dibutuhkan, buat kredensial baru. ## 6. Troubleshooting ### "Kunci API tidak valid" Penyebab umum: - Whitespace pada saat copy-paste (spasi atau newline di awal atau akhir). - Kunci kadaluarsa atau telah dicabut di dashboard penyedia. - Status billing akun penyedia tidak aktif. - Scope kunci tidak memiliki permission untuk endpoint metadata. - Base URL tidak benar bila menggunakan custom endpoint. Pesan respons dari penyedia ditampilkan pada baris *"Detail penyedia:"* di bawah error utama untuk membantu diagnosis. ### "Nama kredensial sudah digunakan untuk penyedia ini" Setiap kombinasi tenant + penyedia membutuhkan nama unik. Gunakan suffix versioning, misalnya `production-openai-v2`. ### "Kredensial penyedia AI tidak ditemukan" - Kredensial mungkin telah dicabut oleh administrator lain di tenant Anda. - Refresh halaman untuk memuat state terbaru. ### Permintaan gateway gagal setelah kredensial dinonaktifkan Perilaku yang diharapkan. Saat kredensial dinonaktifkan, gateway akan menggunakan kunci default platform bila administrator deployment telah mengonfigurasinya. Bila fallback belum dikonfigurasi (umum pada deployment on-premise), gateway mengembalikan error konfigurasi. Solusi: aktifkan kembali kredensial melalui UI. ### Dialog tampil-sekali tidak muncul setelah submit Penyebab umum: - Operasi metadata-only (tanpa rotasi kunci) tidak menghasilkan plaintext baru. Tabel akan menampilkan kredensial dengan tampilan masked. - Network error — periksa DevTools console browser. ### Validation timeout Endpoint metadata penyedia kadang mengalami latency tinggi. Coba ulang permintaan; transient error umum terjadi. Bila masalah berlanjut, hubungi support penyedia. ## 7. FAQ ### 7.1 Bagaimana kunci API saya dienkripsi? Monago menerapkan enkripsi at-rest dengan mekanisme kriptografi standar industri. Plaintext hanya didekripsi selama durasi pemrosesan permintaan inference oleh gateway. Untuk deployment production, Monago mendukung *envelope encryption* dengan **Customer-Controlled Key Management Service** (KMS). Tim Monago tidak memiliki kewenangan operasional terhadap KMS pelanggan, sehingga akses ke material kunci membutuhkan otorisasi pelanggan. ### 7.2 Apakah tim Monago dapat melihat plaintext API key saya? Tidak. Plaintext dienkripsi at-rest dan didekripsi hanya selama durasi pemrosesan permintaan inference. Tidak ada product workflow yang menampilkan kembali plaintext setelah dialog tampil-sekali ditutup. ### 7.3 Apakah audit log mencatat plaintext API key? Tidak. Audit log mencatat metadata kredensial: penyedia, nama kredensial, empat karakter terakhir kunci, dan perubahan field-level. Larangan penulisan plaintext ke audit log ditegakkan oleh regression test otomatis yang berjalan di setiap rilis. ### 7.4 Plaintext hilang setelah dialog tampil-sekali ditutup. Bagaimana memulihkannya? Plaintext tidak dapat dipulihkan melalui Monago. Lakukan rotasi kredensial: ### 7.5 Bisakah beberapa administrator mengelola kredensial? Ya. Seluruh pengguna dengan peran admin pada tenant dapat melihat, membuat, melakukan rotasi, menonaktifkan, dan mencabut kredensial. Audit log mencatat pengguna yang melakukan setiap aksi. ### 7.6 Apakah ada batas jumlah kredensial per tenant? Tidak ada hard limit pada pilot. Rekomendasi: 1 hingga 3 kredensial per penyedia (misalnya `prod`, `staging`, `dev`). Apabila terdapat lebih dari satu kredensial aktif untuk satu penyedia, gateway menggunakan kredensial yang paling baru. ### 7.7 Apakah deployment on-premise dapat menggunakan BYOK? Ya. Flow UI identik. Perbedaan: - Peran super_admin tidak tersedia pada deployment on-premise — admin merupakan otoritas tertinggi. - Fallback default key bersifat opsional dan dikonfigurasi oleh administrator deployment. - KMS encryption dikelola oleh pelanggan. ### 7.8 Apa yang terjadi bila tenant saya dihapus? Penghapusan tenant juga melepaskan dan menghapus seluruh kredensial terkait. Audit log tetap dipertahankan untuk kebutuhan forensik. Konfirmasi melalui support sebelum melakukan operasi destructive. ## 8. Security best practices ## 9. Compliance mapping Detail mapping per-clause dan evidence package disampaikan dalam dokumen procurement terpisah — hubungi [support@monago.io](mailto:support@monago.io) untuk salinan PDF. ## 10. Support --- ## Selamat datang di Monago **URL:** https://docs.monago.io/docs **Description:** AI Governance Operating System — dokumentasi untuk integrasi, BYOK, kebijakan, risiko, dan compliance. Monago adalah **AI Governance Operating System** yang beroperasi sebagai *governance gateway* antara aplikasi pelanggan dan penyedia AI (OpenAI, Anthropic, AWS Bedrock). Setiap permintaan inference dievaluasi melalui lapisan governance, audit, dan compliance sebelum diteruskan ke penyedia. ## Apa yang Monago lakukan - **BYOK** — Anda tetap memegang kepemilikan kunci API penyedia AI. - **Policy enforcement** — DSL deklaratif untuk tenant, workspace, dan pengguna; mencakup allow, deny, require-approval, dan human-in-the-loop. - **Audit log integritas-terjamin** — setiap entri saling terhubung secara kriptografis sehingga modifikasi historis dapat dideteksi. - **Deteksi PII berlapis** — kombinasi pola regional, kamus kustom, dan NER kontekstual. - **Compliance multi-framework** — readiness scoring terhadap framework yang relevan untuk audiens Indonesia maupun internasional. ## Mulai cepat | Mulai dari | Untuk | |------------|-------| | [Quickstart](/docs/quickstart) | Tim integrasi | | [BYOK guide](/docs/byok-guide) | Administrator tenant | | [Fitur](/docs/features/byok) | Reviewer keamanan dan compliance | ## Fitur utama Dokumentasi per fitur: - [BYOK](/docs/features/byok) — kelola kredensial penyedia AI per tenant. - [Workspaces](/docs/features/workspaces) — isolasi multi-environment per tim atau lifecycle stage. - [Policies](/docs/features/policies) — DSL governance dan template siap pakai. - [Risk](/docs/features/risk) — signal scoring, snapshot, dan metodologi yang dapat ditelusuri. - [Compliance](/docs/features/compliance) — framework subscription, posture, evidence, dan maturity matrix. ## Audiens Dokumentasi ini ditujukan untuk tim integrasi, administrator tenant, serta reviewer keamanan dan compliance yang melakukan due diligence terhadap Monago. Dokumen operations internal, detail deployment, dan dokumen procurement teknis tidak disertakan di sini dan tersedia melalui jalur terpisah. ## Bahasa Bahasa Indonesia adalah bahasa utama. Versi English tersedia melalui toggle `EN` di header. ## Support --- ## Quickstart **URL:** https://docs.monago.io/docs/quickstart **Description:** Konfigurasi Monago dalam tiga langkah untuk tim integrasi. Panduan ringkas untuk mengonfigurasi Monago sebagai governance gateway dan mengirim permintaan pertama. Prasyarat: peran admin di tenant Monago dan akun aktif di penyedia AI yang ingin diintegrasikan. ## Langkah 1 — Memperoleh kunci API dari penyedia Pilih satu atau lebih penyedia AI. ### OpenAI ### Anthropic ### AWS Bedrock Simpan plaintext kunci pada password manager Anda untuk digunakan pada Langkah 2. ## Langkah 2 — Mendaftarkan kredensial di Monago Monago memvalidasi kunci terhadap endpoint metadata penyedia dengan batas waktu singkat. Indikator *"Memvalidasi kunci…"* ditampilkan selama proses berlangsung. ### Dialog tampil-sekali (penting) Setelah validasi berhasil, dialog tampil-sekali (show-once) menampilkan plaintext kunci. ## Langkah 3 — Mengirim permintaan melalui Monago ```bash curl -X POST https://gateway.monago.io/v1/chat/completions \ -H "Authorization: Bearer $MONAGO_JWT" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o-mini", "messages": [{"role": "user", "content": "Halo!"}] }' ``` Monago akan: 1. Mengidentifikasi kredensial aktif untuk tenant + penyedia yang relevan. 2. Mendekripsi kunci hanya untuk durasi pemrosesan permintaan. 3. Meneruskan permintaan ke penyedia menggunakan kunci pelanggan. 4. Mencatat audit log dengan integritas terjamin secara kriptografis. 5. Menerapkan policy enforcement, deteksi PII, dan risk scoring. 6. Mengembalikan respons ke aplikasi pelanggan. Konfigurasi selesai. Monago sekarang aktif sebagai governance gateway dengan model BYOK. ## Langkah berikutnya | Topik | Dokumen | |-------|---------| | Rotasi kunci, troubleshooting, FAQ | [BYOK guide](/docs/byok-guide) | | Policy enforcement DSL | Dashboard → Policies | | Audit trail + observability | Dashboard → Observability | | Compliance posture | Dashboard → Compliance | ## Troubleshooting ringkas ### "Kunci API tidak valid" - Periksa whitespace pada saat copy-paste (spasi atau newline di awal atau akhir). - Verifikasi kunci masih aktif di dashboard penyedia. - Periksa status billing akun penyedia. ### "Nama kredensial sudah digunakan" Setiap kombinasi tenant + penyedia membutuhkan nama unik. Konvensi yang direkomendasikan: `production-openai-v2`, `staging-openai`. ### Permintaan gateway gagal setelah kredensial dinonaktifkan Perilaku yang diharapkan. Saat kredensial dinonaktifkan, deployment cloud akan menggunakan kunci default platform bila administrator deployment telah mengonfigurasinya. Pada deployment on-premise, permintaan dikembalikan dengan error konfigurasi karena tidak ada fallback. Solusi: aktifkan kembali kredensial melalui UI. Detail lebih lanjut: [BYOK guide — Troubleshooting](/docs/byok-guide#6-troubleshooting). --- ## API Documentation **URL:** https://docs.monago.io/docs/en/api **Description:** AI Governance Gateway for enterprise LLM access. Drop-in, OpenAI-compatible, with PII protection, configurable enforcement, cost visibility, and a signed audit trail on every request. # Monago Atrium — API Documentation > AI Governance Gateway for enterprise LLM access. Drop-in, OpenAI-compatible, with PII protection, configurable enforcement, cost visibility, and a signed audit trail on every request. --- ## Overview Monago Atrium sits between your application and large language model (LLM) providers (OpenAI, Anthropic, and others) as a **Policy Enforcement Point**. Every request passes through the gateway before reaching a provider, and every response passes back through it. At this checkpoint, Atrium applies governance: it detects and redacts personally identifiable information (PII), enforces per-tenant policy, scans for prompt injection, accounts for cost, and writes a tamper-evident audit record. Atrium is designed around **Zero Trust principles (aligned with NIST SP 800-207)** at the data-governance layer: no request is implicitly trusted, every request is evaluated against policy, and security enforcement is **top-down** — a security baseline set at the tenant level cannot be weakened by a workspace or user below it. ### What Atrium gives you - **Multi-layer PII detection** — structured identifiers (national ID, tax ID, phone, bank account, email) plus named-entity recognition for unstructured PII such as person, organization, and location names. - **Configurable enforcement** — choose how detected PII is handled per policy: allow, warn, partial mask, full redaction, or block. - **Top-down policy** — a tenant's security baseline is a *floor*; teams can tighten it but never loosen it. - **Cost visibility** — estimated per-request cost is returned on every call and aggregated for reporting. - **Audit trail** — every request produces a signed audit record, surfaced via a request-level audit ID. - **Drop-in compatibility** — the chat endpoint mirrors the OpenAI Chat Completions API, so existing clients and SDKs work with minimal changes. ### Supported providers A single Atrium API works across providers — the governance layer is provider-agnostic, and routing is resolved from the model identifier. | Provider | Status | |----------|--------| | OpenAI | Available | | Anthropic | Available | | AWS Bedrock | On the roadmap | | Google Vertex AI | On the roadmap | | Alibaba Cloud Model Studio (Qwen) | On the roadmap | Your code does not change per provider: keep the same OpenAI-compatible request shape and switch the `model` field. Which providers and models are permitted is governed by your policy's model allowlist. ### Who this is for - **Evaluators / security & compliance reviewers** — start with [Overview](#overview), [Governance Headers](#governance-headers), [PII Enforcement Modes](#pii-enforcement-modes), and [Compliance](#compliance). - **Developers** — start with [Authentication](#authentication) and [API Reference](#api-reference). --- ## Getting Started ### Base URL ``` https://api.monago.io ``` ### Authentication All requests authenticate with a workspace API key passed as a Bearer token. ``` Authorization: Bearer sk-mng-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` API keys are issued and managed in the Monago console. A key is scoped to a tenant (and optionally a workspace); the governance policy that applies to a request is resolved from that scope. Keep keys secret and rotate them if exposed. ### Quickstart (cURL) ```bash curl -X POST https://api.monago.io/v1/chat/completions \ -H "Authorization: Bearer sk-mng-YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o-mini", "messages": [ { "role": "user", "content": "Summarize the onboarding policy." } ] }' ``` ### Quickstart (Python SDK) ```bash pip install monago-atrium ``` ```python from monago_atrium import Monago client = Monago(api_key="sk-mng-YOUR_KEY") result = client.chat( model="gpt-4o-mini", messages=[{"role": "user", "content": "Summarize the onboarding policy."}], ) print(result.content) print(result.audit_id) # signed audit reference print(result.pii_redacted) # PII types redacted before the provider saw them print(result.cost_idr) # estimated cost for this request ``` --- ## API Reference ### Create a chat completion ``` POST /v1/chat/completions ``` OpenAI-compatible chat completion, governed by your policy. Supports both standard and streaming responses. Try it live below — paste your `sk-mng-` key, edit the request, and the code samples (cURL / Python / TypeScript) update as you type. The response panel surfaces the `X-Monago-*` governance headers. #### Request body | Field | Type | Required | Description | |-------|------|----------|-------------| | `model` | string | yes | Model identifier (e.g. `gpt-4o-mini`). Must be permitted by your policy's model allowlist. | | `messages` | array | yes | Conversation messages. Each item has `role` (`system` / `user` / `assistant`) and `content` (string). 1–200 messages. | | `stream` | boolean | no | When `true`, returns a Server-Sent Events stream. Defaults to `false`. | | `max_tokens` | integer | no | Maximum tokens to generate (1–200000). | | `temperature` | number | no | Sampling temperature (0.0–2.0). | ```json { "model": "gpt-4o-mini", "messages": [ { "role": "system", "content": "You are a helpful assistant." }, { "role": "user", "content": "Draft a one-line welcome message." } ], "max_tokens": 256, "temperature": 0.7, "stream": false } ``` #### Response body The response shape mirrors the OpenAI Chat Completions format. | Field | Type | Description | |-------|------|-------------| | `id` | string | Completion identifier. | | `object` | string | Always `chat.completion`. | | `created` | integer | Unix timestamp. | | `model` | string | Resolved provider model. | | `choices` | array | Generated choices, each with `index`, `message` (`role`, `content`), and `finish_reason`. | | `usage` | object | `prompt_tokens`, `completion_tokens`, `total_tokens`. | ```json { "id": "chatcmpl-...", "object": "chat.completion", "created": 1779896327, "model": "gpt-4o-mini-2024-07-18", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "Welcome aboard — glad to have you!" }, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 23, "completion_tokens": 11, "total_tokens": 34 } } ``` Governance results (PII detection, policy decision, cost, audit reference) are returned as **response headers** — see below. --- ### Governance Headers Every response carries governance metadata in `X-Monago-*` headers. These let your application observe what the gateway did without parsing the body. | Header | Always present | Description | |--------|----------------|-------------| | `X-Monago-Audit-Id` | yes | Signed audit reference for this request. Use it to look up the full audit record. | | `X-Monago-Provider` | yes | Upstream provider that served the request. | | `X-Monago-Latency-Ms` | yes | Gateway-measured latency in milliseconds. | | `X-Monago-Pii-Detected` | yes | `true` / `false` — whether any PII was detected. | | `X-Monago-Pii-Redacted` | when PII found | Comma-separated list of PII types redacted before the request reached the provider (e.g. `nik,phone_id,PERSON`). | | `X-Monago-Policy-Decision` | yes | The policy outcome, e.g. `allowed`. | | `X-Monago-Decision-Source` | yes | Source of the decision (policy engine identifier). | | `X-Monago-Cost-Idr` | when computed | Estimated cost of the request in IDR. | | `X-Monago-Block-Reason` | on block | Present when a request is blocked by policy. | > **PII redaction happens before the provider sees the request.** When `X-Monago-Pii-Redacted` lists a type, that data was replaced with a placeholder in the text sent upstream — the provider never receives the original value. --- ### PII Enforcement Modes How detected PII is handled is controlled by your policy's PII action. Each mode is a point on a strictness ladder; a stricter mode set at the tenant level cannot be overridden to a looser mode by a workspace. | Mode | Behavior | Sent to provider? | |------|----------|-------------------| | `allow` | Pass the request through unchanged. | Original | | `warn` | Pass through, but record detection in the audit log. | Original | | `partial_mask` | Redact PII keeping a short tail (industry "card-number" style, e.g. `****-****-****-0123`) so users can recognize their own data. | Masked (tail kept) | | `full_mask` | Redact PII completely with no remainder (e.g. `[REDACTED_NIK]`). | Masked (zero-tail) | | `block` | Reject the request. It is **not** forwarded to the provider. | No | Strictness order: `allow` < `warn` < `partial_mask` < `full_mask` < `block`. When a request is blocked, the API returns `403` with error code `PII_BLOCKED` (see [Errors](#errors)). --- ### Streaming Set `"stream": true` to receive a Server-Sent Events (SSE) stream. The stream interleaves **governance events** with **content events**, so you can observe policy, PII, routing, and provider stages in real time, followed by the model output. ```bash curl -N -X POST https://api.monago.io/v1/chat/completions \ -H "Authorization: Bearer sk-mng-YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o-mini", "stream": true, "messages": [{ "role": "user", "content": "Hello" }] }' ``` Event types: | Event | Payload | |-------|---------| | `governance` | A pipeline stage update: `policy`, `pii`, `routing`, `provider`, `audit`. Includes status and a short metadata summary. | | `content` | An OpenAI-style chat completion chunk with a `delta`. | | `done` | Final event with `usage`, `audit_id`, and `session_id`. | Example governance event: ``` event: governance data: {"step": "pii", "status": "flagged", "meta": "3 types · PERSON, nik, phone_id", "detail": {"types": ["PERSON", "nik", "phone_id"]}} ``` > On streaming responses, the audit reference is always available (in the `audit` governance event and the final `done` event). Some non-streaming headers are not repeated on the SSE channel by design. --- ### Errors Errors are returned with an appropriate HTTP status and a stable machine-readable `code`. | Code | HTTP | Meaning | |------|------|---------| | `PII_BLOCKED` | 403 | Request blocked because PII was detected and policy is set to `block`. | | `MODEL_NOT_ALLOWED` | 403 | The requested model is not in your policy's allowlist. | | `OUTSIDE_ALLOWED_HOURS` | 403 | Request made outside the policy's permitted hours. | | `MAX_TOKENS_EXCEEDED` | 403 | Requested `max_tokens` exceeds the policy limit. | | `TRIAL_EXPIRED` | 403 | The tenant's trial period has ended. | | `UNKNOWN_MODEL` | 400 | The model identifier is not recognized. | | `NO_ACTIVE_CREDENTIAL` | 400 | No active upstream provider credential is configured for this scope. | | `PROVIDER_NOT_CONFIGURED` | 503 | The target provider is not configured. | | `PROVIDER_RATE_LIMITED` | 429 | The upstream provider rate-limited the request. | | `PROVIDER_TIMEOUT` | 504 | The upstream provider timed out. | | `PROVIDER_UPSTREAM_ERROR` | 502 | The upstream provider returned an error. | All error responses include the governance audit headers where available, so a blocked or failed request is still traceable via `X-Monago-Audit-Id`. --- ## SDK The Python SDK wraps the API and surfaces governance results as first-class fields. ```bash pip install monago-atrium ``` ```python from monago_atrium import Monago client = Monago(api_key="sk-mng-YOUR_KEY") result = client.chat( model="gpt-4o-mini", messages=[{"role": "user", "content": "Help me write a customer reply."}], ) # Model output print(result.content) # Governance surface print(result.audit_id) # signed audit reference print(result.pii_detected) # bool print(result.pii_redacted) # list of redacted PII types print(result.policy_decision) print(result.cost_idr) # estimated cost, when available ``` The SDK is open-core and tracks the API's governance contract. Streaming and additional language SDKs are on the roadmap. --- ## Compliance Atrium is built to support enterprise data-governance obligations, particularly for regulated sectors such as banking and financial services in Indonesia. - **Data minimization at the perimeter.** PII can be redacted or blocked at the gateway, so sensitive identifiers need never leave your trust boundary toward a third-party LLM provider. This supports obligations under Indonesia's Personal Data Protection Law (UU PDP). - **Top-down enforcement (Zero Trust aligned).** Security policy is set at the tenant level as a non-negotiable floor; teams can apply stricter controls but cannot weaken the baseline. This follows the Zero Trust principle (NIST SP 800-207) of explicit, top-down policy enforcement at a dedicated enforcement point. *(Atrium is aligned with these principles; "Zero Trust Architecture" is a framework, not a certification.)* - **Auditability.** Every request produces a signed, tamper-evident audit record referenced by `X-Monago-Audit-Id`, supporting after-the-fact review and regulatory reporting. - **Cost transparency.** Per-request cost estimates support internal chargeback and budget governance. For data-residency and on-premise deployment options, contact the Monago team. --- ## Notes & Conventions - The chat endpoint is intentionally **OpenAI-compatible**: in most cases you can point an existing OpenAI client at the Atrium base URL and add your `sk-mng-` key. - Governance behavior (which models are allowed, how PII is handled, permitted hours) is determined by the **policy bound to your API key's scope**, configured in the Monago console — not by request parameters. - All timestamps are Unix epoch seconds; all monetary estimates in `X-Monago-Cost-Idr` are in Indonesian Rupiah and are **estimates for reporting**, not provider-billed amounts. --- ## BYOK guide **URL:** https://docs.monago.io/docs/en/byok-guide **Description:** Self-service guide for configuring BYOK (Bring Your Own Key) AI providers in Monago. A comprehensive reference for tenant administrators managing AI provider credentials in the Monago Governance Gateway. ## 1. Overview Monago applies a **BYOK** (Bring Your Own Key) model — the customer brings their own AI provider API key (OpenAI, Anthropic, AWS Bedrock). Monago operates as a *governance gateway*: - Enforces governance rules at the tenant, workspace, and user levels. - Captures an integrity-protected audit trail for every request. - Provides observability, cost analytics, and compliance posture. Token usage is billed directly by the AI provider to the customer; Monago uses a separate subscription model for the governance and audit layer. ## 2. Prerequisites - A Monago account with the **admin** role. - Access to the **AI Providers** menu. - Plaintext API key from your AI provider (see section 3). - A password manager or internal secret vault to store the plaintext after the show-once dialog. ## 3. Acquiring the API key from the provider ### 3.1 OpenAI ### 3.2 Anthropic ### 3.3 AWS Bedrock ## 4. Configuration in Monago ### 4.1 Open AI Providers ### 4.2 Add the credential Monago validates the key against the provider's metadata endpoint with a short timeout. The *"Validating key…"* indicator is displayed during the operation. ### 4.3 Show-once dialog (important) After successful validation, the show-once dialog opens. ## 5. Managing credentials ### 5.1 Credential list The **AI Providers** tab shows the credentials table with columns: name, provider, masked key display, status, created date, and actions. Filter chips above the table support filtering by **provider** and **status**. ### 5.2 Disable temporarily To pause use of a credential without permanent revocation. When the credential is disabled, the gateway: - **Cloud**: uses the platform's default key if the deployment administrator has configured one. - **On-premise**: returns a configuration error since there is no fallback. Re-enable: row action → **Enable**. ### 5.3 Rotate the key **Scenarios that require rotation**: - Your organisation's compliance policy (periodic rotation). - A suspected key compromise. - The provider has revoked the key from their side. The old key is replaced by the new one; the gateway begins using the new key on the next request. ### 5.4 Revoke a credential A permanent action — the credential is revoked while the audit trail is retained. The status changes to *Revoked*. A revoked credential cannot be re-enabled — create a new credential if needed. ## 6. Troubleshooting ### "Invalid API key" Common causes: - Whitespace introduced during copy-paste (leading or trailing spaces or newlines). - The key has expired or been revoked at the provider. - The provider account billing status is inactive. - The key scope does not include the metadata endpoint. - An incorrect base URL when using a custom endpoint. The provider's response message is surfaced on the *"Provider detail:"* line below the main error to support diagnosis. ### "Credential name already used for this provider" Each tenant + provider combination requires a unique name. Use a version suffix, e.g. `production-openai-v2`. ### "AI provider credential not found" - The credential may have been revoked by another administrator in your tenant. - Refresh the page to load the latest state. ### Gateway request fails after the credential is disabled This is expected behaviour. When the credential is disabled, the gateway will use the platform's default key if the deployment administrator has configured one. If no fallback has been configured (typical on-premise), the gateway returns a configuration error. Resolution: re-enable the credential through the UI. ### Show-once dialog does not appear after submit Common causes: - Metadata-only operations (without key rotation) do not produce a new plaintext. The table will show the credential with a masked display. - A network error — check the browser DevTools console. ### Validation timeout The provider's metadata endpoint occasionally exhibits higher latency. Retry the request; transient errors are common. If the issue persists, contact provider support. ## 7. FAQ ### 7.1 How is my API key encrypted? Monago applies at-rest encryption using industry-standard cryptographic controls. Plaintext is decrypted only for the duration of an inference request handled by the gateway. For production deployments, Monago supports *envelope encryption* with **Customer-Controlled Key Management Service** (KMS). The Monago team has no operational authority over the customer's KMS, so plaintext recovery requires customer authorisation. ### 7.2 Can the Monago team see the plaintext of my API key? No. The plaintext is encrypted at rest and decrypted only for the duration of an inference request. No product workflow re-presents the plaintext after the show-once dialog closes. ### 7.3 Does the audit log record the plaintext API key? No. The audit log records credential metadata: provider, credential name, the last four characters of the key, and field-level changes. The prohibition on writing plaintext to the audit log is enforced by an automated regression test that runs on every release. ### 7.4 The plaintext was lost after the show-once dialog. How do I recover access? Plaintext recovery through Monago is not available; rotate the credential. ### 7.5 Can multiple administrators manage credentials? Yes. Every user with the admin role on the tenant can view, create, rotate, disable, and revoke credentials. The audit log records the user performing each action. ### 7.6 Is there a limit on the number of credentials per tenant? There is no hard limit during the pilot. Recommendation: 1 to 3 credentials per provider (e.g. `prod`, `staging`, `dev`). When multiple active credentials exist for one provider, the gateway uses the most recently created credential. ### 7.7 Can on-premise deployments use BYOK? Yes. The UI flow is identical. Differences: - The super_admin role is not available on-premise — admin is the highest authority. - The fallback default key is optional and configured by the deployment administrator. - KMS encryption is customer-managed. ### 7.8 What happens if my tenant is deleted? Deleting a tenant also releases and removes all associated credentials. The audit log is retained for forensic needs. Confirm with support before performing destructive operations. ## 8. Security best practices ## 9. Compliance mapping Per-clause mapping detail and the evidence package are delivered in a separate procurement document — contact [support@monago.io](mailto:support@monago.io) for a PDF copy. ## 10. Support --- ## Welcome to Monago **URL:** https://docs.monago.io/docs/en **Description:** AI Governance Operating System — documentation for integration, BYOK, policies, risk, and compliance. --- ## Quickstart **URL:** https://docs.monago.io/docs/en/quickstart **Description:** Configure Monago in three steps for integration teams. A concise walkthrough for configuring Monago as a governance gateway and sending your first request. Prerequisites: the admin role in a Monago tenant and an active account at the AI provider you intend to integrate. ## Step 1 — Acquire the provider API key Pick one or more AI providers. ### OpenAI ### Anthropic ### AWS Bedrock Stash the plaintext key in your password manager — it will be used in Step 2. ## Step 2 — Register the credential in Monago Monago validates the key against the provider's metadata endpoint with a short timeout. The *"Validating key…"* indicator is displayed while validation is in progress. ### Show-once dialog (important) After successful validation, the show-once dialog displays the plaintext key. ## Step 3 — Send a request through Monago ```bash curl -X POST https://gateway.monago.io/v1/chat/completions \ -H "Authorization: Bearer $MONAGO_JWT" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o-mini", "messages": [{"role": "user", "content": "Hi!"}] }' ``` Monago will: 1. Resolve the active credential for the tenant + provider pair. 2. Decrypt the key only for the duration of the request. 3. Forward the request to the provider using the customer's key. 4. Capture an audit log entry with cryptographic integrity chaining. 5. Apply policy enforcement, PII detection, and risk scoring. 6. Return the response to the customer application. Configuration is complete. Monago is now active as a governance gateway under the BYOK model. ## Next steps | Topic | Document | |-------|----------| | Rotation, troubleshooting, FAQ | [BYOK guide](/docs/en/byok-guide) | | Policy enforcement DSL | Dashboard → Policies | | Audit trail + observability | Dashboard → Observability | | Compliance posture | Dashboard → Compliance | ## Quick troubleshooting ### "Invalid API key" - Check for whitespace introduced during copy-paste (leading or trailing spaces or newlines). - Verify the key is still active in the provider dashboard. - Check the billing status of the provider account. ### "Credential name already used" Each tenant + provider combination requires a unique name. Recommended convention: `production-openai-v2`, `staging-openai`. ### Gateway request fails after the credential is disabled This is expected behaviour. When the credential is disabled, cloud deployments will use the platform's default key if the deployment administrator has configured one. On-premise deployments return a configuration error since there is no fallback. Resolution: re-enable the credential through the UI. Further detail: [BYOK guide — Troubleshooting](/docs/en/byok-guide#6-troubleshooting). --- ## BYOK **URL:** https://docs.monago.io/docs/features/byok **Description:** Bring Your Own Key — manajemen kredensial penyedia AI di Monago. ## Overview **BYOK** adalah model arsitektur Monago di mana pelanggan menggunakan kontrak penyedia AI yang dimilikinya sendiri (OpenAI, Anthropic, AWS Bedrock). Monago beroperasi sebagai *governance gateway* di atas kontrak tersebut. Konsumsi token ditagih langsung oleh penyedia kepada pelanggan; Monago menggunakan model berlangganan terpisah untuk lapisan governance dan audit. Relevansi BYOK untuk organisasi yang teregulasi: - **Kepemilikan kontrak penyedia** — organisasi tetap menjadi pemilik akun penyedia AI dan memiliki kendali penuh atas data processing chain. - **Audit trail end-to-end** — visibilitas billing dan model usage berada di dashboard penyedia, sementara governance dan decision logging berada di Monago. - **Minim vendor lock-in** — kunci API menjadi aset pelanggan; perpindahan gateway hanya membutuhkan migrasi metadata. - **Transparansi biaya** — tidak ada lapisan margin pada token usage. Audiens halaman ini: administrator tenant yang mengelola kredensial AI. ## Concepts | Term | Definisi | |------|----------| | **Tenant credential** | Satu entri kredensial yang menyimpan kunci API terenkripsi untuk satu penyedia. | | **Provider type** | Penyedia AI yang didukung Monago: OpenAI, Anthropic, AWS Bedrock. | | **Credential name** | Label internal yang dipilih administrator (misalnya `production-openai`). Unik per kombinasi tenant + penyedia. | | **Last 4 chars** | Empat karakter terakhir kunci API untuk tampilan masking pada UI. | | **Show-once** | Plaintext kunci hanya ditampilkan satu kali pada saat pembuatan atau rotasi kredensial. | | **Fallback default** | Kunci default platform yang digunakan bila tenant tidak memiliki kredensial aktif (deployment cloud). | | **Status** | Lifecycle state kredensial: aktif, dinonaktifkan, atau dicabut. | ## Setup ### Prasyarat - Peran **admin** di tenant. - Akses ke menu **Penyedia AI**. - Plaintext kunci API dari dashboard penyedia AI; lihat [BYOK guide](/docs/byok-guide) untuk panduan acquisition. - Password manager atau secret vault internal untuk menyimpan plaintext setelah dialog tampil-sekali. ### Langkah konfigurasi Monago memvalidasi kunci dengan permintaan ke endpoint metadata penyedia. Setelah validasi berhasil, kunci dienkripsi at-rest dengan mekanisme kriptografi standar industri sebelum disimpan. ### Dialog tampil-sekali Setelah validasi berhasil, dialog tampil-sekali (show-once) menampilkan plaintext kunci. Salin, tempelkan ke password manager, konfirmasi, dan tutup dialog. Setelah dialog ditutup, plaintext tidak lagi tersedia melalui product workflow — pemulihan akses dilakukan dengan melakukan rotasi kredensial. ## Usage ### Daftar kredensial aktif Tab Penyedia AI menampilkan tabel kredensial dengan kolom: nama, penyedia, tampilan kunci (masked), status, tanggal dibuat, dan aksi. Filter chip di atas tabel: **penyedia** dan **status**. ### Rotasi kunci Skenario yang membutuhkan rotasi: - Compliance policy organisasi Anda. - Indikasi kemungkinan kunci kompromis. - Pencabutan kunci dari sisi penyedia. ### Menonaktifkan sementara Menghentikan penggunaan kredensial tanpa mencabutnya secara permanen. Saat dinonaktifkan: - **Cloud**: gateway menggunakan kunci default platform bila administrator deployment telah mengonfigurasinya. - **On-premise**: gateway mengembalikan error konfigurasi karena tidak ada fallback. ### Mencabut kredensial Aksi permanen. Konfirmasi membutuhkan input nama kredensial persis (case-sensitive). Setiap pencabutan kredensial dicatat di audit log dengan pengguna pelaku, timestamp, dan empat karakter terakhir kunci. ## Compliance mapping Detail mapping per-clause dan evidence package disampaikan dalam dokumen procurement terpisah — hubungi [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### "Kunci API tidak valid" Penyebab umum: whitespace pada plaintext, kunci kadaluarsa, billing penyedia tidak aktif, scope kunci tidak mencakup endpoint metadata, atau base URL tidak tepat. Pesan respons dari penyedia ditampilkan pada baris *"Detail penyedia:"* di bawah error utama. ### "Nama kredensial sudah digunakan" Gunakan suffix versioning, misalnya `production-openai-v2`. ### "Kredensial penyedia AI tidak ditemukan" Kredensial kemungkinan telah dicabut oleh administrator lain. Refresh halaman untuk memuat state terbaru. ### Permintaan gateway gagal setelah kredensial dinonaktifkan Perilaku yang diharapkan. Gateway akan mencoba menggunakan kunci default platform. Aktifkan kembali kredensial atau konfigurasikan kunci default melalui administrator deployment. ### Validation timeout Endpoint metadata penyedia kadang lambat. Coba ulang permintaan; transient error umum terjadi. ## FAQ ### Apakah tim Monago dapat melihat plaintext kunci API saya? Tidak. Plaintext dienkripsi at-rest dan didekripsi hanya selama durasi pemrosesan permintaan inference. ### Apakah audit log mencatat plaintext kunci? Tidak. Audit log mencatat metadata kredensial: penyedia, nama, empat karakter terakhir kunci, dan perubahan field-level. Larangan penulisan plaintext ke audit log ditegakkan oleh regression test otomatis pada setiap rilis. ### Plaintext hilang setelah dialog tampil-sekali ditutup. Bagaimana memulihkannya? Buat kunci baru dari dashboard penyedia, lalu lakukan rotasi di Monago. Kunci lama otomatis digantikan. ### Bisakah beberapa administrator mengelola kredensial? Ya. Seluruh pengguna dengan peran admin pada tenant dapat melihat, membuat, melakukan rotasi, dan mencabut kredensial. Audit log mencatat pengguna yang melakukan setiap aksi. ### Apakah ada batas jumlah kredensial per tenant? Tidak ada hard limit pada pilot. Rekomendasi: 1 hingga 3 kredensial per penyedia. Apabila terdapat lebih dari satu kredensial aktif untuk satu penyedia, gateway menggunakan yang paling baru. ### Apakah deployment on-premise dapat menggunakan BYOK? Ya. Flow UI identik. Perbedaan: peran super_admin tidak tersedia, fallback default key bersifat opsional, dan KMS encryption dikelola oleh pelanggan. ### Bagaimana cara melakukan rotasi tanpa downtime? Rotasi di Monago bersifat atomik — permintaan berikutnya akan menggunakan kunci baru tanpa downtime. Beri jeda satu hari penuh sebelum mencabut kunci lama dari sisi penyedia. ## Related - [Quickstart](/docs/quickstart) — setup tiga langkah untuk tim integrasi. - [BYOK guide](/docs/byok-guide) — acquisition, setup, dan rotasi lengkap. - [Workspaces](/docs/features/workspaces) — isolasi multi-environment. - [Compliance](/docs/features/compliance) — framework readiness dan evidence. --- ## Compliance **URL:** https://docs.monago.io/docs/features/compliance **Description:** Framework readiness scoring, gap analysis, evidence reference, dan maturity matrix. ## Overview **Compliance** adalah komponen governance Monago yang mengagregat policy, asset, audit, dan risk signal menjadi framework readiness scoring. Administrator tenant berlangganan ke framework yang berlaku, kemudian Monago menghitung readiness per clause dan maturity level per dimensi secara otomatis. Framework yang didukung mencakup standar internasional dan regulasi domestik Indonesia, di antaranya: - **UU PDP 2022** — Undang-Undang Pelindungan Data Pribadi Indonesia. - **POJK 11/2022** — Otoritas Jasa Keuangan, manajemen risiko teknologi informasi. - **NIST AI RMF 1.0** — NIST AI Risk Management Framework. - **ISO/IEC 42001:2023** — AI management system standard. - **ISO/IEC 27001:2022** — Information security management. Relevansi compliance subsystem: - **Kebutuhan multi-framework** — organisasi umumnya harus patuh terhadap beberapa framework secara paralel. Tracking manual per framework tidak efisien dan rentan error. - **Otomasi evidence** — setiap policy, asset, dan entri audit log otomatis terhubung ke clause framework melalui field `framework_mapping`. Mapping manual menjadi bottleneck pada fase audit preparation. - **Visibilitas posture** — dashboard menampilkan persentase readiness, gap clause, dan maturity level per framework. - **Audit preparation** — audit untuk forensic query dengan prinsip 4-eyes / dual approval memenuhi kebutuhan privileged access control. Audiens halaman ini: compliance officer dan administrator tenant yang mengelola framework subscription dan memantau readiness posture. ## Concepts | Term | Definisi | |------|----------| | **Framework subscription** | Berlangganannya tenant terhadap satu framework. Mengaktifkan readiness scoring dan posture tracking untuk seluruh clause framework tersebut. | | **Framework version** | Snapshot framework pada satu point in time. Versi baru (misalnya amendment UU PDP) ditambahkan sebagai versi baru tanpa membatalkan readiness historis. | | **Clause** | Persyaratan compliance atomik (misalnya UU PDP Pasal 39). Memiliki `priority_weight` (kritikal, tinggi, normal). | | **Evidence reference** | Pointer dari clause ke artifact yang memenuhinya (policy_version, asset, audit_row, risk_snapshot). | | **Readiness score** | Persentase clause dengan evidence aktif. | | **Gap clauses** | Clause tanpa evidence aktif. Diurutkan dari prioritas tertinggi. | | **Maturity matrix** | Pemetaan level per dimensi. Skala 5 tingkat. | ## Setup ### Prasyarat - Peran **admin** untuk berlangganan atau berhenti berlangganan. - Policy dan asset telah dilengkapi field `framework_mapping` (sumber utama deteksi coverage clause). - Pemahaman framework yang berlaku pada konteks organisasi Anda. ### Berlangganan framework Setelah berlangganan, Monago otomatis menghubungkan policy dan asset yang telah dilengkapi `framework_mapping` dengan clause framework tersebut sebagai evidence reference. Audit log mencatat peristiwa berlangganan. ### Mengelola subscription Tab Framework menampilkan tabel subscription: framework dan versi, status, target sertifikasi, tanggal berlangganan, dan aksi. Berhenti berlangganan bersifat soft-suspend — evidence reference tetap dipertahankan untuk keperluan audit. Berlangganan kembali mengembalikan posture tracking secara langsung. ## Usage ### Tab Posture Kartu readiness per framework: - **Persentase readiness** (0-100%). - **Coverage clause kritikal**. - **Maturity level** (1-5) — agregat dari matrix dimensi. - Klik kartu untuk menelusuri detail. Kartu menggunakan kode warna: - **Hijau** (90-100%): production-ready. - **Kuning** (70-89%): mature dengan beberapa gap. - **Oranye** (40-69%): in-progress. - **Merah** (0-39%): early-stage. ### Tab Gap analysis Tabel per clause untuk framework yang dipilih: - **Code + title** — identifier dan nama clause. - **Category** — pengelompokan clause. - **Priority** — Kritikal, Tinggi, atau Normal. - **Evidence status** — Covered atau Gap. Filter: berdasarkan priority, category, atau status. Sort secara descending berdasarkan priority. Gap clauses merupakan action item bagi compliance officer — gap prioritas tinggi membutuhkan policy atau asset baru untuk menutupnya. ### Tab Evidence Daftar seluruh evidence reference aktif: - **Clause** yang dipenuhi. - **Type** — policy_version, asset, audit_row, atau risk_snapshot. - **Reference** — tautan ke artifact sumber. - **Created at**. Use case: menelusuri evidence spesifik saat auditor menanyakan policy atau asset mana yang menutup clause tertentu. ### Tab Maturity matrix Level per dimensi (1-5): **Dimensi NIST AI RMF**: - GOVERN — governance dan policy framework. - MAP — context dan risk identification. - MEASURE — assessment dan monitoring. - MANAGE — risk treatment dan incident response. **Fase ISO/IEC 42001**: - PLAN — membangun AI management system. - DO — implementasi dan operasi. - CHECK — monitoring dan pengukuran. - ACT — perbaikan berkelanjutan. Interpretasi level: | Level | Label | Makna | |-------|-------|-------| | 1 | Initial | Ad-hoc, tanpa proses terdokumentasi | | 2 | Managed | Terdokumentasi tetapi belum konsisten | | 3 | Defined | Proses terstandar | | 4 | Quantitatively managed | Metrics-driven | | 5 | Optimising | Perbaikan berkelanjutan | ### Audit untuk forensic query (privileged access) Untuk ekspor data sensitif (audit log, data pribadi untuk permintaan regulator), Monago menerapkan prinsip 4-eyes / dual approval: Mendukung pemenuhan privileged access control sesuai UU PDP Pasal 16-22 dan POJK § audit. ## Compliance mapping Matrik cakupan per framework: | Framework | Cakupan | |-----------|---------| | UU PDP 2022 Pasal 16-22 | Privileged access control: forensic 4-eyes + RBAC + audit log | | UU PDP 2022 Pasal 39 | Data accountability: deteksi PII berlapis + audit per request + evidence auto-mapping | | POJK 11/2022 § governance | Policy engine + audit log + framework subscription | | POJK 11/2022 § risk management | Risk subsystem + threshold-breach audit + evidence terhubung ke clauses | | ISO/IEC 42001:2023 | AI management system pillars | | NIST AI RMF 1.0 | Map / Measure / Manage cycle + signal evidence + maturity matrix | | ISO/IEC 27001:2022 | Encryption at rest + audit + access control + risk treatment | Detail mapping per-clause dan evidence package disampaikan dalam dokumen procurement terpisah — hubungi [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### Persentase readiness rendah Tinjau tab Gap analysis — daftar gap clauses ditampilkan. Penyebab umum: - Policy belum memiliki field `framework_mapping` — sunting policy dan tambahkan mapping. - Asset registry kosong — daftarkan AI asset pada Asset Registry. - Audit log belum cukup matang (tenant baru, signal feed terbatas). Solusi: prioritaskan gap kritikal; tambahkan policy atau asset yang me-mapping ke clause tersebut. ### Auto-mapping evidence tidak terpicu Proses auto-mapping berjalan secara berkala di background. Refresh halaman setelah perubahan policy untuk melihat update terbaru. Periksa struktur `framework_mapping`: ```json "framework_mapping": [ {"framework": "UU_PDP_2022", "clause": "Pasal 39"} ] ``` Enum framework dan kode clause harus cocok dengan registered framework clauses pada katalog backend. ### Apakah unsubscribe dan re-subscribe menghilangkan posture? Tidak. Evidence reference dipertahankan dalam soft-suspend state. Berlangganan kembali mengembalikan posture secara langsung. ### Maturity level kosong / N/A Evaluator maturity matrix membutuhkan minimum sample size (tenant dengan audit history yang memadai). Tenant baru menampilkan "Pending — insufficient data" sampai data terkumpul. ### Forensic query tidak mendapat respons Forensic query bersifat async (audit log + email notifikasi ke administrator). Periksa inbox dan tab Audit pada Observability untuk status query. ## FAQ ### Bisakah saya berlangganan beberapa framework sekaligus? Ya. Tenant dapat berlangganan seluruh framework yang berlaku. Evidence reference saling berbagi — satu policy dapat me-mapping ke beberapa clause di beberapa framework. ### Bagaimana cara mengonboard framework baru (misalnya amendment UU PDP)? Versi framework baru dikelola oleh tim Monago dan ditambahkan ke katalog secara berkala. Tenant menerima pemberitahuan melalui email saat versi baru tersedia. Migrasi berlangsung mulus: versi lama dipertahankan untuk posture historis; versi baru mulai tracking sejak titik berlangganan. ### Apa perbedaan Compliance dengan subsystem Risk? - **Risk** — kuantitatif (0-100), per asset, signal-driven, near-real-time, untuk operational vigilance. - **Compliance** — kualitatif (Ready, Gap), per framework clause, evidence-driven, daily aggregate, untuk audit readiness. Keduanya saling melengkapi. ### Bisakah workspace_admin mengelola subscription? Tidak. Framework subscription merupakan konfigurasi pada level tenant (admin only). workspace_admin dapat melihat posture untuk workspace yang dikelolanya. ### Bagaimana evidence direvoke saat policy dihapus? Soft cascade. Saat policy diarsipkan, evidence reference yang mengacu pada policy_version tersebut di-mark *revoked* (status ditandai sementara row dipertahankan untuk audit). Skor readiness dihitung ulang pada eksekusi evaluator berikutnya. ### Apakah PCI-DSS didukung? Pilot scope: UU PDP, POJK, NIST AI RMF, ISO 42001, ISO 27001. Dukungan PCI-DSS merupakan bagian dari roadmap pengembangan — hubungi tim untuk konfirmasi timeline bila Anda memproses card data. ### Bagaimana cara mempersiapkan audit dengan dokumen yang disetujui regulator? Workflow: Template audit deliverable procurement-grade tersedia atas permintaan — hubungi [support@monago.io](mailto:support@monago.io). ## Related - [Policies](/docs/features/policies) — `framework_mapping` menjadi sumber evidence auto-mapping. - [Risk](/docs/features/risk) — risk score menginformasikan compliance posture. - [Workspaces](/docs/features/workspaces) — workspace_id pada evidence mendukung posture per workspace. - [BYOK](/docs/features/byok) — enkripsi BYOK menjadi evidence terkait clause ISO 27001. --- ## Policies **URL:** https://docs.monago.io/docs/features/policies **Description:** Aturan governance deklaratif yang dievaluasi pada setiap permintaan inference. ## 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 | Term | Definisi | |------|----------| | **Policy rule** | Container persistent yang menyimpan policy. Memiliki beberapa version; satu version aktif pada waktu tertentu. | | **Policy version** | Snapshot definisi policy. Versioning memungkinkan audit dan rollback. | | **Policy DSL** | Skema JSON dengan field `name`, `when`, `effect`, `priority`, dan `framework_mapping` opsional. | | **Effect** | Tindakan yang diambil saat kondisi cocok. | | **Priority** | Bilangan bulat 0-100. Pada multiple match, policy dengan priority tertinggi menang. | | **Framework mapping** | Opsional — menghubungkan policy ke clause framework untuk feed compliance posture. | | **Workspace scope** | Policy dapat workspace-bound atau tenant-wide. | | **Template** | Policy siap pakai yang dapat di-instansiasi administrator. | ### Anatomi policy Contoh policy yang memblokir penggunaan LLM external untuk data finance klasifikasi confidential: ```json { "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) | Template | Use case | |----------|----------| | PII redaction default | Redaksi identifier sensitif pada request body sebelum diteruskan ke penyedia | | Finance external LLM restriction | Memblokir LLM external untuk data finance klasifikasi confidential / restricted | | Model allowlist by team | Mengizinkan model tertentu hanya untuk tim tertentu | | Token budget cap per user | Memblokir permintaan saat akumulasi token harian per pengguna melampaui batas | | Time-of-day restriction | Mengizinkan permintaan hanya pada jam kerja | | Premium model approval gate | Memicu approval HITL untuk permintaan ke premium model | 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 | Effect | Perilaku | |--------|----------| | `allow` | Permintaan diteruskan ke penyedia | | `deny` | Permintaan diblokir; respons 403 dengan `deny_reason_code` dan user message | | `log_only` | Permintaan diteruskan; audit log diperkaya tanpa enforcement | | `redact` | Konten sensitif diganti placeholder sebelum diteruskan | | `require_approval` | Permintaan ditahan; administrator menerima notifikasi untuk approval | | `require_hitl` | Permintaan ditahan; reviewer human-in-the-loop menerima notifikasi | | `escalate` | Permintaan diteruskan tetapi di-flag untuk review post-hoc | ## 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](mailto: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](/docs/features/byok) — kredensial penyedia (target matching `model_provider`). - [Workspaces](/docs/features/workspaces) — scope workspace untuk isolasi policy. - [Risk](/docs/features/risk) — policy decision menjadi sumber risk signal. - [Compliance](/docs/features/compliance) — agregasi framework mapping. --- ## Risk **URL:** https://docs.monago.io/docs/features/risk **Description:** Signal scoring, snapshot per asset, dan methodology engine untuk operational vigilance. ## Overview **Risk** adalah komponen governance Monago yang menghitung skor risiko per asset dan per tenant berdasarkan signal event dari aktivitas inference dan keputusan governance. Setiap signal diproses oleh methodology engine yang menerapkan bobot per kategori (security, compliance, operational) untuk menghasilkan skor risiko 0-100, kemudian mengklasifikasikan hasilnya ke dalam empat band. Relevansi risk scoring: - **Risk yang terukur** — framework pengukuran risiko AI yang auditable; menjawab kebutuhan regulator akan measurement framework yang quantifiable. - **Visibilitas eksekutif** — risk dashboard menyajikan ringkasan eksekutif tanpa perlu menelusuri audit log. - **Analisis tren** — snapshot per asset over time memungkinkan tracking risk posture sebelum dan sesudah deploy policy baru. - **Eskalasi proaktif** — threshold breach menghasilkan audit event yang dapat di-route ke incident response. Audiens halaman ini: administrator tenant yang memantau risk posture, dan auditor atau compliance officer yang menelaah signal trail. ## Concepts | Term | Definisi | |------|----------| | **Risk signal** | Event yang memicu re-evaluasi risk score. Sumber: policy decision, deteksi PII, prompt injection score, dan abnormality signal. | | **Risk snapshot** | Skor per asset pada satu point in time. Menyertakan breakdown per kategori dan trail signal evidence. | | **Methodology** | Konfigurasi bobot dan threshold yang mengatur perhitungan skor. Dapat disunting administrator tenant; perubahan tercatat di audit log. | | **Score band** | Klasifikasi 4-tingkat: low, medium, high, critical. | | **Signal evidence** | Array referensi ke event spesifik yang berkontribusi pada snapshot. | | **Recompute** | Manual trigger untuk re-evaluasi seluruh snapshot. | ## Setup ### Prasyarat - Peran **admin** untuk konfigurasi methodology. - Tenant aktif dengan signal feed minimum. Tenant baru menghasilkan snapshot kosong sampai signal terkumpul. - Pemahaman risk appetite organisasi Anda agar threshold dan bobot relevan dengan konteks. ### Konfigurasi methodology Default methodology disediakan dengan baseline yang umum digunakan; administrator dapat menyesuaikan. Validasi: bobot keempat kategori berjumlah total 1.0; threshold ketiga band diurutkan menaik (low_max < medium_max < high_max). Field input UI menampilkan validasi inline. ### Trigger recompute (opsional) Setelah pembaruan methodology, snapshot yang sudah ada baru mencerminkan bobot baru saat signal event baru datang, atau saat administrator memicu recompute manual. ## Usage ### Dashboard Tab **Dashboard** menyajikan executive view: - **Skor risiko keseluruhan** untuk tenant. - **Distribusi band** — jumlah asset per band. - **Threshold breach terbaru** — event saat skor asset melintasi threshold band. - **Top signal sources** — kategori signal yang paling dominan pada periode terkini. Halaman menyegarkan data secara berkala. ### Snapshot table Tab **Snapshot** menampilkan snapshot per asset: - Nama asset, skor risiko, dan badge band (color-coded). - Timestamp komputasi terakhir. - Indikator tren (naik, turun, stabil). - Klik row untuk membuka dialog detail dengan breakdown per kategori dan daftar signal evidence. ### Signal events Tab **Sinyal** menampilkan raw signal event: - Source. - Severity. - Dimensi. - Timestamp dan asset terkait. - Klik untuk membuka dialog detail dengan metadata event. Bermanfaat untuk keperluan forensik — auditor dapat menelusuri skor tertentu kembali ke event individual. ### Audit trail methodology Tab **Metodologi** menyediakan section history yang menampilkan konfigurasi sebelumnya (read-only). Setiap penyuntingan tercatat dengan pengguna yang menyunting, timestamp, dan diff bobot. Mendukung demonstrasi due diligence kepada auditor. ## Compliance mapping Detail mapping per-clause dan evidence package disampaikan dalam dokumen procurement terpisah — hubungi [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### Dashboard kosong / empty state Tenant baru belum memiliki signal feed. Pemicu signal: - Mengirim permintaan inference yang melanggar policy (uji intensional). - Mengaktifkan deteksi PII dengan policy `redact`. - Menunggu evaluator memproses signal yang masuk. Pilihan lain: trigger recompute manual untuk mem-bootstrap snapshot dari data yang sudah ada. ### Skor asset tertahan pada band tertentu Periksa tab Sinyal — apakah ada dimensi signal yang dominan? Methodology yang tidak seimbang (misalnya bobot compliance terlalu tinggi) dapat menggeser skor secara konsisten ke satu arah. Solusi: tinjau dan sesuaikan bobot. ### "Sum bobot tidak 1.0" Bobot keempat kategori harus berjumlah total 1.0. Field input UI menampilkan validasi inline saat penyuntingan berlangsung. ### Recompute timeout Pada tenant dengan jumlah asset sangat besar, recompute dapat mengalami timeout. Hubungi support untuk dukungan recompute asinkronus pada skala produksi. ### Snapshot belum terbarui setelah signal baru Evaluator snapshot berjalan secara berkala. Tunggu beberapa saat dan refresh halaman, atau trigger recompute manual untuk pembaruan immediate. ## FAQ ### Bisakah risk score dikustomisasi per asset? Tidak pada pilot. Methodology bersifat tenant-scoped dan berlaku untuk seluruh asset di tenant. Per-asset override untuk asset kritikal merupakan bagian dari roadmap pengembangan. ### Bisakah skor diekspor untuk reporting? Ekspor CSV atau PDF untuk rentang snapshot merupakan bagian dari roadmap pengembangan. Saat ini, gunakan endpoint API snapshot untuk menarik data mentah dan memprosesnya pada tooling eksternal. ### Apa perbedaan risk score dengan compliance posture? - **Risk score** bersifat kuantitatif (0-100), per asset, signal-driven, dan near-real-time. - **Compliance posture** bersifat kualitatif (Ready, Gap, Pending), per framework clause, evidence-driven, dan daily aggregate. Keduanya saling melengkapi — risk score untuk operational vigilance, compliance posture untuk audit readiness. ### Bagaimana cara menentukan threshold yang tepat? Baseline default sesuai untuk sebagian besar use case. Sesuaikan dengan risk appetite organisasi Anda — risk-averse menggunakan threshold yang lebih ketat; risk-tolerant menggunakan threshold yang lebih longgar. Pernyataan risk appetite internal merupakan acuan utama. ### Apakah perubahan methodology bersifat retroactive? Tidak secara otomatis. Snapshot yang sudah ada tetap menggunakan methodology yang berlaku saat snapshot dibuat (immutable untuk audit). Snapshot baru menggunakan methodology terkini. Untuk menerapkan methodology baru pada snapshot historis: trigger recompute manual. ### Bisakah workspace_admin mengelola methodology? Tidak — methodology merupakan konfigurasi pada level tenant (admin only). workspace_admin dapat melihat risk dashboard untuk workspace yang dikelolanya. ### Apakah signal dari workspace berbeda terisolasi? Snapshot ter-scope per asset; asset ter-scope per workspace. Dashboard tenant-wide dapat difilter per workspace untuk mendapatkan tampilan terisolasi. Methodology tetap dibagi pada level tenant. ## Related - [Policies](/docs/features/policies) — policy decision menjadi sumber risk signal. - [Compliance](/docs/features/compliance) — risk score menginformasikan compliance posture. - [Workspaces](/docs/features/workspaces) — scope workspace untuk tampilan dashboard per workspace. --- ## Workspaces **URL:** https://docs.monago.io/docs/features/workspaces **Description:** Multi-environment isolation per tim atau lifecycle stage di dalam tenant. ## Overview **Workspaces** memungkinkan tenant memisahkan policy, AI asset, dan observability data per environment atau per tim, sementara tetap berbagi resource pada level tenant seperti AI Providers, audit chain, dan compliance subscription. Pola ini selaras dengan praktik enterprise SaaS: satu organisasi (tenant) yang membawahi beberapa workspace (sub-isolation). Use case yang umum: - **Pemisahan environment** — `production`, `staging`, dan `development` sebagai workspace terpisah dengan policy dan asset registry masing-masing. - **Isolasi tim** — pemisahan per fungsi tim dengan policy dan model allowlist yang berbeda. - **Scope compliance** — workspace khusus untuk data sensitif yang membutuhkan policy lebih ketat dan retention audit yang lebih panjang. - **Pilot vs production** — workspace terisolasi untuk eksperimen internal sebelum rolling out ke production. Audiens halaman ini: administrator tenant yang menetapkan struktur workspace, dan workspace_admin yang mengelola anggota. ## Concepts | Term | Definisi | |------|----------| | **Workspace** | Sub-isolation di dalam tenant. Policy, asset, dan request log ter-scope per workspace ID. | | **Default workspace** | Workspace yang otomatis aktif saat pengguna login. Tepat satu per tenant. | | **workspace_admin** | Peran pada level workspace. Mengelola anggota dan metadata workspace. | | **workspace_member** | Akses operasional sehari-hari ke policy dan asset workspace. | | **workspace_viewer** | Read-only — cocok untuk auditor atau observer eksternal. | | **Tenant-level resources** | Resource yang dibagi di seluruh workspace pada tenant yang sama. | | **Workspace-level resources** | Resource yang ter-scope per workspace. | ### Tenant vs workspace scope | Resource | Scope | |----------|-------| | Users | Tenant — anggota tenant di-assign ke workspace melalui membership | | AI Providers (BYOK) | Tenant — satu kredensial penyedia melayani seluruh workspace | | API Keys | Tenant — workspace-binding opsional sedang dievaluasi sebagai bagian dari roadmap | | Audit chain | Tenant — entri saling terhubung untuk integritas | | Compliance subscriptions | Tenant — framework subscription pada level tenant | | Policies | Workspace — tuning dan priority per workspace | | Asset registry | Workspace — isolasi multi-environment | | Observability filters | Workspace — scope dashboard per workspace | ## Setup ### Prasyarat - Peran **admin** di tenant untuk membuat atau mengarsipkan workspace. - Peran workspace_admin atau administrator tenant untuk mengelola anggota. - Gambaran struktur tim atau environment yang ingin diisolasi. ### Membuat workspace baru Workspace baru berstatus *aktif* dengan jumlah anggota 1 — administrator pembuat secara otomatis di-assign sebagai workspace_admin. ### Menetapkan default workspace Default workspace adalah workspace yang otomatis aktif saat pengguna login. Tepat satu per tenant. Untuk mengubah default: ### Mengelola anggota Administrator tenant atau workspace_admin dapat menambah dan mengeluarkan anggota. ### Memperbarui peran anggota Pemilihan peran dapat dilakukan secara inline pada kolom *Role* tabel anggota. Administrator tenant atau workspace_admin dapat mengubah peran; perubahan tersimpan langsung. ### Mengeluarkan anggota Tombol **Keluarkan** pada kolom Aksi. Self-removal dicegah oleh UI untuk menghindari accidental lock-out. ## Usage ### Mengganti active workspace Workspace switcher dropdown pada sidebar: Pergantian workspace adalah operasi server-side dan immediate — state diturunkan dari token, bukan dari penyimpanan client. ### Mengarsipkan workspace Soft archive: status workspace menjadi *archived*. Audit chain dan history tetap dipertahankan. Constraint yang ditegakkan: - **Default workspace tidak dapat diarsipkan**. Tetapkan workspace lain sebagai default terlebih dahulu. - **Workspace aktif terakhir tidak dapat diarsipkan**. Tenant harus memiliki minimal satu workspace aktif. Setelah diarsipkan, workspace tidak lagi tampil pada switcher; detail page tetap dapat diakses melalui URL langsung untuk keperluan audit trail. ## Compliance mapping Detail mapping per-clause dan evidence package disampaikan dalam dokumen procurement terpisah — hubungi [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### "Batas 100 workspace tercapai" Tenant memiliki cap default. Solusi: - Arsipkan workspace yang tidak digunakan. - Hubungi support untuk peningkatan cap pada skala produksi. ### "Default workspace tidak dapat diarsipkan" Tetapkan workspace lain sebagai default terlebih dahulu, kemudian arsipkan workspace lama. ### "Minimal harus ada satu workspace aktif" Buat workspace baru sebelum mengarsipkan workspace terakhir. ### "Pengguna sudah menjadi anggota workspace ini" Setiap pengguna memiliki maksimal satu membership per workspace. Perbarui peran melalui inline edit pada tabel anggota apabila diperlukan peran yang berbeda. ### Workspace switcher tidak terbarui setelah pergantian Refresh halaman. Bila masalah berlanjut, logout dan login kembali untuk memperbarui token sesi. ## FAQ ### Apakah AI Providers (BYOK) dibagi antar workspace? Ya. AI Providers merupakan resource pada level tenant. Satu kunci OpenAI melayani seluruh workspace. Scope per workspace diterapkan melalui policy (model allowlist) dan asset registry. ### Bisakah satu pengguna berada di beberapa workspace? Ya. Seorang pengguna dapat di-assign ke beberapa workspace dengan peran yang berbeda. Endpoint switching memungkinkan pergantian antar workspace yang pengguna miliki membership-nya. ### Apa perbedaan workspace_admin dengan administrator tenant? | Aksi | Administrator tenant | workspace_admin | |------|----------------------|-----------------| | Membuat workspace | Ya | Tidak | | Mengarsipkan workspace | Ya | Tidak | | Menetapkan default workspace | Ya | Tidak | | Mengelola anggota | Seluruh workspace | Hanya workspace mereka | | Mengubah metadata workspace | Seluruh workspace | Hanya workspace mereka | | Mengelola AI Providers | Ya | Tidak (level tenant) | | Mengelola Users (level tenant) | Ya | Tidak (level tenant) | ### Bisakah saya mengubah nama workspace setelah dibuat? Ya — nama workspace dapat disunting. Slug bersifat immutable karena merupakan referensi pada audit log dan bookmark URL. ### Apa yang terjadi bila saya mengarsipkan workspace yang sedang aktif? UI mengarahkan ke list page setelah arsip berhasil. Workspace switcher otomatis memilih default workspace melalui pembaruan token sesi. Tidak ada data yang hilang. ### Apa yang terjadi bila tenant saya dihapus? Penghapusan tenant melepaskan seluruh workspace, membership, policy, dan asset yang terkait. Konfirmasi melalui support sebelum melakukan operasi destructive. ## Related - [BYOK](/docs/features/byok) — kredensial penyedia AI (scope tenant). - [Policies](/docs/features/policies) — DSL governance per workspace. - [Risk](/docs/features/risk) — signal scoring per workspace. - [Compliance](/docs/features/compliance) — framework readiness aggregate. --- ## BYOK **URL:** https://docs.monago.io/docs/en/features/byok **Description:** Bring Your Own Key — AI provider credential management in Monago. ## Overview **BYOK** is Monago's architectural model where the customer uses their own AI provider contracts (OpenAI, Anthropic, AWS Bedrock). Monago operates as a *governance gateway* on top of those contracts. Token usage is billed directly by the provider to the customer; Monago uses a separate subscription model for the governance and audit layer. Why BYOK is relevant for regulated organisations: - **Provider contract ownership** — the organisation remains the account holder and retains full control over the data processing chain. - **End-to-end audit trail** — billing and model usage visibility stays in the provider's dashboard, while governance and decision logging sits in Monago. - **Minimal vendor lock-in** — the API key is a customer asset; switching gateways requires only metadata migration. - **Cost transparency** — no margin layer on top of token usage. Audience for this page: tenant administrators managing AI credentials. ## Concepts | Term | Definition | |------|------------| | **Tenant credential** | A credential entry that stores an encrypted API key for one provider. | | **Provider type** | The AI providers supported by Monago: OpenAI, Anthropic, AWS Bedrock. | | **Credential name** | An internal label chosen by the administrator (e.g. `production-openai`). Unique per tenant + provider pair. | | **Last 4 chars** | The last four characters of the API key used for masked display in the UI. | | **Show-once** | The plaintext key is displayed only once during credential creation or rotation. | | **Fallback default** | The platform's default key, used when a tenant has no active credential (cloud deployments). | | **Status** | Credential lifecycle state: active, disabled, or revoked. | ## Setup ### Prerequisites - The **admin** role on the tenant. - Access to the **AI Providers** menu. - A plaintext API key from the provider dashboard; see the [BYOK guide](/docs/en/byok-guide) for acquisition guidance. - A password manager or internal secret vault to store the plaintext after the show-once dialog. ### Configuration steps Monago validates the key by calling the provider's metadata endpoint. On success, the key is encrypted at rest with industry-standard cryptographic controls before storage. ### Show-once dialog After successful validation, the show-once dialog displays the plaintext key. Copy it, paste it into your password manager, acknowledge, and close. Once dismissed, the plaintext is no longer surfaced through any product workflow — recovery requires rotating the credential. ## Usage ### Active credentials list The AI Providers tab shows the credentials table with columns: name, provider, masked key display, status, created date, and actions. Filter chips above the table: **provider** and **status**. ### Rotate the key Scenarios that require rotation: - Your organisation's compliance policy. - A suspected key compromise. - The provider has revoked the key from their side. ### Disable temporarily To pause use of a credential without permanent revocation. When disabled: - **Cloud**: the gateway uses the platform's default key when the deployment administrator has configured one. - **On-premise**: the gateway returns a configuration error since there is no fallback. ### Revoke a credential A permanent action. Confirmation requires typing the credential name exactly (case-sensitive). Every revocation is recorded in the audit log with the user performing the action, the timestamp, and the last four characters of the key. ## Compliance mapping Per-clause mapping detail and the evidence package are delivered in a separate procurement document — contact [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### "Invalid API key" Common causes: whitespace in the plaintext, an expired key, inactive provider billing, an insufficient scope for the metadata endpoint, or an incorrect base URL. The provider's response message is surfaced on the *"Provider detail:"* line below the main error. ### "Credential name already used" Use a version suffix, e.g. `production-openai-v2`. ### "AI provider credential not found" The credential may have been revoked by another administrator. Refresh the page to load the latest state. ### Gateway request fails after the credential is disabled This is expected behaviour. The gateway will attempt to use the platform's default key. Re-enable the credential or have the deployment administrator configure a default key. ### Validation timeout The provider's metadata endpoint can be slow. Retry; transient errors are common. ## FAQ ### Can the Monago team see the plaintext of my API key? No. The plaintext is encrypted at rest and decrypted only for the duration of an inference request. ### Does the audit log record the plaintext of the key? No. The audit log records credential metadata: provider, name, the last four characters of the key, and field-level changes. The prohibition on writing plaintext to the audit log is enforced by an automated regression test on every release. ### The plaintext was lost after the show-once dialog. How do I recover access? Generate a new key from the provider dashboard, then rotate in Monago. The old key is replaced automatically. ### Can multiple administrators manage credentials? Yes. Every user with the admin role on the tenant can view, create, rotate, and revoke credentials. The audit log records the user performing each action. ### Is there a limit on the number of credentials per tenant? There is no hard limit during the pilot. Recommendation: 1 to 3 credentials per provider. When multiple active credentials exist for one provider, the gateway uses the most recently created credential. ### Can on-premise deployments use this BYOK flow? Yes. The UI flow is identical. Differences: the super_admin role is not available, the fallback default key is optional, and KMS encryption is customer-managed. ### How do I rotate without downtime? Rotation in Monago is atomic — the next request uses the new key without downtime. Allow a one-day safety window before revoking the old key at the provider. ## Related - [Quickstart](/docs/en/quickstart) — three-step setup for integration teams. - [BYOK guide](/docs/en/byok-guide) — acquisition, setup, and rotation in full. - [Workspaces](/docs/en/features/workspaces) — multi-environment isolation. - [Compliance](/docs/en/features/compliance) — framework readiness and evidence. --- ## Compliance **URL:** https://docs.monago.io/docs/en/features/compliance **Description:** Framework readiness scoring, gap analysis, evidence references, and the maturity matrix. ## Overview **Compliance** is the governance component of Monago that aggregates policies, assets, audit, and risk signals into framework readiness scoring. A tenant administrator subscribes to the frameworks that apply, after which Monago computes per-clause readiness and per-dimension maturity automatically. Supported frameworks include both international standards and Indonesian regulations, among others: - **UU PDP 2022** — Indonesia's Personal Data Protection law. - **POJK 11/2022** — Otoritas Jasa Keuangan, IT risk management. - **NIST AI RMF 1.0** — NIST AI Risk Management Framework. - **ISO/IEC 42001:2023** — AI management system standard. - **ISO/IEC 27001:2022** — Information security management. Why the compliance subsystem matters: - **Multi-framework requirements** — organisations typically have to comply with several frameworks in parallel. Tracking manually per framework is inefficient and error-prone. - **Evidence automation** — every policy, asset, and audit log entry is automatically linked to a framework clause through the `framework_mapping` field. Manual mapping becomes an audit-prep bottleneck. - **Posture visibility** — the dashboard shows readiness percentage, gap clauses, and maturity level per framework. - **Audit preparation** — the forensic-query audit (4-eyes / dual approval) satisfies privileged access control requirements. Audience for this page: compliance officers and tenant administrators managing framework subscriptions and monitoring readiness posture. ## Concepts | Term | Definition | |------|------------| | **Framework subscription** | A tenant's active subscription to one framework. Enables readiness scoring and posture tracking for every clause. | | **Framework version** | A point-in-time snapshot of the framework. New versions (e.g. UU PDP amendments) are added as new versions without invalidating historical readiness. | | **Clause** | An atomic compliance requirement (e.g. UU PDP Pasal 39). Holds a `priority_weight` (critical, high, normal). | | **Evidence reference** | A pointer from a clause to an artifact satisfying it (policy_version, asset, audit_row, risk_snapshot). | | **Readiness score** | Percentage of clauses with active evidence. | | **Gap clauses** | Clauses without active evidence. Sorted by priority descending. | | **Maturity matrix** | A per-dimension level mapping. A 5-level scale. | ## Setup ### Prerequisites - The **admin** role to subscribe or unsubscribe. - Policies and assets with the `framework_mapping` field set (the primary signal for clause coverage detection). - A clear picture of which frameworks apply to the organisation's context. ### Subscribe to a framework After subscription, Monago automatically links policies and assets that have been annotated with `framework_mapping` to the clauses of the framework as evidence references. The audit log records the subscription event. ### Manage subscriptions The Framework tab shows the subscriptions table: framework and version, status, target certification, subscribe date, and actions. Unsubscribing is a soft suspend — evidence references are retained for audit. Re-subscribing restores posture tracking immediately. ## Usage ### Posture tab Per-framework readiness cards: - **Readiness percentage** (0-100%). - **Critical clauses coverage**. - **Maturity level** (1-5) — aggregated from the dimension matrix. - Click a card to drill down to detail. Cards are colour-coded: - **Green** (90-100%): production-ready. - **Yellow** (70-89%): mature with some gaps. - **Orange** (40-69%): in-progress. - **Red** (0-39%): early-stage. ### Gap analysis tab The per-clause table for the selected framework: - **Code + title** — identifier and clause name. - **Category** — clause grouping. - **Priority** — Critical, High, or Normal. - **Evidence status** — Covered or Gap. Filter by priority, category, or status. Sort descending by priority. Gap clauses are action items for the compliance officer — high-priority gaps require new policies or assets to close. ### Evidence tab A list of every active evidence reference: - **Clause** addressed. - **Type** — policy_version, asset, audit_row, or risk_snapshot. - **Reference** — link to the source artifact. - **Created at**. Use case: drill into specific evidence when an auditor asks which policy or asset covers a particular clause. ### Maturity matrix tab Per-dimension level (1-5): **NIST AI RMF dimensions**: - GOVERN — governance and policy framework. - MAP — context and risk identification. - MEASURE — assessment and monitoring. - MANAGE — risk treatment and incident response. **ISO/IEC 42001 phases**: - PLAN — establish the AI management system. - DO — implement and operate. - CHECK — monitor and measure. - ACT — continual improvement. Level interpretation: | Level | Label | Meaning | |-------|-------|---------| | 1 | Initial | Ad-hoc, no documented process | | 2 | Managed | Documented but inconsistent | | 3 | Defined | Standardised process | | 4 | Quantitatively managed | Metrics-driven | | 5 | Optimising | Continual improvement | ### Forensic query audit (privileged access) For sensitive data extraction (audit log export, personal data for regulator requests), Monago applies the 4-eyes / dual approval principle: This supports privileged access control under UU PDP Pasal 16-22 and POJK § audit. ## Compliance mapping Per-framework coverage matrix: | Framework | Coverage | |-----------|----------| | UU PDP 2022 Pasal 16-22 | Privileged access control: forensic 4-eyes + RBAC + audit log | | UU PDP 2022 Pasal 39 | Data accountability: layered PII detection + audit per request + evidence auto-mapping | | POJK 11/2022 § governance | Policy engine + audit log + framework subscription | | POJK 11/2022 § risk management | Risk subsystem + threshold-breach audit + evidence linked to clauses | | ISO/IEC 42001:2023 | AI management system pillars | | NIST AI RMF 1.0 | Map / Measure / Manage cycle + signal evidence + maturity matrix | | ISO/IEC 27001:2022 | Encryption at rest + audit + access control + risk treatment | Per-clause mapping detail and the evidence package are delivered in a separate procurement document — contact [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### Readiness percentage stuck low Inspect the Gap analysis tab — the list of gap clauses appears. Common causes: - A policy lacks the `framework_mapping` field — edit the policy and add a mapping. - The asset registry is empty — register AI assets in the Asset Registry. - The audit log is not yet mature (a new tenant, a sparse signal feed). Resolution: prioritise critical gaps; add policies or assets that map to those clauses. ### Evidence auto-mapping does not trigger Auto-mapping runs on a fixed background cadence. Refresh the page after a policy change to see the latest update. Check the `framework_mapping` shape: ```json "framework_mapping": [ {"framework": "UU_PDP_2022", "clause": "Pasal 39"} ] ``` The framework enum and clause code must match the registered framework clauses in the backend catalogue. ### Does unsubscribe + re-subscribe lose posture? No. Evidence references are retained in a soft-suspend state. Re-subscribing restores posture immediately. ### Maturity level shows blank / N/A The maturity-matrix evaluator needs a minimum sample size (tenants with sufficient audit history). New tenants see "Pending — insufficient data" until enough data accumulates. ### Forensic query returns no response Forensic queries are async (audit log + email notification to the administrator). Check the inbox and the Audit tab in Observability for query status. ## FAQ ### Can I subscribe to multiple frameworks simultaneously? Yes. A tenant can subscribe to every applicable framework. Evidence references are shared — one policy can map to multiple clauses across multiple frameworks. ### How do I onboard a new framework (e.g. a UU PDP amendment)? New framework versions are managed by the Monago team and added to the catalogue on a regular cadence. Tenants receive an email notification when a new version is available. Migration is seamless: the old version is retained for historical posture, and the new version begins tracking from the subscription point. ### What's the difference between Compliance and the Risk subsystem? - **Risk** — quantitative (0-100), per-asset, signal-driven, near-real-time, for operational vigilance. - **Compliance** — qualitative (Ready, Gap), per-framework clause, evidence-driven, daily aggregate, for audit readiness. The two are complementary. ### Can workspace_admin manage subscriptions? No. Framework subscription is a tenant-level configuration (admin only). workspace_admin can view the posture for the workspace they manage. ### How is evidence revoked when a policy is removed? Soft cascade. When a policy is archived, evidence references pointing to that policy_version are marked *revoked* (the status is flagged while the row is retained for audit). The readiness score is recalculated on the evaluator's next run. ### Is PCI-DSS supported? Pilot scope: UU PDP, POJK, NIST AI RMF, ISO 42001, ISO 27001. PCI-DSS support is on the development roadmap — contact the team for a timeline if you process card data. ### How do I prepare for an audit with regulator-approved documents? Workflow: A procurement-grade audit deliverable template is available on request — contact [support@monago.io](mailto:support@monago.io). ## Related - [Policies](/docs/en/features/policies) — `framework_mapping` feeds evidence auto-mapping. - [Risk](/docs/en/features/risk) — the risk score informs the compliance posture. - [Workspaces](/docs/en/features/workspaces) — workspace_id on evidence supports per-workspace posture. - [BYOK](/docs/en/features/byok) — BYOK encryption is evidence for ISO 27001 clauses. --- ## Policies **URL:** https://docs.monago.io/docs/en/features/policies **Description:** Declarative governance rules evaluated on every inference request. ## Overview **Policies** are declarative governance rules evaluated against every inference request passing through the Monago Gateway. Each policy is written in JSON DSL with the core fields: `name`, `when` (conditions), `effect` (allow / deny / log_only / redact / require_approval / require_hitl), and `priority`. The policy engine is the foundational governance component of Monago. Why the policy engine matters in a regulated context: - **Runtime enforcement** — the policy engine blocks rule-violating requests before they reach upstream AI. - **Auditable decisions** — every policy decision produces an audit chain entry, so regulators can audit both the governance rules and the actual decisions. - **Ready-to-use templates** — common patterns such as PII protection, model allowlist, token budget, time restriction, prompt injection scoring, and premium model approval gate. - **Multi-dimensional matching** — conditions can reference user.team, user.role, request.model, estimated tokens, data classification, and additional fields. Audience for this page: tenant administrators or workspace_admin users who define and maintain governance rules. ## Concepts | Term | Definition | |------|------------| | **Policy rule** | A persistent container storing a policy. It holds multiple versions; one version is active at a time. | | **Policy version** | A snapshot of the policy definition. Versioning enables audit and rollback. | | **Policy DSL** | A JSON schema with `name`, `when`, `effect`, `priority`, and optional `framework_mapping`. | | **Effect** | The action taken when the condition matches. | | **Priority** | An integer from 0 to 100. When multiple policies match, the highest priority wins. | | **Framework mapping** | Optional — links a policy to a framework clause to feed the compliance posture. | | **Workspace scope** | A policy can be workspace-bound or tenant-wide. | | **Template** | A pre-built policy that an administrator can instantiate. | ### Policy anatomy An example policy blocking external LLM for confidential finance data: ```json { "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"} ] } ``` When a request comes from a user on the `finance` team with classification `confidential` to an external provider, the policy engine returns `deny` with a reason code and a user-facing message. The audit row records the decision with the policy version and matched conditions. ## Setup ### Prerequisites - The **admin** role on the tenant (or workspace_admin for a workspace-bound policy). - A clear governance use case (model usage, team restrictions, cost caps, and so on). - Familiarity with the JSON DSL structure, or pick a template. ### Create a policy from a template (recommended) | Template | Use case | |----------|----------| | PII redaction default | Redact sensitive identifiers in the request body before forwarding to the provider | | Finance external LLM restriction | Block external LLM for confidential / restricted finance data | | Model allowlist by team | Allow specific models only for specific teams | | Token budget cap per user | Block requests once the daily cumulative tokens per user exceed the cap | | Time-of-day restriction | Allow requests only during business hours | | Premium model approval gate | Trigger HITL approval for requests to a premium model | The first version is automatically active after creation. ### Create a custom policy (no template) ### Conditions (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 groups are supported for complex expressions. ### Effects | Effect | Behaviour | |--------|-----------| | `allow` | The request is forwarded to the provider | | `deny` | The request is blocked; the response is 403 with `deny_reason_code` and the user message | | `log_only` | The request continues; the audit row is enriched without enforcement | | `redact` | Sensitive content is replaced with a placeholder before forwarding | | `require_approval` | The request is held; the administrator is notified for approval | | `require_hitl` | The request is held; a human-in-the-loop reviewer is notified | | `escalate` | The request continues but is flagged for post-hoc review | ## Usage ### Policy list The Policies page lists every policy rule at the tenant + workspace scope. An empty-state quickstart appears when the tenant does not yet have any policies. ### Policy detail and decision log Click a row to open the detail page (`/policies/{id}`): - Metadata: name, slug, description, framework mapping, priority. - JSON viewer for the active version. - Recent decisions table (20 entries): action, status, matched conditions, user, model, timestamp. - **Create new version** and **Revoke** buttons (admin). ### Create a new version (edit a policy) Policies are versioned — every change produces a new version. ### Priority and conflict resolution When multiple policies match a single request: Recommended priority bands: - **0-30**: log_only or observational policies. - **40-60**: standard governance. - **70-90**: strict governance. - **91-100**: emergency override. ### NER integration for redaction A policy with the `redact` effect can optionally invoke contextual NER for entities that do not match the regional pattern layer. Configuration sits under `effect.redact_config`. ## Compliance mapping Per-clause mapping detail and the evidence package are delivered in a separate procurement document — contact [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### "Invalid policy DSL format" The backend rejects the payload with a detailed error message. Common causes: missing or wrongly shaped condition fields, a typo on the operator, or an effect type outside the allowed enum. Resolution: copy from the closest template and adjust where needed. ### A policy matches but the gateway request still succeeds Check the policy status — if it is *disabled* or *archived*, the engine skips it. Re-activate through the UI or create a new version. ### Multiple policies match and the wrong one wins Priority resolution: highest wins. Check the priority of every matching candidate on the detail page. Reorder by creating a new version with the priority adjusted. ### "Policy not found" when updating a version The policy may have been archived by another administrator. Refresh the list page. ### Redaction does not trigger despite a `redact` policy - Verify the effect is `redact` (not `log_only`). - Verify that `effect.redact_config` is active. - When the contextual NER layer is unavailable, detection still runs on the regional pattern layer; the audit log records which layer is active per request. ## FAQ ### Are policy decisions real-time or async? Real-time. Every inference request is evaluated synchronously before being forwarded to the provider. Latency overhead is minimal because resolution is cached per tenant. ### Can a policy use custom fields beyond the built-in set? The pilot scope only supports the built-in fields (see the list in Setup). Custom fields via an extension mechanism are on the development roadmap. ### Is there a limit on the number of policies per tenant? There is no hard limit during the pilot. Recommendation: keep the count manageable (typically 10 to 30 per tenant) so audit and decision tracing remain straightforward. ### How do I test a policy before deploying to production? Use workspace separation: deploy first to a `staging` workspace, test with a sample workload, then replicate to the production workspace. Dry-run evaluation against a sample request (without enforcement) is on the development roadmap. ### What happens if I delete an active policy? Soft archive (status becomes *archived*). The audit chain and decision history are retained. ### Can workspace_admin create policies? Yes — limited to the workspace they manage (workspace-bound policies). Tenant-wide policies can only be created by tenant administrators. ### What is the difference between log_only and allow? `allow` is an explicit permit with no audit enrichment. `log_only` is a permit with audit log tagging using the policy match metadata for compliance reporting. ## Related - [BYOK](/docs/en/features/byok) — provider credentials (target of `model_provider` matching). - [Workspaces](/docs/en/features/workspaces) — workspace scope for policy isolation. - [Risk](/docs/en/features/risk) — policy decisions feed risk signals. - [Compliance](/docs/en/features/compliance) — framework mapping aggregate. --- ## Risk **URL:** https://docs.monago.io/docs/en/features/risk **Description:** Signal scoring, per-asset snapshots, and the methodology engine for operational vigilance. ## Overview **Risk** is the governance component of Monago that computes per-asset and per-tenant risk scores based on signal events from inference activity and governance decisions. Each signal is processed by a methodology engine that applies per-category weights (security, compliance, operational) to produce a 0-100 risk score, then classifies the result into one of four bands. Why risk scoring matters: - **Quantifiable risk** — an auditable measurement framework for AI risk that addresses regulators' need for a quantifiable measurement framework. - **Executive visibility** — the risk dashboard provides an executive summary without the need to traverse the audit log. - **Trend analysis** — per-asset snapshots over time enable tracking of risk posture before and after a new policy is deployed. - **Proactive escalation** — threshold breaches generate audit events that can be routed to incident response. Audience for this page: tenant administrators monitoring risk posture, and auditors or compliance officers reviewing the signal trail. ## Concepts | Term | Definition | |------|------------| | **Risk signal** | An event that triggers risk score re-evaluation. Sources: policy decisions, PII detections, prompt injection scores, and abnormality signals. | | **Risk snapshot** | A per-asset score at a point in time. Includes a breakdown per category and the signal evidence trail. | | **Methodology** | The weight and threshold configuration governing the score computation. Editable by tenant administrators; changes are recorded in the audit log. | | **Score band** | A 4-tier classification: low, medium, high, critical. | | **Signal evidence** | An array of references to specific events that contribute to the snapshot. | | **Recompute** | A manual trigger to re-evaluate every snapshot. | ## Setup ### Prerequisites - The **admin** role for methodology configuration. - An active tenant with a minimum signal feed. New tenants produce empty snapshots until signals accumulate. - Familiarity with the organisation's risk appetite so thresholds and weights align with context. ### Configure the methodology A default methodology ships with a commonly used baseline; administrators can tune the configuration. Validation: the four category weights sum to 1.0; the three band thresholds are strictly ascending (low_max < medium_max < high_max). The UI input fields show inline validation. ### Trigger recompute (optional) After a methodology update, existing snapshots reflect the new weights only after a new signal arrives, or when an administrator triggers a manual recompute. ## Usage ### Dashboard The **Dashboard** tab provides the executive view: - **Overall risk score** for the tenant. - **Score band distribution** — count of assets per band. - **Recent threshold breaches** — events where an asset's score crossed a band threshold. - **Top signal sources** — the most dominant signal categories for the recent period. The page refreshes data periodically. ### Snapshot table The **Snapshot** tab lists per-asset snapshots: - Asset name, risk score, and band badge (colour-coded). - Last computed timestamp. - Trend indicator (up, down, stable). - Click a row to open the detail dialog with the per-category breakdown and the signal evidence list. ### Signal events The **Signals** tab lists raw signal events: - Source. - Severity. - Dimension. - Timestamp and the linked asset. - Click to open the detail dialog with the event metadata. Useful for forensic work — auditors can trace a specific score back to individual events. ### Methodology audit trail The **Methodology** tab provides a history section that shows previous configurations (read-only). Every edit is recorded with the editing user, timestamp, and the diff of weights. Supports demonstration of due diligence to auditors. ## Compliance mapping Per-clause mapping detail and the evidence package are delivered in a separate procurement document — contact [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### Empty dashboard / empty state A new tenant has no signal feed yet. To generate signals: - Send inference requests that violate a policy (intentional test). - Enable PII detection with a `redact` policy. - Allow the evaluator to process the incoming signals. Alternative: trigger a manual recompute to bootstrap snapshots from existing data. ### An asset score is stuck in one band Check the Signals tab — is one signal dimension dominant? An unbalanced methodology (for example, the compliance weight set too high) can shift scores consistently in one direction. Resolution: review and adjust the weights. ### "Weight sum is not 1.0" The four category weights must sum to 1.0. The UI input fields show inline validation during editing. ### Recompute timeout On tenants with a very large asset count, recompute can time out. Contact support for asynchronous recompute support at production scale. ### Snapshot has not updated after a new signal The snapshot evaluator runs at a fixed interval. Wait briefly and refresh the page, or trigger a manual recompute for an immediate update. ## FAQ ### Can the risk score be customised per asset? Not in the pilot. The methodology is tenant-scoped and applies to every asset in the tenant. Per-asset override for critical assets is on the development roadmap. ### Can scores be exported for reporting? CSV or PDF export for a snapshot range is on the development roadmap. In the meantime, use the snapshot API endpoint to pull raw data and process it on external tooling. ### What's the difference between risk score and compliance posture? - **Risk score** is quantitative (0-100), per-asset, signal-driven, and near-real-time. - **Compliance posture** is qualitative (Ready, Gap, Pending), per-framework clause, evidence-driven, and a daily aggregate. The two are complementary — risk score for operational vigilance, compliance posture for audit readiness. ### How do I pick the right thresholds? The default baseline suits most use cases. Tune to the organisation's risk appetite — risk-averse organisations use stricter thresholds; risk-tolerant organisations use looser ones. The internal risk-appetite statement is the primary anchor. ### Is a methodology change retroactive? Not automatically. Existing snapshots keep the methodology that was in effect when they were created (immutable for audit). New snapshots use the current methodology. To apply the new methodology to historical snapshots: trigger a manual recompute. ### Can workspace_admin manage the methodology? No — the methodology is a tenant-level configuration (admin only). workspace_admin can view the risk dashboard for the workspace they manage. ### Are signals from different workspaces isolated? Snapshots are scoped per asset; assets are scoped per workspace. The tenant-wide dashboard can be filtered per workspace to obtain an isolated view. The methodology remains shared at the tenant level. ## Related - [Policies](/docs/en/features/policies) — policy decisions feed risk signals. - [Compliance](/docs/en/features/compliance) — the risk score informs the compliance posture. - [Workspaces](/docs/en/features/workspaces) — workspace scope for per-workspace dashboard view. --- ## Workspaces **URL:** https://docs.monago.io/docs/en/features/workspaces **Description:** Multi-environment isolation per team or lifecycle stage within a tenant. ## Overview **Workspaces** let a tenant separate policies, AI assets, and observability data per environment or per team, while still sharing tenant-level resources such as AI Providers, the audit chain, and compliance subscriptions. The pattern follows enterprise SaaS practice: one organisation (tenant) containing several workspaces (sub-isolation). Common use cases: - **Environment separation** — `production`, `staging`, and `development` as separate workspaces, each with their own policy and asset registry. - **Team isolation** — separation by functional team with distinct policies and model allowlists. - **Compliance scope** — a workspace for sensitive data with stricter policies and longer audit retention. - **Pilot vs production** — an isolated workspace for internal experiments before rolling out to production. Audience for this page: tenant administrators structuring workspaces, and workspace_admin users managing members. ## Concepts | Term | Definition | |------|------------| | **Workspace** | A sub-isolation inside a tenant. Policies, assets, and request logs are scoped per workspace ID. | | **Default workspace** | The workspace automatically selected at user login. Exactly one per tenant. | | **workspace_admin** | A workspace-level role. Manages workspace members and metadata. | | **workspace_member** | Day-to-day operational access to the workspace's policies and assets. | | **workspace_viewer** | Read-only — suitable for auditors or external observers. | | **Tenant-level resources** | Resources shared across every workspace in the tenant. | | **Workspace-level resources** | Resources scoped per workspace. | ### Tenant vs workspace scope | Resource | Scope | |----------|-------| | Users | Tenant — members assigned to workspaces through membership | | AI Providers (BYOK) | Tenant — one provider credential serves every workspace | | API Keys | Tenant — optional workspace binding is being evaluated on the roadmap | | Audit chain | Tenant — entries chained together for integrity | | Compliance subscriptions | Tenant — framework subscription at the tenant level | | Policies | Workspace — tuning and priority per workspace | | Asset registry | Workspace — multi-environment isolation | | Observability filters | Workspace — dashboard scope per workspace | ## Setup ### Prerequisites - The **admin** role in the tenant to create or archive workspaces. - The workspace_admin or tenant admin role to manage members. - A clear picture of the team or environment structure to isolate. ### Create a new workspace A new workspace is *active* with one member — the creating administrator is automatically assigned as workspace_admin. ### Set the default workspace The default workspace is the workspace auto-selected at user login. Exactly one per tenant. To change the default: ### Manage members A tenant administrator or workspace_admin can add or remove members. ### Update a member's role Role selection is available inline on the *Role* column of the members table. A tenant administrator or workspace_admin can change the role; the update is persisted immediately. ### Remove a member The **Remove** button on the Actions column. Self-removal is prevented by the UI to avoid accidental lock-out. ## Usage ### Switching the active workspace The workspace switcher dropdown in the sidebar: Workspace switching is a server-side, immediate operation — state is derived from the token, not from client storage. ### Archive a workspace A soft archive: the workspace status becomes *archived*. The audit chain and history are retained. Enforced constraints: - **The default workspace cannot be archived**. Set another workspace as the default first. - **The last active workspace cannot be archived**. A tenant must retain at least one active workspace. After archiving, the workspace is no longer shown in the switcher; the detail page remains accessible via direct URL for the audit trail. ## Compliance mapping Per-clause mapping detail and the evidence package are delivered in a separate procurement document — contact [support@monago.io](mailto:support@monago.io). ## Troubleshooting ### "100 workspaces limit reached" The tenant has a default cap. Options: - Archive workspaces that are no longer in use. - Contact support to raise the cap at production scale. ### "The default workspace cannot be archived" Set another workspace as the default first, then archive the old workspace. ### "At least one active workspace required" Create a new workspace before archiving the last one. ### "User is already a member of this workspace" Each user has at most one membership per workspace. Update the role through the inline editor on the members table if a different role is needed. ### The workspace switcher doesn't update after switching Refresh the page. If the issue persists, log out and back in to refresh the session token. ## FAQ ### Are AI Providers (BYOK) shared across workspaces? Yes. AI Providers is a tenant-level resource. One OpenAI key serves every workspace. Workspace scope is applied through policies (model allowlists) and the asset registry. ### Can one user be in multiple workspaces? Yes. A user can be assigned to multiple workspaces with different roles. The switching endpoint allows changing between workspaces where the user holds membership. ### What's the difference between workspace_admin and the tenant administrator? | Action | Tenant administrator | workspace_admin | |--------|----------------------|-----------------| | Create workspace | Yes | No | | Archive workspace | Yes | No | | Set the default workspace | Yes | No | | Manage members | Every workspace | Only their workspace | | Edit workspace metadata | Every workspace | Only their workspace | | Manage AI Providers | Yes | No (tenant-level) | | Manage Users (tenant-level) | Yes | No (tenant-level) | ### Can I rename a workspace after creation? Yes — the name is editable. The slug is immutable because it is a reference held by the audit log and URL bookmarks. ### What happens if I archive the workspace I'm currently in? The UI redirects to the list page after a successful archive. The workspace switcher automatically picks the default workspace via a session refresh. No data is lost. ### What happens if my tenant is deleted? Deleting a tenant releases every workspace, membership, policy, and asset associated with it. Confirm with support before performing destructive operations. ## Related - [BYOK](/docs/en/features/byok) — AI provider credentials (tenant-level scope). - [Policies](/docs/en/features/policies) — governance DSL per workspace. - [Risk](/docs/en/features/risk) — signal scoring per workspace. - [Compliance](/docs/en/features/compliance) — framework readiness aggregate. --- ## Links - [Support](mailto:info@monago.io)