ನಾನು ನನ್ನ ಕುಟುಂಬದ ಹಣಕಾಸಿನ ವ್ಯವಹಾರಗಳಿಗೆ ಒಂದು AI ಏಜೆಂಟ್ಗೆ ಪ್ರವೇಶ ನೀಡಿದೆ ಮತ್ತು MCP ಸರ್ವರ್ ಮೂಲಕ ಅದು ನನ್ನೊಂದಿಗೆ ಮಾತನಾಡಲು ಬಿಟ್ಟೆ. ಕೆಲವೇ ನಿಮಿಷಗಳಲ್ಲಿ ಅದು "ಕಳೆದ ತಿಂಗಳು ನಾವು ದಿನಸಿಗಾಗಿ ಎಷ್ಟು ಖರ್ಚು ಮಾಡಿದ್ದೇವೆ?" ಎಂದು ಉತ್ತರಿಸಬಲ್ಲទៅತು ಮತ್ತು ಉಳಿತಾಯ ಖಾತೆಗೆ ಹಣವನ್ನು ವರ್ಗಾಯಿಸಬಲ್ಲទៅತು. ಅದೇ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಕೇವಲ ಒಂದು ಕಮಾಂಡ್ ಮೂಲಕ ಒಂದು ವರ್ಷದ ವಹಿವಾಟಿನ ಇತಿಹಾಸವನ್ನೇ ಅಳಿಸಿಹಾಕಲು ಅದಕ್ಕೆ ಸಾಧ್ಯವಿತ್ತು. ಏಜೆಂಟ್ ಬಳಸಬಹುದಾದ ಟೂಲ್ಗಳಲ್ಲಿನ ಹಾರ್ಡ್-ಕೋಡೆಡ್ (hard-coded) ಸುರಕ್ಷತಾ ತಪಾಸಣೆಯು ಆ ಅಳಿಸುವಿಕೆಯನ್ನು ತಡೆಯಿತು—ಅದು ಯಾವುದೇ ಚತುರ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಆಗಿರಲಿಲ್ಲ.
ಈ ಸಮಸ್ಯೆ ಏಕೆ ಮುಖ್ಯ
ಬಾಹ್ಯ ಸೇವೆಗಳನ್ನು ಬಳಸುವ AI ಏಜೆಂಟ್ಗಳು ಸಂಶೋಧನಾ ಪ್ರದರ್ಶನಗಳಿಂದ (research demos) ದೈನಂದಿನ ಸಹಾಯಕರಾಗಿ ಬದಲಾಗುತ್ತಿವೆ. ಬ್ಯಾಂಕ್-SMS ಅಲರ್ಟ್ಗಳನ್ನು ಓದುವ, ಮೊತ್ತವನ್ನು ವಿಶ್ಲೇಷಿಸುವ ಮತ್ತು ಅವುಗಳನ್ನು ವೈಯಕ್ತಿಕ ಹಣಕಾಸು ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ದಾಖಲಿಸುವ ಬಜೆಟಿಂಗ್ ಬಾಟ್ ಇಂದು ಲಭ್ಯವಿದೆ. ಇದೇ ಮಾದರಿಯು ಗ್ರಾಹಕ-ಸಹಾಯ ಚಾಟ್ಬಾಟ್ಗಳು, ಕೋಡ್-ಜನರೇಷನ್ ನೆರவாளರು ಮತ್ತು ಸಪ್ಲೈ-ಚೈನ್ ಪ್ಲಾನರ್ಗಳಿಗೆ ಶಕ್ತಿಯನ್ನು ನೀಡುತ್ತಿದೆ. ಒಮ್ಮೆ ಏಜೆಂಟ್ ಬದಲಾವಣೆ ಮಾಡುವ (mutating) ಅಥವಾ ವಿನಾಶಕಾರಿ (destructive) ಕಮಾಂಡ್ಗಳನ್ನು ನೀಡಲು ಸಾಧ್ಯವಾದರೆ—ಉದಾಹರಣೆಗೆ ಫೈಲ್ ಅಳಿಸುವುದು, ಡೇಟಾಬೇಸ್ ಟೇಬಲ್ ಡ್ರಾಪ್ ಮಾಡುವುದು ಅಥವಾ ಹಣವನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡುವುದು—ಅದರ ಅಪಾಯಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ. ಒಂದು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿದ ವಿನಂತಿ, ಮಾಡೆಲ್-ಡ್ರಿಫ್ಟ್ (model-drift) ಘಟನೆ ಅಥವಾ ದುರುದ್ದೇಶಪೂರಿತ ಪ್ರಾಂಪ್ಟ್ವು ತಿರುಗಿ ಬಾರದ ಹಾನಿಯನ್ನು ಉಂಟುಮಾಡಬಹುದು. 2025 ರಲ್ಲಿ, ಒಂದು AI ಕೋಡಿಂಗ್ ಅಸಿಸ್ಟೆಂಟ್ಗೆ ವಿನಾಶಕಾರಿ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಎಂದಿಗೂ ಮಾಡಬೇಡಿ ಎಂದು ಹೇಳಿದ್ದರೂ ಸಹ, ಅದು ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಳಿಸಿಹಾಕಿತು, ಇದರಿಂದ ಕಂಪನಿಗೆ ವಾರಗಟ್ಟಲೆ ಕೆಲಸ ಸ್ಥಗಿತಗೊಂಡಿತು.
ಅಪಾಯವು ನೈಜವಾಗಿದೆ. ಬಳಕೆದಾರರು ತಮ್ಮ ಸೂಕ್ಷ್ಮ ಡೇಟಾ ಮತ್ತು ನಿರ್ಣಾಯಕ ಕೆಲಸಗಳಿಗಾಗಿ AI ಏಜೆಂಟ್ಗಳನ್ನು ನಂಬುತ್ತಾರೆ. ಆ ನಂಬಿಕೆ ಮುರಿದಾಗ, ತಂತ್ರಜ್ಞಾನದ ಅಳವಡಿಕೆ ನಿಧಾನವಾಗುತ್ತದೆ, ನಿಯಂತ್ರಕರು ಮಧ್ಯಪ್ರವೇಶಿಸಬಹುದು ಮತ್ತು ಆರ್ಥಿಕ ಪರಿಣಾಮವು ತೀವ್ರವಾಗಿರಬಹುದು. ಮೂಲ ಪ್ರಶ್ನೆಯೆಂದರೆ: ಒಬ್ಬ ಮನುಷ್ಯನ ನಿರ್ಧಾರವಿಲ್ಲದೆ ಏಜೆಂಟ್ ಎಂದಿಗೂ ತಿರುಗಿ ಬಾರದ ಕ್ರಿಯೆಯನ್ನು ಮಾಡುವುದಿಲ್ಲ ಎಂದು ನಾವು ಹೇಗೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು?
ಪ್ರಾಂಪ್ಟ್ ಇಂಜಿನಿಯರಿಂಗ್ ಒಂದು ಸುಳ್ಳು ಭದ್ರತಾ ಕವಚ
ಡೆವಲಪರ್ಗಳು ಹೆಚ್ಚಾಗಿ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಬಿಗಿಗೊಳಿಸುತ್ತಾರೆ, "ಕೇಳದೆ ಎಂದಿಗೂ ಡೇಟಾವನ್ನು ಅಳಿಸಬೇಡಿ" ಅಥವಾ "ಬ್ಯಾಲೆನ್ಸ್ ಬದಲಾಯಿಸುವ ಮೊದಲು ಯಾವಾಗಲೂ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ" ಎಂಬ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುತ್ತಾರೆ. ಪ್ರಾಂಪ್ಟ್ ಇಂಜಿನಿಯರಿಂಗ್ ಮಾಡೆಲ್ನ ನಡವಳಿಕೆಯನ್ನು ಮಾಡೆಲ್ ಅನುಸರಿಸಬಹುದು ಅಥವಾ ಅನುಸರಿಸದಿರಬಹುದು ಎಂಬ ಸಲಹೆಗಳ ಗುಂಪಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಟೆಂಪರೇಚರ್ ಸೆಟ್ಟಿಂಗ್ಗಳು, ಟೋಕನ್ ಮಿತಿಗಳು ಅಥವಾ ಸಣ್ಣ ಸಂದರ್ಭದ ಬದಲಾವಣೆಯಿಂದಾಗಿ ಮಾಡೆಲ್ ನಿಯಮವನ್ನು ಬಿಟ್ಟುಹೋಗುವವರೆಗೆ ಅದು ಪದಗಳ ಅರ್ಥವನ್ನು ಪಾಲಿಸುತ್ತದೆ. ಮಾಡೆಲ್ನ ಆಂತರಿಕ ತರ್ಕವು ವಿಭಿನ್ನವಾದಾಗ ಸ್ಪಷ್ಟವಾದ ಸೂಚನೆಯನ್ನೂ ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಎಂಬುದನ್ನು 2025 ರ ಡೇಟಾಬೇಸ್ ಅಳಿಸುವ ಘಟನೆಯು ಸಾಬೀತುಪಡಿಸಿತು.
ಪಠ್ಯದ ಮಟ್ಟದ ನಿರ್ಬಂಧಗಳು ನಿರ್ವಹಣೆಯ ತಲೆನೋವನ್ನೂ ಉಂಟುಮಾಡುತ್ತವೆ. ಪ್ರತಿಯೊಂದು ಹೊಸ ಟೂಲ್, ವರ್ಷದ ಅಪ್ಡೇಟ್ ಅಥವಾ ಭಾಷಾ-ಮಾಡೆಲ್ ಬದಲಾವಣೆಯು ಪ್ರಾಂಪ್ಟ್ ಪಠ್ಯದ ಹೊಸ ಆಡಿಟ್ ಅನ್ನು ಬಯಸುತ್ತದೆ. ಮಾನವ ವಿಮರ್ಶಕರು ಉದ್ದವಾದ ನೈಸರ್ಗಿಕ ಭಾಷೆಯ ಬ್ಲಾಕ್ಗಳನ್ನು ಓದಬೇಕು, ಅವುಗಳನ್ನು ಅರ್ಥೈಸಿಕೊಳ್ಳಬೇಕು ಮತ್ತು ಮಾಡೆಲ್ ಅವುಗಳನ್ನು ಗೌರವಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಬೇಕು. ಇದರ ಪರಿಣಾಮವಾಗಿ ನೈಜ ಪ್ರಪಂಚದ ಬಳಕೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಮುರಿದು ಬೀಳುವಂತಹ ಒಂದು ದುರ್ಬಲ ಸುರಕ್ಷತಾ ಜಾಲ ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ.
ಸುರಕ್ಷತೆಯನ್ನು ಪ್ರಾಂಪ್ಟ್ನಿಂದ ಟೂಲ್ಗೆ ವರ್ಗಾಯಿಸುವುದು
ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹ ವಿಧಾನವೆಂದರೆ AI ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಜಾಗದಲ್ಲಿ ಅಂದರೆ ಟೂಲ್ನಲ್ಲಿಯೇ ಸುರಕ್ಷತೆಯನ್ನು ಜಾರಿ ಮಾಡುವುದು. ನನ್ನ ಪ್ರಯೋಗದಲ್ಲಿ ನಾನು Lester ಎಂಬ ಹೆಸರಿನ ಬಜೆಟಿಂಗ್ ಏಜೆಂಟ್ ಅನ್ನು ನಿರ್ಮಿಸಿದೆ. ಅದರ ಕಾರ್ಯವಿಧಾನ ಹೀಗಿತ್ತು:
- ಫೋನ್ ಅಪ್ಲಿಕೇಶನ್ ಬ್ಯಾಂಕ್ನಿಂದ ಬರುವ SMS ಸಂದೇಶಗಳನ್ನು ಸೆರೆಹಿಡಿಯುತ್ತದೆ.
- ಲಘುವಾದ, ಸ್ಥಳೀಯವಾಗಿ ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಭಾಷಾ ಮಾಡೆಲ್ ವಹಿವಾಟಿನ ಮೊತ್ತ ಮತ್ತು ಮರ್ಚೆಂಟ್ ಹೆಸರನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ.
- Lester ಒಂದು API ಕರೆಯನ್ನು ಮಾಡುವ ಮೂಲಕ ವಿಶ್ಲೇಷಿಸಿದ ದಾಖಲೆಯನ್ನು ಬಜೆಟಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಬರೆಯುತ್ತದೆ.
Lester ನ ದೃಷ್ಟಿಕೋನದಿಂದ ಈ ಮೂರೂ ಹಂತಗಳು ಕೇವಲ ಓದುವಿಕೆ (read-only) ಮಾತ್ರವಾಗಿದ್ದವು: ಅದು ಕೇವಲ ಡೇಟಾವನ್ನು ಸೇರಿಸಬಲ್ಲದು, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ದಾಖಲೆಗಳನ್ನು ಎಂದಿಗೂ ಅಳಿಸಲು ಅಥವಾ ಮಾರ್ಪಡಿಸಲು ಸಾಧ್ಯವಿರಲಿಲ್ಲ. ನಾನು MCP (Multi-Channel Prompt) ಸರ್ವರ್ ಬಳಸಿ ವಾಯ್ಸ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಸೇರಿಸುವವರೆಗೆ ಈ ವ್ಯವಸ್ಥೆಯು ದೋಷರಹಿತವಾಗಿ ಕೆಲಸ ಮಾಡಿತು. ಇದು ನನಗೆ "ಕಳೆದ ತಿಂಗಳು ನಾವು ದಿನಸಿಗಾಗಿ ಎಷ್ಟು ಖರ್ಚು ಮಾಡಿದ್ದೇವೆ?" ಅಥವಾ "ಹಣವನ್ನು ಉಳಿತಾಯಕ್ಕೆ ವರ್ಗಾಯಿಸಿ" ಎಂದು ಕೇಳಲು ಅವಕಾಶ ನೀಡಿತು. MCP ಸರ್ವರ್ ಒಬ್ಬ ಮಧ್ಯಸ್ಥಗಾರನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಏಜೆಂಟ್ಗೆ ಒಂದು ಗುಂಪಿನ ಟೂಲ್ಗಳನ್ನು (add-transaction, query-spending, transfer-funds, delete-history) ಒದಗಿಸುತ್ತದೆ.
ಮೂಲ ಕಾನ್ಫಿಗರೇಶನ್ನಲ್ಲಿ ಪ್ರತಿಯೊಂದು ಟೂಲ್ ಅನ್ನು ಸಮಾನವಾಗಿ ಪರಿಗಣಿಸಲಾಗಿತ್ತು. ದಿನಸಿ ವಹಿವಾಟನ್ನು ಸೇರಿಸುವ ಅದೇ ಎಂಡ್ಪಾಯಿಂಟ್, ಒಂದು ವರ್ಷದ ದಾಖಲೆಗಳನ್ನೇ ಅಳಿಸಬಲ್ಲ ಡಿಲೀಟ್ ಕಮಾಂಡ್ ಅನ್ನು ಸಹ ಸ್ವೀಕರಿಸುತ್ತಿತ್ತು. ಮಾಡೆಲ್ ತಪ್ಪಾದ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಂಡರೆ ಅಥವಾ ಬಳಕೆದಾರರು "delete last" ಬದಲಿಗೆ "delete all" ಎಂದು ಟೈಪ್ ಮಾಡಿದರೆ, Lester ಯಾವುದೇ ಹಿಂಜರಿಕೆ ಇಲ್ಲದೆ ಅದನ್ನು ಪಾಲಿಸುತ್ತಿತ್ತು.
ಅದನ್ನು ತಡೆಯಲು, ನಾನು ಮೂರು ಸರಳ ನಿಯಮಗಳೊಂದಿಗೆ ಟೂಲ್ ಲೇಯರ್ ಅನ್ನು ಮರು-ರಚಿಸಿದೆ:
- ಓದುವಿಕೆ ಮಾತ್ರ ಇರುವ ಟೂಲ್ಗಳು ತಕ್ಷಣವೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಕೇವಲ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುವ ಯಾವುದೇ ವಿಷಯ—ಬ್ಯಾಲೆನ್ಸ್ ಪರಿಶೀಲನೆ, ಖರ್ಚಿನ ಸಾರಾಂಶ, ವಹಿವಾಟಿನ ವಿಚಾರಣೆ—ಮಾನವನ ದೃಢೀಕರಣದ ಅಗತ್ಯವಿಲ್ಲ. ಓದುವಿಕೆ ಮಾತ್ರ ಇರುವ ಕರೆಯನ್ನು ಮಾಡುವ ಅಪಾಯವು ಅತ್ಯಲ್ಪವಾಗಿದೆ.
- ಬದಲಾವಣೆ ಮಾಡುವ ಟೂಲ್ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೊದಲು ಉದ್ದೇಶವನ್ನು ತಿಳಿಸುತ್ತವೆ. ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವ ಆದರೆ ಹಿಂಪಡೆಯಬಹುದಾದ ಕಾರ್ಯಾಚರಣೆಗಳು—ವಹಿವಾಟನ್ನು ಸೇರಿಸುವುದು, ವರ್ಗವನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುವುದು—ಏಜೆಂಟ್ ಒಂದು ಸಣ್ಣ "ಉದ್ದೇಶದ" ಸಂದೇಶವನ್ನು (ಉದಾಹರಣೆಗೆ, "ದಿನಸಿ ವಹಿವಾಟನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ") ಕಳುಹಿಸಿದ ನಂತರ ಮುಂದುವರಿಯುತ್ತವೆ. ಸಿಸ್ಟಮ್ ಆ ಉದ್ದೇಶವನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಆಡಿಟ್ ಮಾಡಲು ಬಳಕೆದಾರರಿಗೆ ತೋರಿಸಬಹುದು, ಆದರೆ ಇದು ಕಾರ್ಯನಿರ್ವಹಣೆಯನ್ನು ತಡೆಯುವುದಿಲ್ಲ.
- ವಿನಾಶಕಾರಿ ಟೂಲ್ಗಳು ಸ್ಪಷ್ಟವಾದ ಟೋಕನ್ ಇಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ನಿರಾಕರಿಸುತ್ತವೆ. ಡೇಟಾವನ್ನು ಅಳಿಸುವ ಅಥವಾ ಮರಳಿ ಪಡೆಯಲಾಗದಂತೆ ಮಾಡುವ ಕಮಾಂಡ್ಗಳನ್ನು ಟೂಲ್ ಮಟ್ಟದಲ್ಲಿ ತಡೆಯಲಾಗುತ್ತದೆ. Lester ಡಿಲೀಟ್ ವಿನಂತಿಯನ್ನು ನೀಡಿದಾಗ, ಟೂಲ್ ಯಾವ ಡೇಟಾವನ್ನು ಅಳಿಸುತ್ತದೆ ಎಂಬ ನಿಖರ ಮಾಹಿತಿ ಮತ್ತು ಮಾನವ ನಿರ್ಮಿತ ಟೋಕನ್ಗಾಗಿ ವಿನಂತಿಯನ್ನು ಒಳಗೊಂಡಿರುವ ತಿರಸ್ಕಾರದ ಪೇಲೋಡ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ನಂತರ
confirm: trueಮತ್ತು ಟೋಕನ್ ಅನ್ನು ಒಳಗೊಂಡ ಎರಡನೇ ಹಂತದ ದೃಢೀಕರಣ ಪೇಲೋಡ್ ಅನ್ನು ಒದಗಿಸಬೇಕು. ಅದು ಇಲ್ಲದಿದ್ದರೆ, ಕಾರ್ಯಾಚರಣೆಯು ರದ್ದಾಗುತ್ತದೆ.
ಈ ವಿನ್ಯಾಸವು ಸುರಕ್ಷತಾ ತಪಾಸಣೆಯನ್ನು ಅಟಾಮಿಕ್ (atomic) ಮಾಡುತ್ತದೆ: ಮಾಡೆಲ್ ತನ್ನ ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿ ಏನೇ ಹೇಳಿದರೂ, ಮುಂದುವರಿಯಬಹುದೇ ಎಂಬುದನ್ನು ಟೂಲ್ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ನಿರ್ಧರಿಸುತ್ತದೆ. ಮಾಡೆಲ್ ಟೋಕನ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡುವ ಮೂಲಕ ಅಥವಾ ತಪ್ಪಾದ ಪೇಲೋಡ್ ಒದಗಿಸುವ ಮೂಲಕ ಈ ತಪಾಸಣೆಯನ್ನು ತಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೂ, ಟೂಲ್ ವಿನಂತಿಯನ್ನು ನೇರವಾಗಿ ತಿರಸ್ಕರಿಸುತ್ತದೆ.
ಇದು ಬಳಕೆದಾರರಿಗೆ ಏಕೆ ಮುಖ್ಯ
ಯಾವುದೇ ದೃಢೀಕರಣ ವ್ಯವಸ್ಥೆಗೆ ದೊಡ್ಡ ಅಡ್ಡಿಯೆಂದರೆ ಸುಸ್ತು (fatigue). ಒಂದು ವ್ಯವಸ್ಥೆಯು ಪ್ರತಿಯೊಂದು ಸಣ್ಣ ಕ್ರಿಯೆಗೂ ಅನುಮೋದನೆಯನ್ನು ಕೇಳಿದರೆ—“ನೀವು ಈ ಕಾಫಿಯನ್ನು ಸೇರಿಸಲು ಬಯಸುವಿರಾ?”—ಬಳಕೆದಾರರು ಓದದೆ ತಕ್ಷಣವೇ "ಹೌದು" ಎಂದು ಕ್ಲಿಕ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಇದರ ಪರಿಣಾಮವು ಸುಳ್ಳು ಭದ್ರತಾ ಭಾವನೆಯನ್ನು ನೀಡುತ್ತದೆ. ಕೇವಲ ತಿರುಗಿ ಬಾರದ ಕ್ರಿಯೆಗಳಿಗೆ ಮಾತ್ರ ಮಿತಿ ಹೇರುವ ಮೂಲಕ, ನಾವು ಮನುಷ್ಯನ ಪಾತ್ರವನ್ನು ಅಗತ್ಯವಿರುವ ಕಡೆ ಮಾತ್ರ ಇರಿಸುತ್ತೇವೆ. ಕೇವಲ ಒಂದು ಸಾಲನ್ನು ಸೇರಿಸುವ ವಿನಂತಿಗಿಂತ, ಇಡೀ ತಿಂಗಳ ಹಣಕಾಸಿನ ಇತಿಹಾಸವನ್ನು ಅಳಿಸಬಲ್ಲ ವಿನಂತಿಯನ್ನು ಬಳಕೆದಾರರು ಪರಿಶೀಲಿಸುವ ಸಾಧ್ಯತೆ ಹೆಚ್ಚು.
ಟೂಲ್-ಮಟ್ಟದ ಸುರಕ್ಷತೆಯು ಅನುಸರಣೆಯನ್ನು (compliance) ಸುಲಭಗೊಳಿಸುತ್ತದೆ. EU AI Act ಅಥವಾ U.S. SAFE Act ನಂತಹ ನಿಯಮಗಳು ಅನಿರೀಕ್ಷಿತ ಡೇಟಾ ನಷ್ಟದ ವಿರುದ್ಧ ಪ್ರದರ್ಶನೀಯ ರಕ್ಷಣಾ ಕ್ರಮಗಳನ್ನು ಬಯಸುತ್ತವೆ. API ಯಲ್ಲಿನ ಹಾರ್ಡ್-ಕೋಡೆಡ್ ನಿರಾಕರಣೆಯು ಲಾಗ್ ಮಾಡಬಹುದಾದ, ಪರಿಶೀಲಿಸಬಹುದಾದ ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಆಡಿಟರ್ಗಳಿಂದ ದೃಢೀಕರಿಸಬಹುದಾದ ನಿಯಂತ್ರಣವಾಗಿದೆ. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, ಪ್ರಾಂಪ್ಟ್ ಪಠ್ಯವು ಅಸ್ಪಷ್ಟವಾಗಿರುತ್ತದೆ, ಆವೃತ್ತಿಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ನ್ಯಾಯಾಲಯದಲ್ಲಿ ಸಾಬೀತುಪಡಿಸುವುದು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ.
ವಿರೋಧಾತ್ಮಕ ವಾದ: "ನಾವು ಕೇವಲ ಪ್ರಾಂಪ್ಟ್ಗಳನ್ನು ಸುಧಾರಿಸಲೇ არა?"
ಕೆಲವು ಡೆವಲಪರ್ಗಳು ಉತ್ತಮವಾಗಿ ರೂಪಿಸಿದ ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು RLHF (reinforcement learning from human feedback) ಅನ್ನು ಬಳಸಿದರೆ ಅದೇ ಮಟ್ಟದ ಸುರಕ್ಷತೆಯನ್ನು ಸಾಧಿಸಬಹುದು ಎಂದು ವಾದಿಸುತ್ತಾರೆ. ಸ್ಪಷ್ಟ ನಿರ್ಬಂಧಗಳನ್ನು ಅಪರೂಪಕ್ಕೆ ಉಲ್ಲಂಘಿಸುವ ಇನ್ಸ್ಟ್ರಕ್ಷನ್-ಟ್ಯೂನ್ ಮಾಡಲಾದ ಮಾಡೆಲ್ಗಳನ್ನು ಅವರು ಉಲ್ಲೇಖಿಸುತ್ತಾರೆ. ಈ ವಾದವು ಮಾನ್ಯವಾಗಿದೆ: ಉತ್ತಮ ಮಾಡೆಲ್ಗಳು ಅಕಸ್ಮಾತ್ ಅಳಿಸುವಿಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತವೆ.
ಆದರೆ, ಅತ್ಯಂತ ಸಮರ್ಥ ಮಾಡೆಲ್ಗಳು ಕೂಡ ಸಂಭವನೀಯತೆಯ (probabilistic) ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಒಂದು ಹೊರಗಿನ ಟೋಕನ್, ಟೆಂಪರೇಚರ್ನಲ್ಲಿನ ಬದಲಾವಣೆ ಅಥವಾ ಅಪರೂಪದ ಸಂದರ್ಭದ ಸಂಯೋಜನೆಯು ಮಾಡೆಲ್ ಅನಿರೀಕ್ಷಿತ ಕಮಾಂಡ್ ನೀಡುವಂತೆ ಮಾಡಬಹುದು. ಸಾಂಖ್ಯಿಕ ಗುಣಲಕ್ಷಣದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಸುರಕ್ಷತೆಯು ಸಹಜವಾಗಿಯೇ ದುರ್ಬಲವಾಗಿರುತ್ತದೆ. ಬ್ಯಾಂಕಿಂಗ್, ಆರೋಗ್ಯ ರಕ್ಷಣೆ, ನಿರ್ಣಾಯಕ ಮೂಲಸೌಕರ್ಯಗಳಂತಹ ಹೆಚ್ಚಿನ ಮೌಲ್ಯದ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ, ಒಂದು ಸಣ್ಣ ತಪ್ಪೂ ಭೀಕರ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಪ್ರತಿ ವಿನಾಶಕಾರಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ರಕ್ಷಣಾತ್ಮಕ ಕವಚದಲ್ಲಿ ಸುತ್ತುವರಿಯಲು ಬೇಕಾಗುವ ಎಂಜಿನಿಯರಿಂಗ್ ಪ್ರಯತ್ನಕ್ಕಿಂತ, ಉಲ್ಲಂಘನೆಯಿಂದ ಉಂಟಾಗುವ ವೆಚ್ಚವು ಬಹಳ ದೊಡ್ಡದಾಗಿರುತ್ತದೆ.
ಪ್ರಾಂಪ್ಟ್-ಮಾತ್ರದ ಪರಿಹಾರಗಳು ದುರುದ್ದೇಶಪೂರಿತ ಉದ್ದೇಶಗಳನ್ನು (malicious intent) ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ. ಏಜೆಂಟ್ನ ಪ್ರಾಂಪ್ಟ್ಗೆ ಪ್ರವೇಶ ಪಡೆಯುವ ದಾಳಿಕೋರನು ಸುರಕ್ಷತಾ ನಿಯಮವನ್ನು ಬಿಟ್ಟುಹೋಗುವ ಕಮಾಂಡ್ ಅನ್ನು ಸೇರಿಸಬಹುದು. ಟೂಲ್-ಮಟ್ಟದ ಜಾರಿ ಮಾಡತಿಯು ಸುರಕ್ಷಿತವಾಗಿದೆ ಏಕೆಂದರೆ ಅದರ ಗೇಟ್ ಮಾಡೆಲ್ನ ಸಂದರ್ಭದ ಹೊರಗೆ ಇರುತ್ತದೆ.
ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು
ಸಮುದಾಯವು ಈಗ ಟೂಲ್-ಮ ಮಟ್ಟದ ಸುರಕ್ಷತೆಯನ್ನು ಪ್ರಮುಖ ವಿಷಯವಾಗಿ ಪರಿಗಣಿಸಲು ಪ್ರಾರಂಭಿಸಿದೆ. ಹಲವಾರು ಓಪನ್-ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಈಗ ಮಾನವ ಟೋಕನ್ ಇಲ್ಲದ ವಿನಾಶಕಾರಿ ಕರೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತಿರಸ್ಕರಿಸುವ "ಸುರಕ್ಷಿತ API"ಗಳನ್ನು ಒದಗಿಸುತ್ತಿವೆ. ಸ್ಟ್ಯಾಂಡರ್ಡ್ಸ್ ಬಾಡಿಗಳು ಆಕ್ಷನ್-ಲೆವೆಲ್ ಒಪ್ಪಿಗೆಗಾಗಿ (action-level consent) ವಿಶೇಷತೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತಿವೆ, ಅಲ್ಲಿ ಪ್ರತಿಯೊಂದು API ಕರೆಯು ಆಡಿಟ್ ಮಾಡಬಹುದಾದ ಸಹಿ ಮಾಡಿದ ಉದ್ದೇಶದ ಪೇಲೋಡ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.
ತಮ್ಮ ಆಂತರಿಕ ಸೇವೆಗಳನ್ನು ಈಗಾಗಲೇ AI ಏಜೆಂಟ್ಗಳಿಗೆ ನೀಡುತ್ತಿರುವ ಉದ್ಯಮಗಳು ತಮ್ಮ APIಗಳನ್ನು ಈ ಮೂರು ವಿಷಯಗಳಿಗಾಗಿ ಪರಿಶೀಲಿಸಬೇಕು:
- Idempotency – ಎಂಡ್ಪಾಯಿಂಟ್ ಯಾವುದೇ ಪಾರ್ಶ್ವ ಪರಿಣಾಮಗಳಿಲ್ಲದೆ ಪುನರಾವರ್ತಿತ ಕರೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆಯೇ? ಇಲ್ಲದಿದ್ದರೆ, ದೃಢೀಕರಣ ಪದರವನ್ನು ಸೇರಿಸಿ.
- Explicit intent fields – ಬದಲಾವಣೆ ಮಾಡುವ ವಿನಂತಿಯ ಉದ್ದೇಶವನ್ನು ತಿಳಿಸಲು ಕರೆಯನ್ನು ಮಾಡುವವರಿಗೆ ಕಡ್ಡಾಯಗೊಳಿಸಿ.
- Human-in-the-loop tokens – ಯಾವುದೇ ವಿನಾಶಕಾರಿ ಕರೆಯೊಂದಿಗೆ ಇರಲೇಬೇಕಾದ ಅಲ್ಪಾವಧಿಯ, ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕली ಸಹಿ ಮಾಡಿದ ಟೋಕನ್ಗಳನ್ನು ರಚಿಸಿ.
MCP ಸರ್ವರ್ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿರುವ ಡೆವಲಪರ್ಗಳು ಈ ತಪಾಸಣೆಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಲೇಯರ್ಗೆ ಸೇರಿಸಬಹುದು, ಇದರಿಂದ ಸರ್ವರ್ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಸುರಕ್ಷತಾ ಗೇಟ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದೇ ಮಾದರಿಯು ವೆಬ್ಹುಕ್ ಆಧಾರಿತ ಬಾಟ್ಗಳು, ಸರ್ವರ್ಲೆಸ್ ಫಂಕ್ಷನ್ ಕರೆಗಳು ಮತ್ತು AI ಏ