ನಿಮ್ಮ AI-ಚಾಲಿತ ಅಸಿಸ್ಟೆಂಟ್ ಸುಮಾರು 99% ರಷ್ಟು ಸಮಯ ತನ್ನ ಸೂಚನೆಗಳನ್ನು ಪಾಲಿಸುತ್ತದೆ, ಆದರೆ ಆ ಬಿಟ್ಟುಹೋದ 1% ರೇ ದಾಳಿಕೋರರು ದಾಳಿ ಮಾಡುವ ಸ್ಥಳವಾಗಿದೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಾಂಪ್ಟ್ ನೀಡುವ ಮೂಲಕ, ದುರುದ್ದೇಶಪೂರಿತ ಬಳಕೆದಾರರು ಮಾಡೆಲ್ ಮಾಡಬಾರದು ಎಂದುಕೊಂಡಿರುವ ಫಂಕ್ಷನ್ಗಳನ್ನು ಬಳಸುವಂತೆ ಮಾಡಬಹುದು, ಇದರಿಂದ ಡೇಟಾವನ್ನು ಕದಿಯಬಹುದು ಅಥವಾ ವಿಶೇಷ ಅಧಿಕಾರವಿರುವ ಕ್ರಮಗಳನ್ನು ಕೈಗೊಳ್ಳಬಹುದು. ಇದಕ್ಕೆ ಪರಿಹಾರವು ಹೆಚ್ಚು ವಿನಯಪೂರ್ವಕವಾದ ಪದಗಳಲ್ಲಲ್ಲ—ಬದಲಾಗಿ ಈ ದೋಷವನ್ನು ಅಧಿಕಾರೀಕರಣದ (authorization) ಸಮಸ್ಯೆಯಾಗಿ ಪರಿಗಣಿಸಿ, ಅಪಾಯಕಾರಿ ಸಾಧನಗಳನ್ನು ಮಾಡೆಲ್ನ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿಡುವುದು.
ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಕೇವಲ ಪದಗಳ ಸಮಸ್ಯೆಯಲ್ಲದಿರಲು ಕಾರಣಗಳೇನು
ಡೆವಲಪರ್ಗಳು ಹೆಚ್ಚಾಗಿ ಅಕ್ಷರಗಳಲ್ಲೇ ಎಚ್ಚರಿಕೆ ನೀಡುವುದು (all-caps warnings), ಸಂಖ್ಯೆಗಳ ರೂಪದಲ್ಲಿ ನಿಯಮಗಳನ್ನು ನೀಡುವುದು ಅಥವಾ “ಅಡ್ಮಿನ್ ಫಂಕ್ಷನ್ಗಳನ್ನು ಕರೆಯಬೇಡಿ” ಎಂಬ ನಿಯಮಗಳ ಮೂಲಕ ಏಜೆಂಟ್ಗಳನ್ನು ಬಲಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಈ ರಕ್ಷಣಾತ್ಮಕ ಕ್ರಮಗಳು, “X ಅನ್ನು ಮಾಡಬೇಡಿ” ಎಂಬ ವಾಕ್ಯವನ್ನು ಮಾಡೆಲ್ ಪಾಲಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುತ್ತವೆ. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, ವಿನಂತಿಯನ್ನು ಮರುರೂಪಿಸುವ ಮೂಲಕ, ಬೇರೆ ಪಾತ್ರವನ್ನು (role-playing) ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಅಥವಾ ಕೇವಲ ಹೆಚ್ಚಿನ ಸಂದರ್ಭವನ್ನು (context) ಸೇರಿಸುವ ಮೂಲಕ ಮಾಡೆಲ್ ಅನ್ನು ಆ ಸೂಚನೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುವಂತೆ ಪ್ರೇರೇಪಿಸಬಹುದು. ಇಂಗ್ಲಿಷ್ ಭಾಷೆಯ ಮಿತಿಗಳು ಚೌಕಾಸಿ ಮಾಡಬಹುದಾದವು; ಆದರೆ ದಾಳಿಕೋರರ ಪ್ರಾಂಪ್ಟ್ ಅತೀಮಿತ ಮತ್ತು ಅದನ್ನು ಪರೀಕ್ಷಿಸಲು ಯಾವುದೇ ವೆಚ್ಚವಿಲ್ಲ.
ನಿಜವಾದ ದುರ್ಬಲತೆಯು ಏಜೆಂಟ್ಗೆ ಸಿಗುವ ಟೂಲ್ ಪಟ್ಟಿಯಲ್ಲಿ (tool list) ಅಡಗಿದೆ. ಪ್ರಾಂಪ್ಟ್ ಸ್ಕೀಮಾದಲ್ಲಿ ಅಡ್ಮಿನ್ ಹಕ್ಕುಗಳನ್ನು ನೀಡುವ ಫಂಕ್ಷನ್ ಇದ್ದರೆ, ಮಾಡೆಲ್ಗೆ ಆ ಅಧಿಕಾರವನ್ನು ಬಳಸಲು ಒಂದು ಮಾರ್ಗದರ್ಶನ ಸಿಗುತ್ತದೆ. ಪ್ರಾಂಪ್ಟ್ನಲ್ಲಿ “ಗ್ರಾಹಕರಿಗಾಗಿ ಇದನ್ನು ಬಳಸಬೇಡಿ” ಎಂದು ಹೇಳಿದ್ದರೂ ಸಹ, ಆ ಫಂಕ್ಷನ್ ಅದರ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನಲ್ಲಿ ಇರುವುದರಿಂದ ಮಾಡೆಲ್ ಅದನ್ನು ಬಳಸಲು ಪ್ರೇರೇಪಿತವಾಗಬಹುದು. ಆದ್ದರಿಂದ ಈ ಸಮಸ್ಯೆಯು ಅಧಿಕಾರೀಕರಣದ ಅಂತರವಾಗಿದೆ (authorization gap): ವ್ಯವಸ್ಥೆಯು ಅಧಿಕಾರವಿಲ್ಲದ ಬಳಕೆದಾರರಿಗೆ ವಿಶೇಷ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತಿದೆ.
ಪ್ರದರ್ಶನವನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ ಏಜೆಂಟ್ಗಳನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುವುದು
ಈ ಅಂತರವನ್ನು ಮುಚ್ಚಲು ಸರಳವಾದ ಮಾರ್ಗವೆಂದರೆ, ಮಾಡೆಲ್ಗೆ ಅದು ಬಳಸಲು ಅಧಿಕಾರವಿಲ್ಲದ ಟೂಲ್ಗಳ ಪ್ರವೇಶವನ್ನು ನಿಲ್ಲಿಸುವುದು. ಟೂಲ್ ಪಟ್ಟಿಯನ್ನು ಒಂದು API ಕೀ ಎಂದು ಭಾವಿಸಿ: ಕೀ ಇಲ್ಲದಿದ್ದರೆ, ಕರೆಯನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ರಸ್ತುತ ಸಂದರ್ಭದಲ್ಲಿ ಇಲ್ಲದ ಫಂಕ್ಷನ್ ಅನ್ನು ಯಾವುದೇ ಚತುರ ಪದಗಳಿಂದ ತರಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ.
ತಪ್ಪು ವಿಧಾನ
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
ಮಾಡೆಲ್ ತನ್ನ ಟೂಲ್ಬಾಕ್ಸ್ನಲ್ಲಿ adminDeleteUser ಅನ್ನು ಇನ್ನೂ ನೋಡಬಲ್ಲದು ಮತ್ತು ಅದನ್ನು ಬಳಸುವಂತೆ ಮೋಸಗೊಳಿಸಬಹುದು.
ಸರಿಯಾದ ವಿಧಾನ
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser ಎಂದಿಗೂ ಕಾಣಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಮಾಡೆಲ್ಗೆ ಅದನ್ನು ಕರೆಯಲು ಯಾವುದೇ ದಾರಿಯಿಲ್ಲ.
ಡೆವಲಪರ್ಗಳಿಗಾಗಿ ಮೂರು ಪ್ರಾಯೋಗಿಕ ನಿಯಮಗಳು
- ಪ್ರತಿ ವಿನಂತಿಗೆ ತಕ್ಕಂತೆ ಟೂಲ್ ಪಟ್ಟಿಗಳನ್ನು ನಿರ್ಮಿಸಿ – ದೃಢೀಕರಿಸಲ್ಪಟ್ಟ ಬಳಕೆದಾರರ ಅನುಮತಿಗಳ ಆಧಾರದ ಮೇಲೆ ಫಂಕ್ಷನ್ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ಡೈನಾಮಿಕ್ ಆಗಿ ತಯಾರಿಸಿ. ಗ್ರಾಹಕರು ಅವರಿಗೆ ಬೇಕಾದ ಫಂಕ್ಷನ್ಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತಾರೆ; ಅಡ್ಮಿನ್ ಪೂರ್ಣ ಸೆಟ್ ಅನ್ನು ನೋಡುತ್ತಾರೆ.
- ಫೇಲ್ ಕ್ಲೋಸ್ಡ್ (Fail closed) – ಬಳಕೆದಾರರ ಗುರುತನ್ನು ದೃಢೀಕರಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಸಾಮಾನ್ಯ “ಎಲ್ಲಾ ಟೂಲ್ಗಳು ಲಭ್ಯವಿವೆ” ಎಂಬ ಬದಲಿಗೆ ಖಾಲಿ ಪಟ್ಟಿಯನ್ನು ಹಿಂತಿರುಗಿಸಿ. ಇದು ಅಧಿಕಾರವಿಲ್ಲದ ವಿನಂತಿಯು ಎಂದಿಗೂ ಅನಿರೀಕ್ಷಿತ ಅಧಿಕಾರವನ್ನು ಪಡೆಯದಂತೆ ಖಚಿತಪಡಿಸುತ್ತದೆ.
- ಹಂಚಿಕೆಯ ಸ್ಥಿತಿಯನ್ನು (shared state) ತಪ್ಪಿಸಿ – ಟೂಲ್ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವಾಗ, ಬಳಕೆದಾರರಿಗೆ ಸಂಬಂಧಿಸಿದ ಡೇಟಾವನ್ನು ಎಂದಿಗೂ ಹಂಚಿಕೆಯ ಆಬ್ಜೆಕ್ಟ್ ಮೇಲೆ ಬರೆಯಬೇಡಿ. ಒಂದು ಬಳಕೆದಾರರ ಅನುಮತಿಗಳು ಇನ್ನೊಬ್ಬರ ವಿನಂತಿಗೆ ಹರಡದಂತೆ ನೋಡಿಕೊಳ್ಳಲು copy-on-write ಅಥವಾ ಪ್ರತಿ-ಸೆಷನ್ ಪ್ರತಿಗಳನ್ನು (per-session copies) ಬಳಸಿ.
ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರಿಗೆ ತೋರಿಸುವ ಸ್ಕೀಮಾ ಅಡ್ಮಿನ್ಗೆ ತೋರಿಸುವ ಸ್ಕೀಮಾಂತೆಯೇ ಇದ್ದರೆ, ಭದ್ರತಾ ಮಿತಿಯು ಇನ್ನೂ ಪ್ರಾಂಪ್ಟ್ ಪಠ್ಯದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ಪ್ರಾಂಪ್ಟ್ಗಳು ವಿಶ್ವಾಸಾರ್ಹ ಭದ್ರತಾ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲ.
ಇದು ನಮಗೆ ಹೇಗೆ ತಲುಪಿತು
ಡೆವಲಪರ್ಗಳು ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ಗಳನ್ನು (LLMs) ಬಾಹ್ಯ APIಗಳನ್ನು ಕರೆಯಲು, ಕೋಡ್ ಚಲಾಯಿಸಲು ಅಥವಾ ಡೇಟಾಬೇಸ್ಗಳನ್ನು ಮಾರ್ಪಡಿಸಲು ಅಗತ್ಯವಿರುವ ಪ್ರೊಡಕ್ಷನ್ ವರ್ಕ್ಫ್ಲೋಗಳಿಗೆ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಸಮಸ್ಯೆ ಎದುರಾಯಿತು. ಮಾಡೆಲ್ನ “ರೀಸನಿಂಗ್” (reasoning) ಲಭ್ಯವಿರುವ ಟೂಲ್ಗಳ ಪಟ್ಟಿಯನ್ನು ಒಳಗೊಂಡಿರುವ ಪ್ರಾಂಪ್ಟ್ ಮೂಲಕ ಮಾರ್ಗದರ್ಶನ ಪಡೆಯುತ್ತದೆ. ಆರಂಭಿಕ ಪ್ರೊಟೊಟೈಪ್ಗಳು “ಅಡ್ಮಿನ್ಗಳಲ್ಲದವರ ರೆಕಾರ್ಡ್ಗಳನ್ನು ಡಿಲೀಟ್ ಮಾಡಬೇಡಿ” ಎಂಬ ನೈಸರ್ಗಿಕ ಭಾಷೆಯ ನಿಯಮವನ್ನು ಮಾಡೆಲ್ ಪಾಲಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಿದ್ದವು. ಆದರೆ ಕೆಲವು ಹೆಚ್ಚುವರಿ ವಾಕ್ಯಗಳು ಆ ನಿಯಮಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಲ್ಲವು ಮತ್ತು ಮಾಡೆಲ್ ಅನ್ನು ಅದೇ ಡಿಲೀಟ್ ಫಂಕ್ಷನ್ ಅನ್ನು ಬಳಸುವಂತೆ ಪ್ರೇರೇಪಿಸಬಹುದು ಎಂದು ದಾಳಿಕೋರರು ಶೀಘ್ರದಲ್ಲೇ ತೋರಿಸಿಕೊಟ್ಟರು.
ಸಮುದಾಯದ ಮೊದಲ ಪ್ರತಿಕ್ರಿಯೆಯೆಂದರೆ ಪ್ರಾಂಪ್ಟ್ ಭಾಷೆಯನ್ನು ಬಿಗಿಗೊಳಿಸುವುದು, “ಎಂದಿಗೂ X ಮಾಡಬೇಡಿ” ಎಂಬ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವುದು ಅಥವಾ ಅನುಮಾನಾಸ್ಪದ ಟೋಕನ್ಗಳನ್ನು ತೆಗೆದುಹಾಕುವ regex ಫಿಲ್ಟರ್ಗಳನ್ನು ಅಳವಡಿಸುವುದು. ಈ ಕ್ರಮಗಳು ಅಕಸ್ಮಾತ್ ದುರುಪಯೋಗವನ್ನು ಕಡಿಮೆ ಮಾಡಿದವು ಆದರೆ ವಿನಂತಿಯನ್ನು ಮರುರೂಪಿಸುವ ಸಾಮರ್ಥ್ಯವಿರುವ ನಿರ್ಧಾಕಿಯೊಬ್ಬನನ್ನು ತಡೆಯಲಿಲ್ಲ. ಮೂಲ ಕಾರಣ—ಅಧಿಕಾರವಿಲ್ಲದ ಬಳಕೆದಾರರಿಗೆ ವಿಶೇಷ ಫಂಕ್ಷನ್ಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವುದು—ಅಂತೆಯೇ ಉಳಿಯಿತು.
ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ, ಯಾರು ಸೋಲುತ್ತಾರೆ
ಪ್ರತಿ-ವಿನಂತಿಗೆ ಟೂಲ್ ಸ್ಕೋಪಿಂಗ್ ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಉದ್ಯಮಗಳು ಸ್ಪಷ್ಟವಾದ ಮತ್ತು ಜಾರಿಗೊಳಿಸಬಹುದಾದ ಮಿತಿಯನ್ನು ಪಡೆಯುತ್ತವೆ. ಕೇವಲ ಒಂದು ತಪ್ಪಾದ ಪ್ರಾಂಪ್ಟ್ ಅಡ್ಮಿನ್ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಅನ್ಲಾಕ್ ಮಾಡುತ್ತದೆ ಎಂಬ ಭಯವಿಲ್ಲದೆ ಅವರ ಏಜೆಂಟ್ಗಳನ್ನು ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ ಬಳಸಬಹುದು. ಅನುಸರಣೆ (Compliance) ತಂಡಗಳು ಕೂಡ ಆಡಿಟ್ ಟ್ರೈಲ್ ಅನ್ನು ಇಷ್ಟಪಡುತ್ತವೆ: ಮಾಡೆಲ್ಗೆ ಕಳುಹಿಸಲಾದ ಫಂಕ್ಷನ್ಗಳ ಪಟ್ಟಿಯು ಲಾಗ್ ಮಾಡಬಹುದಾದ ಮತ್ತು ಪರಿಶೀಲಿಸಬಹುದಾದ ಒಂದು ನಿರ್ದಿಷ್ಟ ದಾಖಲೆಯಾಗಿದೆ.
ಪ್ರಾಂಪ್ಟ್-ಮಾತ್ರದ ರಕ್ಷಣೆಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಡೆವಲಪರ್ಗಳು ನಿರಂತರವಾಗಿ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸುತ್ತಲೇ ಇರುತ್ತಾರೆ. ಅವರ ಏಜೆಂಟ್ಗಳು ಪರೀಕ್ಷೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವಂತೆ ಕಂಡರೂ, ವಾಸ್ತವದಲ್ಲಿ ಅವು ಡೇಟಾ ಸೋರಿಕೆ, ಅನಧಿಕೃತ ವಹಿವಾಟುಗಳು ಅಥವಾ ಅನುಸರಣೆ ಉಲ್ಲಂಘನೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ಭದ್ರತಾ ಉಲ್ಲಂಘನೆಯ ವೆಚ್ಚವು ಡೈನಾಮಿಕ್ ಟೂಲ್ ಪಟ್ಟಿಯನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರಯತ್ನಕ್ಕಿಂತ ಬಹಳ ದೊಡ್ಡದಾಗಿರುತ್ತದೆ.
ವಿರೋಧಾತ್ಮಕ ವಾದ: “ಉತ್ತಮ ಪ್ರಾಂಪ್ಟ್ಗಳು ಸಾಕಾಗುತ್ತವೆ”
Some argue that with enough instruction engineering—layered prompts, system messages, and reinforcement learning from human feedback—the model can be made to respect “do not” clauses. The reality is that language models are probabilistic generators; they weigh the most likely continuation, not a hard security rule. Even with fine-tuned guardrails, a novel phrasing can slip through, especially when the attacker can iterate endlessly at zero cost. Guardrails are useful for reducing noise but should not be the sole line of defense.
What to watch next
- Frameworks that expose tool scoping as a first-class API – Expect new libraries that let you declare per-user capabilities and automatically prune the function list before the prompt is built.
- Standardized “function manifests” – Industry groups may define a JSON schema that separates public and privileged functions, making it easier to generate request-specific manifests.
- Runtime enforcement – Some platforms are experimenting with sandboxed execution that checks the caller’s token against the function being invoked, adding a second layer beyond prompt scoping.
The takeaway is clear: treat prompt injection as an authorization flaw. By removing unauthorized tools from the model’s toolbox, you eliminate the attack surface that a cleverly worded prompt seeks to exploit. Prompts can guide behavior; they cannot replace proper access control.