GraphOS Agent Services: akses API masih private preview

Pada 7 Oktober 2026, blog Apollo GraphQL memperkenalkan GraphOS Agent Services sebagai satu endpoint bagi agen AI untuk mengakses API perusahaan, memakai istilah public preview, dan menyebut Intuit sedang mengujinya. Namun, dokumentasi onboarding Apollo secara eksplisit menetapkan private preview: calon pengguna memerlukan bantuan anggota tim Apollo untuk mulai memakai layanan.

Agent Services menempatkan pencarian data, perantara kredensial, keputusan izin, dan catatan aktivitas pada jalur permintaan agen. Dalam laporan Database Trends and Applications, CEO dan salah satu pendiri Apollo, Matt DeBergalis, mengatakan, “Enterprises need to adapt their APIs for AI agents”; laporan itu juga mencatat perluasan GraphOS MCP Server sebagai pengumuman terpisah.

Satu endpoint, dengan keputusan akses per field

Agent Services berada di antara agen dan sistem perusahaan. Model domainnya memetakan layanan, entitas data, serta hubungan di antaranya agar permintaan agen dapat diarahkan ke panggilan API yang sesuai. Layanan ini memperantarai kredensial ke sistem asal, lalu menerapkan aturan pada permintaan dan respons. Dengan begitu, keputusan apakah sebuah nilai boleh diterima agen berada pada kebijakan akses, bukan pada penilaian model bahasa saat membaca respons.

Perbedaan itu terasa ketika API mengembalikan lebih banyak informasi daripada yang diperlukan. Contoh bersyarat: agen layanan pelanggan meminta nama seorang pelanggan, sementara sistem asal juga memiliki alamat dan rincian penagihannya. Jika aturan mengizinkan field nama tetapi menolak field penagihan bagi aplikasi tersebut, rincian penagihan tidak masuk ke konteks agen. Contoh ini menggambarkan pembatasan yang dirancang layanan; hasil pada suatu organisasi tetap bergantung pada field yang dimodelkan dan aturan yang dipasang.

Katalog layanan menjadi titik awalnya. Layanan yang ditambahkan membawa alamat dasar dan tag bawaan pada field, tetapi field dalam layanan baru ditolak sampai ada aturan yang memberinya akses. Pengelola kemudian dapat mengelompokkan data dengan tag, termasuk klasifikasi data pribadi untuk nama dan email, data keuangan untuk pembayaran atau penagihan, serta operasi yang memerlukan persetujuan. Tag khusus tersedia ketika klasifikasi bawaan tidak cukup tepat untuk keputusan akses yang dibutuhkan.

Dari identitas agen sampai hasil yang diterima

Alur izin: identitas pengguna dan aplikasi agen → permintaan melalui runtime → aturan mencocokkan pengguna, klien, layanan, dan tag field → field diizinkan, disamarkan, atau ditolak → aktivitas dicatat untuk pemantauan. Aturan dapat berlaku bagi semua pengguna, satu kelompok, atau seorang pengguna; cakupan kliennya dapat mencakup semua aplikasi atau satu aplikasi tertentu. Orang yang mengajukan permintaan dan aplikasi yang menjalankannya karena itu merupakan bagian berbeda dari keputusan akses.

Penyamaran mempertahankan keberadaan field tanpa memberikan nilai tersimpan. Untuk penolakan, pengelola dapat memilih apakah field disembunyikan, menghasilkan pesan kesalahan, atau memungkinkan permintaan akses. Jika beberapa tag berlaku pada field yang sama, efek yang lebih ketat menang: penolakan mengalahkan penyamaran, sedangkan penyamaran mengalahkan izin penuh. Urutan ini penting bagi field yang sekaligus tergolong data pribadi dan data keuangan, karena aturan yang lebih longgar tidak otomatis membuka nilainya.

Identitas klien pun dibedakan. Sesi interaktif berkaitan dengan seseorang yang masuk saat menggunakan agen, sedangkan aplikasi agen didaftarkan sebagai klien dan menggunakan kunci API miliknya sendiri. Ketika akses dapat diminta, pengajuan memuat field yang diminta, alasannya, dan aturan yang menghalangi; keputusan menerima atau menolaknya memerlukan peran Org Admin. Monitor mencatat permintaan, klien yang mengirimkannya, serta apakah aturan mengubah respons. Catatan itu membantu menelusuri keputusan, sementara pencegahan paparan tetap bergantung pada klasifikasi dan aturan sebelum data mencapai agen.

Mengapa menambah server MCP belum menyelesaikan persoalan yang sama

Lebih banyak koneksi MCP dapat memberi agen lebih banyak alat, tetapi setiap koneksi tambahan juga membawa pertanyaan tentang identitas, kredensial, dan isi respons yang boleh diterima. Agent Services dirancang sebagai satu jalur terkelola menuju layanan perusahaan: organisasi memodelkan data yang tersedia, mengikat aturan pada identitas dan tag, lalu mencatat keputusan akses. Perbedaannya terletak pada kendali atas data sampai tingkat field, bukan sekadar pada jumlah alat yang bisa dipanggil agen.

GraphOS MCP Server melayani pekerjaan lain. Perluasannya memberi agen alat untuk membangun dan mengelola graph melalui kemampuan GraphOS Platform API, termasuk pemeriksaan skema dan pembacaan informasi operasional. Sebuah tim dapat membutuhkan kedua produk, tetapi kredensial untuk mengelola graph dan izin untuk melihat data pelanggan menjawab pertanyaan akses yang berbeda. Menyatukan seluruh koneksi agen tanpa memetakan field sensitif tidak dengan sendirinya menentukan apa yang boleh masuk ke respons.

Batas evaluasi selama private preview

Intuit sudah memakai GraphOS dalam produksi dan sedang menguji Agent Services dalam preview; kedua status itu berlaku untuk produk yang berbeda. Untuk calon pengguna lain, bantuan Apollo saat onboarding berarti cakupan integrasi dan pengaturan operasional perlu dibahas sebelum layanan dapat dievaluasi di lingkungan mereka. Dokumentasi yang tersedia menjelaskan mekanisme izin, tetapi tidak menetapkan tanggal akses umum.

Field apa saja yang akan masuk katalog, siapa yang menetapkan tag untuk field baru, dan bagaimana aturan awal diperiksa sebelum agen diberi akses?
Bagaimana identitas pengguna serta aplikasi agen diteruskan ke sistem asal, dan apa yang berubah pada kredensial yang sekarang disimpan di aplikasi atau server MCP?
Apakah uji preview dapat memperlihatkan hasil izin, penyamaran, penolakan, permintaan akses, dan catatan aktivitas untuk klien yang berbeda?
Siapa yang dapat mencabut akses aplikasi, berapa lama catatan audit disimpan, dan batas dukungan apa yang berlaku selama onboarding?

Jawaban atas pertanyaan tersebut menentukan apakah jalur baru ini sesuai dengan API dan aturan organisasi tertentu. Sampai akses diperluas, pengembang yang ingin menilainya masih harus menyepakati cakupan preview bersama Apollo.