ಹೊಸ ಸಂಶೋಧನೆಯ ಪ್ರಕಾರ, Model Context Protocol (MCP)—ಅಂದರೆ large-language-model (LLM) agents ಹೊರಗಿನ ಪರಿಕರಗಳನ್ನು (tools) ಬಳಸಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಇಂಟರ್ಫೇಸ್—"tool-poisoning" ದಾಳಿಗಳ ಮೂಲಕ ಹೈಜಾಕ್ ಆಗಬಹುದು. ಈ ದಾಳಿಗಳು ಮೂರನೇ ಒಂದು ಭಾಗಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಯಶಸ್ವಿಯಾಗುತ್ತವೆ. 20 ಜನಪ್ರಿಯ agents ಗಳಾದವುಗಳಲ್ಲಿ ಸರಾಸರಿ ಯಶಸ್ಸಿನ ದರವು 36.5% ರಷ್ಟಿತ್ತು; o1-mini ಮಾಡೆಲ್ 72.8% ಪ್ರಯತ್ನಗಳಲ್ಲಿ ಸೋತಿದ್ದರೆ, Claude-3.7-Sonnet 3% ಕ್ಕಿಂತ ಕಡಿಮೆ ಬಾರಿ ಮಾತ್ರ ದುರುದ್ದೇಶಪೂರಿತ ಕರೆಗಳನ್ನು ನಿರಾಕರಿಸಿತು. MCP ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ LLM agents ಗಳನ್ನು ಬಳಸುವವರಿಗೆ, ಈ ಸಂಶೋಧನೆಯು ಒಂದು ಅನುಕೂಲಕರ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಯಾವುದೇ ಕೋಡ್ ಚಲಾಯಿಸುವ ಮೊದಲೇ ಬಳಸಿಕೊಳ್ಳಬಹುದಾದ supply-chain ಅಪಾಯವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

ಇಂದು ಡೆವಲಪರ್‌ಗಳಿಗೆ MCP ಏಕೆ ಮುಖ್ಯ

MCP એ agents ಗಳು ಫೈಲ್ ರೀಡರ್‌ಗಳು, web APIs ಅಥವಾ ಇಮೇಲ್ ಸೆಂಡರ್‌ಗಳಂತಹ ಪರಿಕರಗಳನ್ನು ಹೇಗೆ ಪತ್ತೆಹಚ್ಚುತ್ತವೆ, ನೋಂದಾಯಿಸುತ್ತವೆ ಮತ್ತು ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ಪ್ರಮಾಣೀಕರಿಸುತ್ತದೆ. ಒಂದು ಪರಿಕರದ ಹೆಸರು, input schema ಮತ್ತು ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆಯನ್ನು ಪ್ರಕಟಿಸುವ ಮೂಲಕ, ಸರ್ವರ್ ಆ ಸಾಮರ್ಥ್ಯವನ್ನು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಯಾವುದೇ ಕ್ಲೈಂಟ್‌ಗೆ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ. ಇದರ ಉದ್ದೇಶ ಸರಳವಾಗಿದೆ: ಪ್ರತಿ ಇಂಟಿಗ್ರೇಷನ್ ಅನ್ನು ಹಾರ್ಡ್-ಕೋಡ್ ಮಾಡದೆ, ಒಂದು agent ಪರಿಕರವನ್ನು ಹುಡುಕಬಹುದು, ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಬಹುದು.

ಆ ನಮ್ಯತೆಯು (flexibility) ಒಂದು ಅಂತರ್ಗತ ನಂಬಿಕೆಯ ಸಂಬಂಧವನ್ನೂ ಸೃಷ್ಟಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ನಂಬಿರುವ ಸರ್ವರ್‌ನಿಂದ ಬಂದಿದ್ದಲ್ಲಿ ಮಾತ್ರ ಪರಿಕರದ ವಿವರಣೆಗಳನ್ನು ನಂಬಬೇಕೆಂದು ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಸೂಚಿಸುತ್ತದೆ. ಈ ನಂಬಿಕೆಯನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳಬಹುದು ಎಂದು ಹೊಸ ಅಧ್ಯಯನವು ತೋರಿಸುತ್ತದೆ.

Tool-poisoning ಸಾಮಾನ್ಯ prompt injection ಗಿಂತ ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ

ಸಾಂಪ್ರದಾಯಿಕ prompt injection ಮಾಡೆಲ್ ಜನರೇಟ್ ಮಾಡುವ ಅಥವಾ ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಪಡೆಯುವ ಪಠ್ಯದಲ್ಲಿ ದುರುದ್ದೇಶಪೂರಿತ ಸೂಚನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಆ ಸೂಚನೆಗಳು ಬಳಕೆದಾರರ ವಿನಂತಿಯಂತೆಯೇ ಒಂದೇ ಟೋಕನ್ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವುದರಿಂದ ಮಾಡೆಲ್ ಅವುಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, tool-poisoning ಪೇಲೋಡ್ ಅನ್ನು ಪರಿಕರದ metadata ನಲ್ಲಿ ಅಡಗಿಸುತ್ತದೆ—ಅಂದರೆ ಯಾವುದೇ agent ಕರೆಯುವ ಮೊದಲು ನೋಂದಾಯಿಸಲಾಗುವ ಹೆಸರು, ವಿವರಣೆ ಅಥವಾ ಪ್ಯಾರಾಮೀಟರ್ ಸ್ಕೀಮಾ. ನಂತರ ಒಂದು agent ಪರಿಕರವನ್ನು ಆಯ್ಕೆ ಮಾಡಿದಾಗ, ಅದು ವಿವರಣೆಯನ್ನು "trusted context" ನ ಭಾಗವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ರನ್‌ಟೈಮ್ ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ಅಡಗಿರುವ ಸೂಚನೆಯನ್ನು ಅನುಸರಿಸಬಹುದು. ಇಂಜೆಕ್ಷನ್ ನೋಂದಣಿಯ ಸಮಯದಲ್ಲಿ ನಡೆಯುವುದರಿಂದ, ಮಾಡೆಲ್ ಪೇಲೋಡ್ ಅನ್ನು ಸಂಶಯಾಸ್ಪದ ಎಂದು ಗುರುತಿಸಲು ಎಕ್ಸಿಕ್ಯೂಷನ್ ಫ್ಲೋನಲ್ಲಿ ಯಾವುದೇ ಅವಕಾಶವಿರುವುದಿಲ್ಲ.

ಸಮಸ್ಯೆಯ ವ್ಯಾಪ್ತಿ – MCPTox ಬೆಂಚ್‌ಮಾರ್ಕ್

MCPTox (arXiv:2508.14925) ಹಿಂದಿರುವ ಸಂಶೋಧಕರು ಒಟ್ಟು 353 ವಿಭಿನ್ನ ಪರಿಕರಗಳನ್ನು ನೀಡುವ 45 MCP ಸರ್ವರ್‌ಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದರು. ಅವರು ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ 20 LLM agents ವಿರುದ್ಧ ದಾಳಿಗಳನ್ನು ರೂಪಿಸಿದರು ಮತ್ತು agents ಎಷ್ಟು ಬಾರಿ ವಿಷಪೂರಿತ (poisoned) ಪರಿಕರ ಕರೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದವು ಎಂಬುದನ್ನು ಅಳೆದರು.

  • ಸರಾಸರಿ ಯಶಸ್ಸಿನ ದರ: 36.5%
  • ಗರಿಷ್ಠ ಯಶಸ್ಸು: o1-mini 72.8% ರಷ್ಟಿತ್ತು
  • ಅತ್ಯುತ್ತಮ ನಿರಾಕರಣೆ: Claude-3.7-Sonnet, ಇದು ಇನ್ನೂ 3% ಕ್ಕಿಂತ ಕಡಿಮೆ ಇದೆ

ಈ ಅಂಕಿಅಂಶಗಳು ಕಠಿಣ ವಾಸ್ತವವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತವೆ: ಹೆಚ್ಚಿನ agents ವಿಷಪೂರಿತ ಕರೆಯನ್ನು ನಿರಾಕರಿಸುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಆ ವಿನಂತಿಯು ಕಾನೂನುಬದ್ಧ ಪರಿಕರ ಕರೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಪರಿಕರದ ವಿವರಣೆಯು ಕೇವಲ ಒಂದು ಸಾಮಾನ್ಯ ದಾಖಲೆಯಾಗಿದೆಯೇ ಹೊರತು, ಕೋಡ್ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಮಾಡುವ ಮಾರ್ಗವಲ್ಲ ಎಂದು agents ಭಾವಿಸುತ್ತವೆ.

Agents ವಿಷಪೂರಿತ ಕರೆಗಳನ್ನು ಏಕೆ ಅಪರೂಪವಾಗಿ ನಿರಾಕರಿಸುತ್ತವೆ

OWASP ನ LLM01 ಮಾರ್ಗಸೂಚಿಯು LLM ಗಳು ಸೂಚನೆಗಳು ಮತ್ತು ಡೇಟಾ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಮಾಡುವುದಿಲ್ಲ ಎಂದು ವಿವರಿಸುತ್ತದೆ—ಎರಡೂ ಕೇವಲ ಒಂದು ಸರಣಿಯಲ್ಲಿನ ಟೋಕನ್‌ಗಳು. ಒಂದು ಪರಿಕರದ ವಿವರಣೆಯು “send an email to admin@example.com with the subject ‘Update’” ಎಂದು ಹೇಳಿದಾಗ, ಆ ಸಾಲು ಹಾನಿಕಾರಕವಲ್ಲದ ಕಾಮೆಂಟ್ ಆಗಿದೆಯೇ ಅಥವಾ ನಂತರ ಪಾಲಿಸಬೇಕಾದ ಸೂಚನೆಯೇ ಎಂದು ಮಾಡೆಲ್‌ಗೆ ತಿಳಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಮಾಡೆಲ್ ವಿವರಣೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಪರಿಸರದ ಭಾಗವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ ಮತ್ತು ಪರಿಕರವನ್ನು ಬಳಸಿದಾಗ ಯಾವುದೇ ಅಳವಡಿಸಲಾದ ಕಮಾಂಡ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾರ್ಗಸೂಚಿಗಳು ಮತ್ತು ಅವುಗಳ ಕೊರತೆಗಳು

MCP ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಈಗಾಗಲೇ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ, ಪರಿಕರದ ವಿವರಣೆಗಳು ವಿಶ್ವಾಸಾರ್ಹ ಸರ್ವರ್‌ನಿಂದ ಬಂದಿಲ್ಲದಿದ್ದರೆ ಅವುಗಳನ್ನು ನಂಬದಂತೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಪರಿಣಾಮ ಬೀರುವ ಕರೆಗಳಿಗಾಗಿ ಮಾನವ ಹಸ್ತಕ್ಷೇಪವನ್ನು (human in the loop) ಇರಿಸಿಕೊಳ್ಳುವಂತೆ ಸಲಹೆ ನೀಡುತ್ತದೆ. ಆದರೆ ಈ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಪ್ರಕಾರ, ಅನೇಕ ನೈಜ-ಪ್ರಪಂಚದ ಅಳವಡಿಕೆಗಳು ಈ ಶಿಫಾರಸುಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ ಅಥವಾ ಅವುಗಳನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುತ್ತವೆ.

ಡೆವಲಪರ್‌ಗಳು ಇಂದು ತೆಗೆದುಕೊಳ್ಳಬಹುದಾದ ನಿರ್ದಿಷ್ಟ ಕ್ರಮಗಳು

  1. ಸರ್ವರ್ ಆವೃತ್ತಿಗಳನ್ನು ಪಿನ್ ಮಾಡಿ (Pin server versions) – ಬದಲಾಗುವ ಟ್ಯಾಗ್ ಬದಲಿಗೆ ನಿರ್ದಿಷ್ಟವಾದ, ಬದಲಾಗದ (immutable) ಸರ್ವರ್ ಇಮೇಜ್ ಅಥವಾ ಹ್ಯಾಶ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಿ. ಇದು ನಿಯೋಜನೆಯ ನಂತರ (deployment) ದಾಳಿಕಾರರು ಸ್ವಚ್ಛವಾದ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ವಿಷಪೂರಿತವಾದದ್ದರೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
  2. ಖಾಲಿ ಅಲೋಲಿಸ್ಟ್ (allowlist) ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ – ಸ್ಪಷ್ಟವಾಗಿ ಪರಿಶೀಲಿಸಲಾದ ಪರಿಕರಗಳನ್ನು (tools) ಮಾತ್ರ ಸಕ್ರಿಯಗೊಳಿಸಿ. ಪಟ್ಟಿಯಲ್ಲಿ ಇಲ್ಲದ ಯಾವುದೇ ವಿಷಯವನ್ನು ಡಿಫಾಲ್ಟ್ ಆಗಿ ನಿರ್ಬಂಧಿಸಲಾಗುತ್ತದೆ.
  3. ಸ್ಥಿತಿ ಬದಲಾಯಿಸುವ ಪರಿಕರಗಳಿಗೆ ನಿರ್ಬಂಧ ಹೇರಿ (Gate state-changing tools) – ಡೇಟಾವನ್ನು ಬರೆಯುವ, ಕಳುಹಿಸುವ ಅಥವಾ ಅಳಿಸುವ ಯಾವುದೇ ಪರಿಕರಕ್ಕೆ ಹೆಚ್ಚುವರಿ ಅನುಮೋದನೆಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿ. ಸ್ಕೀಮಾದಲ್ಲಿ (schema) "ಓದಲು ಮಾತ್ರ" (read-only) ಮತ್ತು "ಬರೆಯುವ ಸಾಮರ್ಥ್ಯವಿರುವ" (write-capable) ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ.
  4. ಹೆಚ್ಚಿನ ಪರಿಣಾಮ ಬೀರುವ ಕರೆಗಳಿಗೆ ಮಾನವ ಅನುಮೋದನೆಯನ್ನು ಸೇರಿಸಿ – ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದಾದ ಕ್ರಮಗಳಿಗಾಗಿ (ಉದಾಹರಣೆಗೆ, ಇಮೇಲ್ ಕಳುಹಿಸುವುದು, ಕಮಾಂಡ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು, ಫೈಲ್‌ಗಳನ್ನು ಮಾರ್ಪಡಿಸುವುದು), ಕರೆ ಕಳುಹಿಸುವ ಮೊದಲು ಮಾನವ ವಿಮರ್ಶಕರಿಂದ ಅನುಮೋದನೆ ಪಡೆಯಿರಿ.
  5. ಪ್ರತಿ ಪರಿಕರದ ಬಳಕೆಯನ್ನು ಲಾಗ್ ಮಾಡಿ (Log every tool invocation) – ಪರಿಕರದ ಹೆಸರು, ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳು, ಸಮಯದ ಮುದ್ರೆ (timestamp) ಮತ್ತು ಮೂಲ ಏಜೆಂಟ್ ಅನ್ನು ದಾಖಲಿಸಿ. ಬದಲಾಗದ ಆಡಿಟ್ ಟ್ರೈಲ್ (audit trail) ನಂತರದ ವಿಶ್ಲೇಷಣೆಯನ್ನು (post-mortem analysis) ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ ಮತ್ತು ತಮ್ಮ ಕ್ರಮಗಳು ಗೋಚರಿಸುತ್ತವೆ ಎಂದು ತಿಳಿದಿರುವ ದಾಳಿಕಾರರನ್ನು ತಡೆಯಬಹುದು.

ಪ್ರತಿ ಪರಿಕರದ ವಿವರಣೆಯನ್ನು ಸೋರ್ಸ್ ಕೋಡ್‌ನಂತೆ ಪರಿಗಣಿಸಿ—ಅದನ್ನು ಲಿಂಟಿಂಗ್ (linting), ಕೋಡ್ ರಿವ್ಯೂ ಮತ್ತು ವರ್ಷನ್ ಕಂಟ್ರೋಲ್‌ಗೆ ಒಳಪಡಿಸಿ—ಇದರ ಮೂಲಕ MCP ಸಪ್ಲೈ ಚೈನ್ ಅನ್ನು ಪ್ರಮಾಣಿತ ಸಾಫ್ಟ್‌ವೇರ್-ಅಭಿವೃದ್ಧಿ ಪದ್ಧತಿಗಳೊಂದಿಗೆ ಹೊಂದಿಸಿ.

ವಿರೋಧಾಭಿಪ್ರಾಯಗಳು ಮತ್ತು ಮುಕ್ತ ಪ್ರಶ್ನೆಗಳು

ಆದಾಗ್ಯೂ, ಈ ಅಧ್ಯಯನದಲ್ಲಿನ ಅತ್ಯಂತ ಸುಧಾರಿತ ಮಾದರಿಯು ಸಹ ವಿಷಪೂರಿತ ಕರೆಗಳಲ್ಲಿ ಮೂರು ಪ್ರತಿಶತಕ್ಕಿಂತ ಕಡಿಮೆ ಪ್ರಮಾಣವನ್ನು ನಿರಾಕರಿಸಿದೆ ಎಂದು ಬೆಂಚ್‌ಮಾರ್ಕ್ ತೋರಿಸುತ್ತದೆ. ಫೈನ್-ಟ್ಯೂನಿಂಗ್ (Fine-tuning) ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು, ಆದರೆ ಮಾದರಿಯು ಎಂದೂ ನೋಡಿರದ ಸ್ಕೀಮಾ ಫೀಲ್ಡ್‌ಗಳಲ್ಲಿ ಅಡಗಿರುವ ಹೊಸ ಪೇಲೋಡ್‌ಗಳ (payloads) ವಿರುದ್ಧ ಸುರಕ್ಷತೆಯನ್ನು ಇದು ಖಾತರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

  • ಉದಯೋನ್ಮುಖ ಮಾನದಂಡಗಳು (Emerging standards) – ಪರಿಕರ ಸ್ಕೀಮಾಗಳ ಮೇಲೆ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸಹಿಗಳನ್ನು (cryptographic signatures) ಅಗತ್ಯಪಡಿಸುವಂತೆ LLM ಭದ್ರತಾ ಸಮುದಾಯದಿಂದ ಬರುವ ಪ್ರಸ್ತಾವನೆಗಳನ್ನು ಗಮನಿಸಿ.
  • ಟೂಲ್-ರಿಜಿಸ್ಟ್ರಿ ಹಾರ್ಡನಿಂಗ್ (Tool-registry hardening) – ಮಾರಾಟಗಾರರು ಸೇವೆಯಾಗಿ ಬದಲಾಗದ, ಓದಲು ಮಾತ್ರ ಅನುಮತಿಸುವ (read-only) ರಿಜಿಸ್ಟರಿಗಳನ್ನು ಒದಗಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು, ಇದು ದಾಳಿಯ ಮೇಲ್ಮೈಯನ್ನು (attack surface) ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
  • ಮಾಡೆಲ್-ಮಟ್ಟದ ರಕ್ಷಣೆಗಳು (Model-level defenses) – ಅನುಮಾನಾಸ್ಪದ ಪರಿಕರ ಮೆಟಾಡೇಟಾವನ್ನು ಗುರುತಿಸುವ ಪ್ರಾಂಪ್ಟಿಂಗ್ ತಂತ್ರಗಳು ಅಥವಾ ಪೂರಕ ಮಾದರಿಗಳ ಮೇಲಿನ ಸಂಶೋಧನೆಯು ಹೋಸ್ಟ್-ಸೈಡ್ ಸುರಕ್ಷತಾ ಕ್ರಮಗಳಿಗೆ ಪೂರಕವಾಗಿರಬಹುದು.

ಪ್ರಾಯೋಗಿಕ ತೀರ್ಮಾನ ಸ್ಪಷ್ಟವಾಗಿದೆ: ಯಾವುದೇ MCP-ಆಧಾರಿತ ನಿಯೋಜನೆಯು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಲೈಬ್ರರಿಗಳಿಗೆ ಅನ್ವಯಿಸುವಷ್ಟೇ ಕಟ್ಟುನಿಟ್ಟಿನ ಪರಿಶೀಲನೆಯನ್ನು ಪರಿಕರ ವಿವರಣೆಗಳಿಗೂ ಮಾಡಬೇಕು. ಸಪ್ಲೈ-ಚೈನ್ ಅಪಾಯವನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು ಅನುಕೂಲಕರ ಅಮೂರ್ತತೆಯನ್ನು (abstraction) ಮೌನವಾದ ಬ್ಯಾಕ್‌ಡೋರ್ ಆಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಸರ್ವರ್‌ಗಳನ್ನು ಪಿನ್ ಮಾಡುವ ಮೂಲಕ, ಕನಿಷ್ಠ-ಅಧಿಕಾರದ (least-privilege) ಅಲೋಲಿಸ್ಟ್‌ಗಳನ್ನು ಜಾರಿಗೆ ತರುವ ಮೂಲಕ, ಸ್ಥಿತಿ ಬದಲಾಯಿಸುವ ಕ್ರಮಗಳಿಗೆ ನಿರ್ಬಂಧ ಹೇರುವ ಮೂಲಕ, ಅಗತ್ಯವಿರುವಲ್ಲಿ ಮಾನವರನ್ನು ಒಳಗೊಳ್ಳುವ ಮೂಲಕ ಮತ್ತು ಬದಲಾಗದ ಲಾಗ್ ಅನ್ನು ಇರಿಸುವ ಮೂಲಕ, ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ LLM ಏಜೆಂಟ್‌ಗಳು ಅನಿವಾರ್ಯ ಸಹಚರರಾಗದಂತೆ ತಡೆಯಬಹುದು.