Laravel MCP टूल्ससह AI एजंट्स सुरक्षित करणे
MCP द्वारे तुमच्या ॲपला AI एजंटला प्रवेश देणे म्हणजे एखाद्याला चाव्यांचा गुच्छ देणे आहे. जर तुम्ही नियम ठरवले नाहीत, तर ते चुकीची दारे उघडू शकतात.
मी अलीकडेच एका multi-tenant Laravel ॲपसाठी MCP टूल्स तयार केली. माझे एकच ध्येय होते: एजंटला दुसऱ्या कोणाचाही डेटा न पाहता ॲप चालवू देणे.
MCP टूल्समधील समस्या
प्रत्येक MCP टूल हे एक endpoint आहे. एजंट एका टूलला कॉल करतो आणि तुमचा सर्व्हर कोड रन करतो. एका multi-tenant ॲपमध्ये, प्रत्येक टूलला दोन प्रश्नांची उत्तरे द्यावी लागतात:
- तुम्हाला हे करण्याची परवानगी आहे का?
- तुम्हाला या विशिष्ट संस्थेत (organization) हे करण्याची परवानगी आहे का?
जर तुम्ही एकही गोष्ट चुकली, तर तुमचा डेटा लीक होऊ शकतो.
मानक Multi-Tenancy येथे का अपयशी ठरते
एका सामान्य वेब ॲपमध्ये, तुमच्याकडे sessions असतात. तुम्ही organization ID नुसार डेटा फिल्टर करण्यासाठी global scopes वापरता. हे काम करते कारण "current organization" नेहमी session मध्ये असते.
MCP टूल्स sessions वापरत नाहीत. ते tokens वापरतात. tenant context सेट करण्यासाठी कोणतेही middleware नसते. जर तुम्ही session शोधणाऱ्या global scope वर अवलंबून असाल, तर त्याला काहीही सापडणार नाही. त्यानंतर ते तुमच्या डेटाबेस मधील प्रत्येक row परत करू शकते. हा एक 'silent data leak' आहे.
उपाय: स्पष्ट फिल्टरिंग (Explicit Filtering)
token authentication सोबत ambient scope वर कधीही अवलंबून राहू नका. प्रत्येक वेळी स्पष्टपणे (explicitly) फिल्टर करा.
मी हे हाताळण्यासाठी एक single trait तयार केले:
trait ResolvesOrgEvents
{
protected function resolveOrgEvent(Authenticatable $user, string $uuid): ?Event
{
if (empty($user->organization_id)) {
return null;
}
return Event::query()
->withOrganization($user->organization_id)
->where('uuid', $uuid)
->first();
}
}
हा दृष्टिकोन चार नियमांचे पालन करतो:
- UUIDs वापरा: कधीही auto-increment IDs वापरू नका. एजंटने फक्त नंबर बदलून IDs ओळखू नयेत.
- Single Source of Truth: organization फिल्टर एकाच trait मध्ये असावा. प्रत्येक टूल त्याचा वापर करेल.
- Permissions पुन्हा वापरा: एजंटसाठी नवीन permissions तयार करू नका. तुमचे वेब ॲप जे permission strings वापरते तेच वापरा. यामुळे एजंटला मानवी वापरकर्त्यापेक्षा जास्त अधिकार मिळण्यापासून रोखता येईल.
- Side Effects मार्क करा: एखादे टूल read-only आहे की write-enabled आहे हे दर्शवण्यासाठी annotations वापरा.
सीमांची चाचणी (Testing the Boundary) घेणे
तुम्हाला 'negative path' ची चाचणी घेणे आवश्यक आहे. टूल काम करते की नाही एवढेच तपासू नका. Organization A मधील वापरकर्ता Organization B चा डेटा पाहू शकत नाही, याची चाचणी घ्या.
जर एखाद्या एजंटने दुसऱ्या tenant चा UUID ॲक्सेस करण्याचा प्रयत्न केला, तर टूलने "not found" असे परत केले पाहिजे. डेटा अस्तित्वात आहे पण तो दुसऱ्या कोणाचा आहे, हे एजंटला सांगू नये.
प्रत्येक AI टूलला एक 'untrusted endpoint' समजा. तुमचा डेटा सुरक्षित ठेवण्याचा एकमेव मार्ग म्हणजे शिस्त.