Laravel MCP టూల్స్తో AI ఏజెంట్లను సురక్షితం చేయడం
MCP ద్వారా మీ యాప్కు AI ఏజెంట్కు యాక్సెస్ ఇవ్వడం అనేది ఎవరికైనా కీరింగ్ (keyring) అందించడం వంటిది. మీరు నియమాలను విధించకపోతే, వారు తప్పుడు తలుపులను తెరిచే అవకాశం ఉంది.
నేను ఇటీవల మల్టీ-టెనెంట్ (multi-tenant) Laravel యాప్ కోసం MCP టూల్స్ను రూపొందించాను. నా లక్ష్యం ఒక్కటే: ఏజెంట్ ఇతరుల డేటాను చూడకుండా, యాప్ను నడపడానికి అనుమతించడం.
MCP టూల్స్లోని సమస్య
ప్రతి MCP టూల్ ఒక ఎండ్పాయింట్ (endpoint). ఏజెంట్ ఒక టూల్ను పిలిచినప్పుడు, మీ సర్వర్ కోడ్ను రన్ చేస్తుంది. మల్టీ-టెనెంట్ యాప్లో, ప్రతి టూల్ రెండు ప్రశ్నలకు సమాధానం ఇవ్వాలి:
- మీరు దీనిని చేయడానికి అనుమతించబడ్డారా?
- మీరు ఈ నిర్దిష్ట సంస్థలో (organization) దీనిని చేయడానికి అనుమతించబడ్డారా?
మీరు వీటిలో ఒకటి విస్మరిస్తే, డేటా లీక్ అయ్యే ప్రమాదం ఉంది.
ఇక్కడ సాధారణ మల్టీ-టెనన్సీ ఎందుకు విఫలమవుతుంది
సాధారణ వెబ్ యాప్లో, మీకు సెషన్లు (sessions) ఉంటాయి. ఆర్గనైజేషన్ ID ద్వారా డేటాను ఫిల్టర్ చేయడానికి మీరు గ్లోబల్ స్కోప్స్ను (global scopes) ఉపయోగిస్తారు. "ప్రస్తుత సంస్థ" (current organization) ఎల్లప్పుడూ సెషన్లో ఉండటం వల్ల ఇది పనిచేస్తుంది.
MCP టూల్స్ సెషన్లను ఉపయోగించవు. అవి టోకెన్లను (tokens) ఉపయోగిస్తాయి. టెనెంట్ కాంటెక్స్ట్ను (tenant context) సెట్ చేయడానికి ఎటువంటి మిడిల్వేర్ (middleware) ఉండదు. మీరు సెషన్ కోసం వెతికే గ్లోబల్ స్కోప్పై ఆధారపడితే, అది దేనినీ కనుగొనదు. అప్పుడు అది మీ డేటాబేస్లోని ప్రతి రో (row)ను తిరిగి ఇచ్చే అవకాశం ఉంది. అది ఒక నిశ్శబ్ద డేటా లీక్ (silent data leak).
పరిష్కారం: స్పష్టమైన ఫిల్టరింగ్ (Explicit Filtering)
టోకెన్ అథెంటికేషన్తో యాంబియంట్ స్కోప్ (ambient scope) పై ఎప్పుడూ ఆధారపడకండి. ప్రతిసారీ స్పష్టంగా ఫిల్టర్ చేయండి.
దీనిని నిర్వహించడానికి నేను ఒకే ఒక 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();
}
}
ఈ విధానం నాలుగు నియమాలను అనుసరిస్తుంది:
- UUIDలను ఉపయోగించండి: ఎప్పుడూ ఆటో-ఇంక్రిమెంట్ IDలను ఉపయోగించకండి. ఏజెంట్లు కేవలం ఒక నంబర్ను మార్చడం ద్వారా IDలను ఊహించలేనంత సురక్షితంగా ఉండాలి.
- సింగిల్ సోర్స్ ఆఫ్ ట్రూత్ (Single Source of Truth): ఆర్గనైజేషన్ ఫిల్టర్ ఒకే ఒక traitలో ఉంటుంది. ప్రతి టూల్ దానిని ఉపయోగిస్తుంది.
- పర్మిషన్లను తిరిగి ఉపయోగించండి: ఏజెంట్ల కోసం కొత్త పర్మిషన్లను సృష్టించకండి. మీ వెబ్ యాప్ ఉపయోగించే పర్మిషన్ స్ట్రింగ్స్నే ఉపయోగించండి. ఇది ఏజెంట్ మానవ వినియోగదారుడి కంటే ఎక్కువ అధికారాన్ని పొందకుండా నిరోధిస్తుంది.
- సైడ్ ఎఫెక్ట్స్ను గుర్తించండి: ఒక టూల్ రీడ్-ఓన్లీ (read-only) లేదా రైట్-ఎనేబుల్డ్ (write-enabled) అని చూపించడానికి అనోటేషన్లను (annotations) ఉపయోగించండి.
బౌండరీని పరీక్షించడం (Testing the Boundary)
మీరు నెగటివ్ పాత్ను (negative path) తప్పనిసరిగా పరీక్షించాలి. టూల్ పనిచేస్తుందో లేదో మాత్రమే పరీక్షించకండి. ఆర్గనైజేషన్ A నుండి వచ్చిన వినియోగదారుడు ఆర్గనైజేషన్ B డేటాను చూడలేరని పరీక్షించండి.
ఒక ఏజెంట్ మరొక టెనెంట్కు చెందిన UUIDని యాక్సెస్ చేయడానికి ప్రయత్నిస్తే, టూల్ "not found" అని తిరిగి ఇవ్వాలి. డేటా ఉనికిలో ఉందని, కానీ అది వేరొకరిది అని ఏజెంట్కు చెప్పకూడదు.
ప్రతి AI టూల్ను నమ్మలేని ఎండ్పాయింట్గా పరిగణించండి. మీ డేటాను సురక్షితంగా ఉంచడానికి క్రమశిక్షణ మాత్రమే ఏకైక మార్గం.