LLM ಭದ್ರತೆ ಎಂದರೇನು? OWASP Top 10 ಸುರಕ್ಷತಾ ಅಪಾಯಗಳನ್ನು ತಗ್ಗಿಸುವುದು ಹೇಗೆ

ದಾಳಿಕೋರನ ಸೂಚನೆಗಳನ್ನು ಆದೇಶಗಳೆಂದು ಪರಿಗಣಿಸುವಂತೆ AI ಅನ್ನು ವಂಚಿಸುವ ದಾಳಿ—ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್—2023 ರಿಂದ ಪ್ರತಿಯೊಂದು ಆವೃತ್ತಿಯಲ್ಲೂ OWASP Top 10 for LLM Applications ಪಟ್ಟಿಯಲ್ಲಿ ನಂ. 1 ಸ್ಥಾನದಲ್ಲಿದೆ.

AI ಭದ್ರತೆಯಲ್ಲಿ ಒಮ್ಮತಕ್ಕೆ ಅತ್ಯಂತ ಹತ್ತಿರವಾದದ್ದು ಎಂದರೆ ಈ ಪಟ್ಟಿಯೇ. ಈ ಯೋಜನೆಯು ಭದ್ರತಾ ವೃತ್ತಿಪರರ ಒಂದು ಸಣ್ಣ ಗುಂಪಾಗಿ ಆರಂಭವಾಯಿತು ಮತ್ತು ಈಗ 18 ಕ್ಕೂ ಹೆಚ್ಚು ದೇಶಗಳ 600 ಕ್ಕೂ ಹೆಚ್ಚು ಕೊಡುಗೆದಾರ ತಜ್ಞರನ್ನು ಒಳಗೊಂಡಿದೆ.

AI ಅನ್ನು ಮನವೊಲಿಸಿ ಹೇಗೆ ತಪ್ಪು ಕೆಲಸಗಳನ್ನು ಮಾಡಿಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಪ್ರಕಟಿಸುತ್ತಿರುವ AI ಕಂಪನಿ ನಾವು, ಹಾಗಾಗಿ ಈ ಸಮಸ್ಯೆ ಬಗೆಹರಿದಿದೆ ಎಂದು ನಟಿಸುವುದಿಲ್ಲ. OWASP ಯೋಜನೆಯ ಸಹ-ನಾಯಕರಾದ ವಿಲ್ಸನ್ ಪ್ರಸ್ತುತ ರಕ್ಷಣಾ ಕ್ರಮಗಳ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿದ್ದಾರೆ: “...ನೇರವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ನಾವು 99% ತಲುಪಿದ್ದೇವೆ ಎಂದು ನನಗನಿಸುವುದಿಲ್ಲ.”

2026 ರ ಆವೃತ್ತಿಯೂ ಇದೇ ಧಾಟಿಯಲ್ಲಿ ಆರಂಭವಾಗುತ್ತದೆ. “ಮೋಸಗೊಳಿಸಲಾಗದ ಮಾದರಿಯನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರಯತ್ನವನ್ನು ನಿಲ್ಲಿಸಿ” ಎಂದು, ಹಾಗೂ ಮೋಸಹೋದ ಮಾದರಿಯೂ ಯಾವುದೇ ಮುಖ್ಯವಾದುದನ್ನು ಹಾಳುಮಾಡಲು ಸಾಧ್ಯವಾಗದಂತೆ ಸುತ್ತಲಿನ ವ್ಯವಸ್ಥೆಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ ಎಂದು ಯೋಜನೆಯ ನಾಯಕರು ನಮಗೆ ಹೇಳುತ್ತಾರೆ.

OWASP ನ 2026 ರ ಪಟ್ಟಿಯಲ್ಲಿರುವ ಎಲ್ಲಾ 10 ಅಪಾಯಗಳಿಗೂ ನಾವು ಇದೇ ನಿಲುವನ್ನು ಅನ್ವಯಿಸುತ್ತಿದ್ದೇವೆ.

LLM ಭದ್ರತೆ ಎಂದರೇನು?

LLM ಭದ್ರತೆ ಎಂದರೆ AI ಮಾದರಿಗಳನ್ನು ಮತ್ತು ಅವುಗಳನ್ನು ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ದಾಳಿಗಳು ಹಾಗೂ ದುರುಪಯೋಗದಿಂದ ರಕ್ಷಿಸುವುದು. ಮಾದರಿಯು ಯಾವುದಕ್ಕೆಲ್ಲಾ ಸಂಪರ್ಕಗೊಂಡಿದೆಯೋ ಅದರೊಂದಿಗೆ ಅಪಾಯವೂ ಹೆಚ್ಚುತ್ತದೆ: ಅದು ಓದಬಹುದಾದ ಫೈಲ್‌ಗಳು ಮತ್ತು ಡೇಟಾ, ಹಾಗೂ ಇಮೇಲ್, ಹುಡುಕಾಟ ಅಥವಾ ಕಂಪನಿಯ ಡೇಟಾಬೇಸ್‌ನಂತಹ ಅದು ಬಳಸಬಹುದಾದ ಉಪಕರಣಗಳು.

ಸರಿಯಾಗಿ ಸುರಕ್ಷಿತಗೊಳಿಸಿದ ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ, ಪ್ರೋಗ್ರಾಂ ಅನುಸರಿಸುವ ಸೂಚನೆಗಳು ಮತ್ತು ಅದು ಸಂಸ್ಕರಿಸುವ ಮಾಹಿತಿಯ ನಡುವೆ ಸ್ಪಷ್ಟವಾದ ಗೆರೆ ಇರುತ್ತದೆ. ಆದರೆ LLM ಗಳಲ್ಲಿ ಆ ಗೆರೆ ಇಲ್ಲ.

ಮಾದರಿ ಓದುವ ಎಲ್ಲವೂ ಒಂದೇ ದೀರ್ಘ ಪಠ್ಯ ಪ್ರವಾಹವಾಗಿ ಬರುತ್ತದೆ: ಡೆವಲಪರ್‌ನ ಸೂಚನೆಗಳು, ನಿಮ್ಮ ಪ್ರಶ್ನೆ, ಅದು ಹುಡುಕಿದ ವೆಬ್‌ಪುಟ. ಮಾತನಾಡುತ್ತಿರುವವರು ಯಾರು—ಡೆವಲಪರ್, ಬಳಕೆದಾರ, ಅಥವಾ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಿರುವ ಮಾದರಿಯೇ—ಎಂಬುದನ್ನು AI ಮಾದರಿಗಳು ಗಮನದಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು.

ಆದರೆ ಸಂಶೋಧಕರಾದ ಜಾಸ್ಮಿನ್ ಕುಯಿ ಮತ್ತು ಚಾರ್ಲ್ಸ್ ಯೆ ಅವರು, ಪಠ್ಯವು ಹೇಗೆ ಧ್ವನಿಸುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆಯೇ ಮಾತನಾಡುತ್ತಿರುವವರು ಯಾರು ಎಂದು ಮಾದರಿಗಳು ಹೆಚ್ಚಾಗಿ ಊಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಕಂಡುಕೊಂಡರು. ಹಾಗಾಗಿ ದಾಳಿಕೋರನು ಮಾದರಿಯ ಸ್ವಂತ ತಾರ್ಕಿಕತೆಯಂತೆ ಧ್ವನಿಸುವ ಏನನ್ನಾದರೂ ಬರೆದರೆ, ಆ ಆಲೋಚನೆ ತನ್ನದೇ ಎಂದು ಮಾದರಿ ನಂಬಬಹುದು. ಅಧಿಕಾರ ಯಾರದು ಎಂಬುದನ್ನು ಮಾದರಿ ತಿಳಿದಿರುವುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಯಾವುದೇ ಸುರಕ್ಷತಾ ವ್ಯವಸ್ಥೆಗೆ ಇದು ಸಮಸ್ಯೆ.

ನಮ್ಮ ಸ್ವಂತ AI ಏಜೆಂಟ್‌ಗಳಲ್ಲಿಯೂ ನಾವು ಇದೇ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. ನಮ್ಮ CISO ಕೈಲ್ ಪೊಲ್ಲಿ ಅವರು, ಏಜೆಂಟ್‌ಗಳು “ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಸೇರಿಸಿದರೂ ನೀತಿಗಳನ್ನು ಪಾಲಿಸದಿರಬಹುದು” ಎಂದು ISMG ಗೆ ಹೇಳಿದ್ದಾರೆ. ಅದಕ್ಕಾಗಿಯೇ ನಾವು Numbat ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ—ಇದು ಏಜೆಂಟ್ ಏನು ಮಾಡಲು ಹೊರಟಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುವ ಮತ್ತು ಆ ಕ್ರಿಯೆಯು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಭದ್ರತಾ ನಿಯಮವನ್ನು ಉಲ್ಲಂಘಿಸಿದರೆ ಅದನ್ನು ತಡೆಯಬಲ್ಲ ಓಪನ್-ಸೋರ್ಸ್ ಉಪಕರಣ.

LLM ಭದ್ರತೆ ಎಂದರೆ, ಮಾದರಿಯು ಕೆಲವೊಮ್ಮೆ ತಪ್ಪು ವ್ಯಕ್ತಿಯಿಂದ ಆದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು, ಮತ್ತು ಹಾಗಾದಾಗಲೂ ದೃಢವಾಗಿ ನಿಲ್ಲುವ AI ಗಾರ್ಡ್‌ರೇಲ್‌ಗಳನ್ನು ಅದರ ಸುತ್ತ ನಿರ್ಮಿಸುವುದು.

LLM ಭದ್ರತೆಗೆ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಯಾವುವು?

ನಾವು OWASP Top 10 for LLM Applications 2026 ಪಟ್ಟಿಯನ್ನು ನಂ. 1 ರಿಂದ ನಂ. 10 ರವರೆಗೆ ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ಪ್ರತಿಯೊಂದು ಅಪಾಯಕ್ಕೂ, ಏನು ತಪ್ಪಾಗುತ್ತದೆ ಎಂಬುದರ ಸರಳ ಭಾಷೆಯ ವಿವರಣೆ ಮತ್ತು ನೈಜ ಜಗತ್ತಿನ ಉದಾಹರಣೆಯನ್ನು ನೀಡುತ್ತೇವೆ. ನಂತರ ಅದನ್ನು ತಡೆಯಲು, ಅಥವಾ ಕನಿಷ್ಠ ಪಕ್ಷ ಹಾನಿಯನ್ನು ಸೀಮಿತಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುವ ಅಭ್ಯಾಸಗಳನ್ನು ವಿವರಿಸುತ್ತೇವೆ.

1. ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಿ

ದಾಳಿಕೋರನು AI ತಾನು ಅನುಸರಿಸಬಾರದ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸುವಂತೆ ಮಾಡಿದಾಗ ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಸಂಭವಿಸುತ್ತದೆ. ಆ ಸೂಚನೆಗಳು ನೇರವಾಗಿ ಚಾಟ್‌ನಲ್ಲಿ ಬರಬಹುದು ಅಥವಾ ಇಮೇಲ್, ವೆಬ್‌ಪುಟ ಅಥವಾ ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಅಡಗಿಸಿಡಲಾಗಿರಬಹುದು.

ಎರಡನೆಯ ಪ್ರಕಾರವನ್ನು ಪರೋಕ್ಷ ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ನೀವು ನಿಮ್ಮ ಸಹಾಯಕನಿಗೆ ಒಂದು ಡಾಕ್ಯುಮೆಂಟ್‌ನ ಸಾರಾಂಶ ನೀಡುವಂತೆ ಕೇಳುತ್ತೀರಿ. ಆ ಡಾಕ್ಯುಮೆಂಟ್ ಬರೆದವರು ನಿಮ್ಮ ಖಾಸಗಿ ಫೈಲ್‌ಗಳನ್ನು ತಮಗೆ ಕಳುಹಿಸುವಂತೆ ಸಹಾಯಕನಿಗೆ ಸೂಚಿಸಿದ್ದಾರೆ. ಸಹಾಯಕನು ಆ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿದರೆ, ಡಾಕ್ಯುಮೆಂಟ್ ಬರೆದ ವ್ಯಕ್ತಿಯು ವಾಸ್ತವದಲ್ಲಿ ನಿಮ್ಮ ಪ್ರವೇಶಾಧಿಕಾರವನ್ನು ಎರವಲು ಪಡೆದಂತಾಗುತ್ತದೆ.

PCMag ಪ್ರಾಂಪ್ಟ್ ಭದ್ರತೆಯನ್ನು ರಂಧ್ರಗಳಿರುವ ಕಲ್ಲಿನ ತೂತುಗಳನ್ನು ಮುಚ್ಚುವುದಕ್ಕೆ ಹೋಲಿಸುತ್ತದೆ. ನೀವು ಒಂದು ತೂತನ್ನು ಮುಚ್ಚಿದರೆ, ನೀರು ಮತ್ತೊಂದನ್ನು ಹುಡುಕಿಕೊಳ್ಳುತ್ತದೆ. “ಒಂದು ದಾಳಿ ತನ್ನ ದಾರಿ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ; ಅದನ್ನು ಸರಿಪಡಿಸಲಾಗುತ್ತದೆ, ಆದರೆ LLM ಗಳಂತಹ ವ್ಯವಸ್ಥೆಗಳು ಅಷ್ಟು ಕ್ರಿಯಾಶೀಲವಾಗಿರುವುದರಿಂದಲೇ ಇನ್ನೂ ಲೆಕ್ಕವಿಲ್ಲದಷ್ಟು ದಾಳಿ ಮಾರ್ಗಗಳು ಪತ್ತೆಯಾಗಬೇಕಿವೆ.”

ಉದಾಹರಣೆ: ಜೂನ್ 2025 ರಲ್ಲಿ, Aim Security ಸಂಶೋಧಕರು EchoLeak ಅನ್ನು ಪತ್ತೆಹಚ್ಚಿದರು—ಇದು Microsoft 365 Copilot ಖಾಸಗಿ ಕಂಪನಿ ಮಾಹಿತಿಯನ್ನು ಸೋರಿಕೆ ಮಾಡುವಂತೆ ವಂಚಿಸಿದ ದೋಷ. ಉದ್ಯೋಗಿಯೊಬ್ಬರು ಸಾಮಾನ್ಯ ಕೆಲಸದ ಪ್ರಶ್ನೆ ಕೇಳಿದಾಗ, Copilot ಆ ಇಮೇಲ್ ಅನ್ನು ಸೆಳೆದುಕೊಂಡು, ಅದರೊಳಗೆ ಅಡಗಿಸಿದ್ದ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿ, ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯನ್ನು ದಾಳಿಕೋರನಿಗೆ ಕಳುಹಿಸಬಹುದಿತ್ತು. ದುರುದ್ದೇಶಪೂರಿತ ಸೂಚನೆಗಳನ್ನು ಹಿಡಿಯಲು ಮತ್ತು ಅನುಮಾನಾಸ್ಪದ ಲಿಂಕ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಲು ಉದ್ದೇಶಿಸಿದ್ದ ಪರಿಶೀಲನೆಗಳನ್ನು ಈ ದಾಳಿ ದಾಟಿತು.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• Meta ದ “ಎರಡರ ನಿಯಮ” (Rule of Two) ಅನ್ನು ಅನುಸರಿಸಿ: EchoLeak ಗೆ ಕಂಪನಿ ಡೇಟಾವನ್ನು ಓದಬಲ್ಲ, ಹೊರಗಿನ ಇಮೇಲ್ ಓದಬಲ್ಲ ಮತ್ತು ಮಾಹಿತಿಯನ್ನು ಹೊರಗೆ ಕಳುಹಿಸಬಲ್ಲ AI ಬೇಕಾಗಿತ್ತು—ಮತ್ತು ಅದಕ್ಕೆ ಈ ಮೂರೂ ಸಾಮರ್ಥ್ಯಗಳಿದ್ದವು. ಅದನ್ನು ಈ ಸಾಮರ್ಥ್ಯಗಳಲ್ಲಿ ಎರಡಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸುವುದರಿಂದ ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಅತಿಯಾದ ನಿಯಂತ್ರಣ ಪಡೆಯುವುದನ್ನು ತಡೆಯಬಹುದು. ಕಾರ್ಯಕ್ಕೆ ಮೂರೂ ಅಗತ್ಯವಿದ್ದರೆ, ಪ್ರತಿಯೊಂದು ಕ್ರಿಯೆಯ ಮೊದಲು ಮಾನವ ಅನುಮೋದನೆಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿ.
• ನಿಮ್ಮ ರಕ್ಷಣಾ ಕ್ರಮಗಳನ್ನು ತಿಳಿದಿರುವ ದಾಳಿಕೋರರ ವಿರುದ್ಧ ಪರೀಕ್ಷಿಸಿ: ನೀವು ಜಾರಿಗೊಳಿಸಿರುವ ನಿಯಮಗಳು ಮತ್ತು ಫಿಲ್ಟರ್‌ಗಳನ್ನು ನಿಮ್ಮ ಭದ್ರತಾ ಪರೀಕ್ಷಕರಿಗೆ ನೀಡಿ, ನಂತರ ಅವುಗಳನ್ನು ಮೀರುವ ದಾರಿಗಳನ್ನು ಹುಡುಕಲು ಅವರಿಗೆ ಅವಕಾಶ ನೀಡಿ. ಒಂದು ಅಧ್ಯಯನದಲ್ಲಿ, ರಕ್ಷಣಾ ಕ್ರಮಗಳಿಗೆ ತಕ್ಕಂತೆ ಹೊಂದಿಕೊಂಡ ದಾಳಿಕೋರರು ಪರೀಕ್ಷಿಸಲಾದ 12 ರಕ್ಷಣಾ ಕ್ರಮಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವುಗಳ ವಿರುದ್ಧ 90% ಕ್ಕೂ ಹೆಚ್ಚು ಬಾರಿ ಯಶಸ್ವಿಯಾದರು.

2. ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿ ಸೋರಿಕೆಯಾಗುವುದನ್ನು ತಡೆಯಿರಿ

AI ವ್ಯವಸ್ಥೆಗಳು ಖಾಸಗಿ ಮಾಹಿತಿಯನ್ನು ಅದನ್ನು ನೋಡಬಾರದ ಜನರಿಗೆ ನೀಡಿದಾಗ, ಅದನ್ನು ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿ ಬಹಿರಂಗಪಡಿಸುವಿಕೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಇದು ಗ್ರಾಹಕರ ಪಾವತಿ ವಿವರಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದು ಅಥವಾ ಖಾಸಗಿ ಸಂಭಾಷಣೆಗಳನ್ನು ಹಂಚಿಕೆಯ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಬಿಟ್ಟುಬಿಡುವುದು ಆಗಿರಬಹುದು.

ಅನೇಕ ಸೋರಿಕೆಗಳು “ಅತಿಯಾದ ಹಂಚಿಕೆ”ಯಿಂದ ಆರಂಭವಾಗುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಒಂದು ಕಂಪನಿಯು ಸಡಿಲ ಅನುಮತಿಗಳಿರುವ ಡ್ರೈವ್‌ಗಳು ಮತ್ತು ಜ್ಞಾನ ಭಂಡಾರಗಳಿಗೆ ತನ್ನ AI ಅನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ ಎಂದುಕೊಳ್ಳಿ. AI ತನಗೆ ತಲುಪಬಹುದಾದ ಎಲ್ಲವನ್ನೂ, ವಿನ್ಯಾಸಗೊಳಿಸಿದಂತೆಯೇ, ಹಿಂಪಡೆಯುತ್ತದೆ. ಯಾರೂ ಒಳನುಗ್ಗಬೇಕಾಗಿಲ್ಲ, ಆದರೂ LLM ಅನ್ನು ಭೇದಿಸಲಾಗಿದೆ ಎಂದೇ ಪರಿಗಣಿಸಿ.

ಉದಾಹರಣೆ: ಜನವರಿ 2025 ರಲ್ಲಿ, Wiz ಸಂಶೋಧಕರು ಇಂಟರ್ನೆಟ್‌ಗೆ ತೆರೆದುಕೊಂಡಿದ್ದ DeepSeek ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚಿದರು; ಅದರಲ್ಲಿ ಚಾಟ್ ಇತಿಹಾಸ ಮತ್ತು API ಕೀಗಳು (ಇತರ ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಫ್ಟ್‌ವೇರ್ ಬಳಸುವ ಕೀಗಳು) ಸೇರಿದಂತೆ ಹತ್ತು ಲಕ್ಷಕ್ಕೂ ಹೆಚ್ಚು ಲಾಗ್ ನಮೂದುಗಳಿದ್ದವು. ಏನನ್ನಾದರೂ ಬಹಿರಂಗಪಡಿಸುವಂತೆ ಸಂಶೋಧಕರು ಮಾದರಿಯನ್ನು ಮನವೊಲಿಸುವ ಅಗತ್ಯವೇ ಇರಲಿಲ್ಲ.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• AI ಡೇಟಾವನ್ನು ಓದುವ ಮೊದಲು ಪ್ರವೇಶಾನುಮತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ: ಪ್ರಶ್ನೆ ಕೇಳುತ್ತಿರುವ ವ್ಯಕ್ತಿಗೆ ಯಾವ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ನೋಡಲು ಅನುಮತಿ ಇದೆ ಎಂಬುದನ್ನು, ಅವುಗಳನ್ನು ಮಾದರಿಗೆ ರವಾನಿಸುವ ಮೊದಲೇ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಪರಿಶೀಲಿಸಬೇಕು.
• ನಿಮ್ಮ AI ಬಿಟ್ಟುಹೋಗುವ ದಾಖಲೆಗಳನ್ನು ರಕ್ಷಿಸಿ: ಚಟುವಟಿಕೆ ಲಾಗ್‌ಗಳನ್ನು ಉಳಿಸುವ ಮೊದಲು ಖಾಸಗಿ ವಿವರಗಳು ಮತ್ತು ರಹಸ್ಯ ಕೀಗಳನ್ನು ತೆಗೆದುಹಾಕಿ, ಲಾಗಿನ್ ಕಡ್ಡಾಯಗೊಳಿಸಿ, ಮತ್ತು ಅಗತ್ಯವಿರುವ ಜನರಿಗೆ ಮಾತ್ರ ಪ್ರವೇಶವನ್ನು ಸೀಮಿತಗೊಳಿಸಿ. ಆ ದಾಖಲೆಗಳು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಸಂಗ್ರಹವಾಗದಂತೆ ಉಳಿಸಿಕೊಳ್ಳುವ ಅವಧಿಯನ್ನು ನಿಗದಿಪಡಿಸಿ.

3. ಅತಿಯಾದ ಸ್ವಾಯತ್ತತೆಗೆ ಕಡಿವಾಣ ಹಾಕಿ

ಅತಿಯಾದ ಸ್ವಾಯತ್ತತೆ ಇರುವ AI ಗಳು ತಮ್ಮ ಕೆಲಸಕ್ಕೆ ಬೇಕಾದುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಧಿಕಾರವನ್ನು ಹೊಂದಿರುತ್ತವೆ: ಅಗತ್ಯವಿಲ್ಲದ ಉಪಕರಣಗಳು, ಕಾರ್ಯದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿದ ಅನುಮತಿಗಳು, ಅಥವಾ ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸ್ವಾತಂತ್ರ್ಯ. ಇಲ್ಲಿ ಕಾರಣ ಏನು ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ.

ಇಂಜೆಕ್ಷನ್ ಪ್ರಾಂಪ್ಟ್, ಬಗ್, ಅಥವಾ ಸುಮ್ಮನೆ ತಪ್ಪು ಮಾಡುವ ಮಾದರಿ—ಎಲ್ಲವೂ ಒಂದೇ ಫಲಿತಾಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ. AI ಗೆ ಸಾಮರ್ಥ್ಯ ಇದ್ದರೆ, ಅದು ಎಂದಾದರೂ ವಿನಾಶಕಾರಿಯಾದ ಏನನ್ನಾದರೂ ಮಾಡಿಯೇ ಮಾಡುತ್ತದೆ.

ಉದಾಹರಣೆ: ಜುಲೈ 2025 ರಲ್ಲಿ, ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬಾರದು ಎಂಬ ಸೂಚನೆಗಳಿದ್ದರೂ Replit ನ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ 1,206 ಕಾರ್ಯನಿರ್ವಾಹಕರ ದಾಖಲೆಗಳಿದ್ದ ತಮ್ಮ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಳಿಸಿಹಾಕಿತು ಎಂದು SaaStr ಸಂಸ್ಥಾಪಕ ಜೇಸನ್ ಲೆಮ್ಕಿನ್ ವರದಿ ಮಾಡಿದರು. ಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಏಜೆಂಟ್ ಆರಂಭದಲ್ಲಿ ಹೇಳಿತು, ಆದರೆ ನಂತರ ಮರುಪಡೆಯುವಿಕೆ ಸಾಧ್ಯವೆಂದು ಸಾಬೀತಾಯಿತು. ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮುಟ್ಟಬೇಡ ಎಂದು ಹೇಳಿದ್ದರಿಂದ ಅದನ್ನು ಅಳಿಸುವ ಏಜೆಂಟ್‌ನ ಸಾಮರ್ಥ್ಯ ತೆಗೆದುಹೋಗಿರಲಿಲ್ಲ ಎಂಬುದನ್ನು ಜೇಸನ್ ಕಂಡುಕೊಂಡರು.

ವಿಸ್ತರಿಸಿ

ಮೂಲ: X

ನೀವು ಏನು ಮಾಡಬಹುದು:

• ಕಾರ್ಯಕ್ಕೆ ಅಗತ್ಯವಿಲ್ಲದ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ತೆಗೆದುಹಾಕಿ: ಏಜೆಂಟ್‌ಗೆ ಸಿಗುವ ಉಪಕರಣಗಳು ಮತ್ತು ಆ ಉಪಕರಣಗಳು ಏನು ಮಾಡಬಲ್ಲವು ಎಂಬುದು—ಎರಡನ್ನೂ ಸೀಮಿತಗೊಳಿಸಿ. ಇಮೇಲ್‌ಗಳ ಸಾರಾಂಶ ನೀಡುವ ಸಹಾಯಕನಿಗೆ ಅವುಗಳನ್ನು ಓದಲು ಅನುಮತಿ ಬೇಕು, ಕಳುಹಿಸಲು ಅಥವಾ ಅಳಿಸಲು ಅಲ್ಲ.
• ಅನುಮತಿ ಪರಿಶೀಲನೆಗಳನ್ನು AI ನ ಹೊರಗೆ ಇರಿಸಿ: ಪ್ರತಿ ಬಾರಿ ಕ್ರಿಯೆಯನ್ನು ವಿನಂತಿಸಿದಾಗ, ಅದನ್ನು ನಿಮ್ಮ ಭದ್ರತಾ ನಿಯಮಗಳ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸುವಂತೆ ಮಾಡಿ, ಮತ್ತು ಅದನ್ನು ಒಬ್ಬ ವ್ಯಕ್ತಿ ಅನುಮೋದಿಸುವುದನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿ.

4. ನಿಮ್ಮ AI ಪೂರೈಕೆ ಸರಪಳಿಗೆ ಏನು ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ

ಕೆಲವೇ ಕಂಪನಿಗಳು AI ಅನ್ನು ಮೊದಲಿನಿಂದ ನಿರ್ಮಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿ ವರ್ಷ ಅವುಗಳ ಸಂಖ್ಯೆ ಇನ್ನಷ್ಟು ಕಡಿಮೆಯಾಗುತ್ತಿದೆ. Menlo Ventures ನ 2025 The State of Generative AI in the Enterprise ಸಮೀಕ್ಷೆಯ ಪ್ರಕಾರ, 2024 ರಲ್ಲಿ 53% ಕಂಪನಿಗಳು AI ಮಾದರಿಗಳನ್ನು ಖರೀದಿಸಿದ್ದವು, ಇದು 2025 ರಲ್ಲಿ 76% ಕ್ಕೆ ಏರಿತು.

ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಕಂಪನಿಗಳು Hugging Face ನಂತಹ ಹಬ್‌ಗಳಿಂದ ಮಾದರಿಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತವೆ, ಬೇರೆಯವರು ಸಂಗ್ರಹಿಸಿದ ಡೇಟಾಸೆಟ್‌ಗಳಲ್ಲಿ ಅವುಗಳಿಗೆ ಮತ್ತಷ್ಟು ತರಬೇತಿ ನೀಡುತ್ತವೆ, ಮತ್ತು ಅಪರಿಚಿತರು ಬರೆದ ಆಡ್-ಆನ್‌ಗಳು ಹಾಗೂ ಕೋಡ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಜೋಡಿಸುತ್ತವೆ.

ಈ ಪ್ರತಿಯೊಂದು ಭಾಗವೂ ಒಳನುಸುಳಲು ಒಂದು ದಾರಿ. ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ತಿರುಚಿದರೆ, ಸಮಸ್ಯೆ ನಿಮ್ಮ ಉತ್ಪನ್ನದೊಳಗೇ ಸೇರಿಕೊಂಡು ಬಳಕೆದಾರರನ್ನು ತಲುಪುತ್ತದೆ.

ಉದಾಹರಣೆ: ಜನವರಿ 2026 ಮತ್ತು ಆಗಸ್ಟ್ 2026 ರ ನಡುವೆ Hugging Face ನ ಸಾರ್ವಜನಿಕ ಮಾದರಿ ರೆಪೊಸಿಟರಿಗಳು 2.43 ಮಿಲಿಯನ್‌ನಿಂದ 2.96 ಮಿಲಿಯನ್‌ಗೆ ಏರಿದವು. ಆದರೆ ಜುಲೈ 2026 ರಲ್ಲಿ, ಆಂತರಿಕ ಭದ್ರತಾ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಇಂಟರ್ನೆಟ್‌ನಿಂದ ದೂರವಿಡಲು ಉದ್ದೇಶಿಸಿದ್ದ ನಿಯಂತ್ರಣಗಳನ್ನು OpenAI ನ ಮಾದರಿಗಳು ದಾಟಿ, Hugging Face ನ ವ್ಯವಸ್ಥೆಗಳ ಕೆಲವು ಭಾಗಗಳಿಗೆ ನುಗ್ಗಿದವು. ವಾಸ್ತವವಾಗಿ, ಒಂದು ಏಜೆಂಟ್ ಸಾರ್ವಜನಿಕವಾಗಿ ಬಹಿರಂಗವಾಗಿದ್ದ 14 ಪ್ರವೇಶ ರುಜುವಾತುಗಳನ್ನು ಪಡೆದುಕೊಂಡು, ಅವು ಕೆಲಸ ಮಾಡುತ್ತವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಇತರ ಏಜೆಂಟ್‌ಗಳೊಂದಿಗೆ ಹಂಚಿಕೊಂಡಿತು. ನಂತರ ಏಜೆಂಟ್‌ಗಳು Hugging Face ನ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕೋಡ್ ಚಲಾಯಿಸಲು ಅವಕಾಶ ನೀಡುವ ದೋಷಗಳನ್ನು ದುರ್ಬಳಕೆ ಮಾಡಿಕೊಂಡವು.

“ಮಾದರಿಯ ಜೀವನಚಕ್ರದುದ್ದಕ್ಕೂ ಅಲೈನ್‌ಮೆಂಟ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಕಠಿಣ ಅವಶ್ಯಕತೆಗಳನ್ನು ನಾವು ವಿಧಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಹೆಚ್ಚು ಪ್ರತ್ಯೇಕಿತ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ಗಳನ್ನು ರಚಿಸುತ್ತಿದ್ದೇವೆ, ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತಿದ್ದೇವೆ, ಮತ್ತು ಮಾದರಿ ವೇಟ್‌ಗಳ ಪ್ರವೇಶವನ್ನು ಇನ್ನಷ್ಟು ನಿಯಂತ್ರಿಸುತ್ತಿದ್ದೇವೆ,” ಎಂದು OpenAI ವರದಿ ಹೇಳುತ್ತದೆ.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• ಮಾದರಿಗಳನ್ನು ನಿಖರವಾದ ಆವೃತ್ತಿಗೆ ಪಿನ್ ಮಾಡಿ ಮತ್ತು ಅವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ಪ್ರತಿಯೊಂದು ಮಾದರಿಯನ್ನು ಪರಿಶೀಲಿಸಿದ ಆವೃತ್ತಿಗೆ ಪಿನ್ ಮಾಡಿ ಮತ್ತು ಲೋಡ್ ಮಾಡುವ ಮೊದಲು ಅದರ ಫೈಲ್ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ, ಇದರಿಂದ ಬದಲಾಯಿಸಲಾದ ಫೈಲ್ ಅದೇ ಲೇಬಲ್‌ನಡಿ ನುಸುಳಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. OWASP ಡಿಜಿಟಲ್ ಸಹಿಗಳನ್ನೂ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ, ಆದರೆ ಒಂದು ಎಚ್ಚರಿಕೆಯೊಂದಿಗೆ—ಸಹಿಯು ಮಾದರಿ ಎಲ್ಲಿಂದ ಬಂತು ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆಯೇ ಹೊರತು ಅದು ಸುರಕ್ಷಿತವೆಂದು ಅಲ್ಲ.
• ನಿಮ್ಮ AI ಸೂಚಿಸುವ ಪ್ರತಿಯೊಂದು ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ: AI ಸಹಾಯಕ ಶಿಫಾರಸು ಮಾಡಿದ ಕೋಡ್ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುವ ಮೊದಲು, ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆಯೇ, ಅದು ನೀವು ಉದ್ದೇಶಿಸಿದ ಪ್ಯಾಕೇಜ್ ಹೌದೇ, ಮತ್ತು ಅದು ನೀವು ನಿರೀಕ್ಷಿಸುವ ಪ್ರಕಾಶಕರಿಂದ ಬಂದಿದೆಯೇ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.

5. ಡೇಟಾ ಮತ್ತು ಮಾದರಿ ವಿಷಪೂರಣದಿಂದ ರಕ್ಷಿಸಿಕೊಳ್ಳಿ

ವಿಷಪೂರಿತ AI ಕಲುಷಿತ ಡೇಟಾದಿಂದ ಕಲಿಯುತ್ತದೆ. ಇದು ಅದನ್ನು ಫೈನ್-ಟ್ಯೂನ್ ಮಾಡಲು ಬಳಸಿದ ಉದಾಹರಣೆಗಳಾಗಿರಬಹುದು, ಅಥವಾ ಉತ್ತರಗಳಿಗಾಗಿ ಅದು ಹುಡುಕುವ ಜ್ಞಾನ ಭಂಡಾರವಾಗಿರಬಹುದು. ಮಾದರಿ ಇನ್ನೂ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಂತೆಯೇ ಕಾಣುತ್ತದೆ; ಅದು ತಪ್ಪು ಪಾಠಗಳನ್ನು ಕಲಿಯುತ್ತದೆ ಅಷ್ಟೇ, ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ನಿರ್ದಿಷ್ಟ ಟ್ರಿಗರ್ ನುಡಿಗಟ್ಟನ್ನು ಕಂಡಾಗ ಮಾತ್ರ ತಪ್ಪಾಗಿ ವರ್ತಿಸಲು ಕಲಿಯುತ್ತದೆ.

ಯಾರಾದರೂ ಆ ನುಡಿಗಟ್ಟನ್ನು ಬಳಸುವವರೆಗೂ, ನೀವು ನಡೆಸುವ ಪ್ರತಿಯೊಂದು ಪರೀಕ್ಷೆಯಲ್ಲೂ ಅದು ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ.

ವಿಸ್ತರಿಸಿ

ಅಲ್ಲದೆ, ಇದನ್ನು ಸರಿಪಡಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ. ವಿಷಪೂರಣವು ಪ್ಯಾಚ್ ಮಾಡಬಹುದಾದ ಬಗ್ ಅಲ್ಲ. ನಿಮ್ಮ ಡೇಟಾ ತಪ್ಪಾಗಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಮರುಪರಿಶೀಲಿಸಬೇಕಾಗಬಹುದು, ಮಾದರಿಗೆ ಮರುತರಬೇತಿ ನೀಡಬೇಕಾಗಬಹುದು, ಅಥವಾ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಾಯಿಸಬೇಕಾಗಬಹುದು.

ಉದಾಹರಣೆ: ಅಕ್ಟೋಬರ್ 2025 ರಲ್ಲಿ, Anthropic, UK AI Security Institute ಮತ್ತು Alan Turing Institute ನ ಸಂಶೋಧಕರು, ನಿರ್ದಿಷ್ಟ ಟ್ರಿಗರ್ ಎದುರಾದಾಗಲೆಲ್ಲಾ ಮಾದರಿಯು ಅರ್ಥಹೀನ ಪಠ್ಯವನ್ನು ಉತ್ಪಾದಿಸುವಂತೆ 250 ವಿಷಪೂರಿತ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು ಕಲಿಸಬಲ್ಲವು ಎಂದು ತೋರಿಸಿದರು. ಅತಿದೊಡ್ಡ ಮಾದರಿಯು 20 ಪಟ್ಟಿಗೂ ಹೆಚ್ಚು ಶುದ್ಧ ಡೇಟಾದ ಮೇಲೆ ತರಬೇತಿ ಪಡೆದಿದ್ದರೂ, ಪರೀಕ್ಷಿಸಿದ ಎಲ್ಲಾ ನಾಲ್ಕು ಮಾದರಿ ಗಾತ್ರಗಳಲ್ಲೂ ಅದೇ ಸಂಖ್ಯೆ ಕೆಲಸ ಮಾಡಿತು.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• ನಿಮ್ಮ ಡೇಟಾ ಎಲ್ಲಿಂದ ಬರುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ನಿಗಾ ಇಡಿ: ನೀವು ಬಳಸುವ ಪ್ರತಿಯೊಂದು ಡೇಟಾಸೆಟ್ ಮತ್ತು ಮಾದರಿ, ಪ್ರತಿಯೊಂದೂ ಎಲ್ಲಿಂದ ಬಂತು, ಮತ್ತು ಆವೃತ್ತಿಗಳ ನಡುವೆ ಏನು ಬದಲಾಗಿದೆ ಎಂಬುದರ ದಾಖಲೆಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ಡೇಟಾಸೆಟ್‌ಗಳಿಗೆ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣವನ್ನು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ, ಇದರಿಂದ ವಿಷಪೂರಣ ಪತ್ತೆಯಾದರೆ, ನೀವು ಶುದ್ಧ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗಬಹುದು ಮತ್ತು ಅದು ಹೇಗೆ ಒಳಬಂತು ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದು.
• ಬ್ಯಾಕ್‌ಡೋರ್‌ಗಳಿಗಾಗಿ ಪರೀಕ್ಷಿಸಿ: “ಬ್ಯಾಕ್‌ಡೋರ್” ಎಂದರೆ ದಾಳಿಕೋರನು ಮಾದರಿಯಲ್ಲಿ ಅಳವಡಿಸುವ ಗುಪ್ತ ನಡವಳಿಕೆ; ಅದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ನಿರ್ದಿಷ್ಟ ನುಡಿಗಟ್ಟು ಅಥವಾ ಇತರ ಟ್ರಿಗರ್‌ಗಾಗಿ ಅದು ಕಾಯುತ್ತಿರುತ್ತದೆ. ಮಾದರಿಯು ತನ್ನ ಸಾಮಾನ್ಯ ನಿಯಮಗಳನ್ನು ಮುರಿಯುವಂತೆ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಇನ್‌ಪುಟ್‌ಗಳೊಂದಿಗೆ ಇವುಗಳಿಗಾಗಿ ಪರೀಕ್ಷಿಸಿ.

6. ಮಿತಿಯಿಲ್ಲದ ಬಳಕೆಗೆ ಮಿತಿ ಹಾಕಿ

AI ಗಳು ಎಷ್ಟು ಕೆಲಸ ಮಾಡಬಹುದು ಅಥವಾ ಎಷ್ಟು ವೆಚ್ಚ ಮಾಡಬಹುದು ಎಂಬುದಕ್ಕೆ ಯಾವುದೇ ಮಿತಿಗಳಿಲ್ಲದಿದ್ದಾಗ, ಅವುಗಳ ಬಳಕೆಯನ್ನು “ಮಿತಿಯಿಲ್ಲದ” ಬಳಕೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ AI ಸೇವೆಗಳು ಪ್ರತಿ ಬಳಕೆಗೆ ಶುಲ್ಕ ವಿಧಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ದಾಳಿಕೋರನು ನಿಮ್ಮ ಬಿಲ್ ಅನ್ನು ಏರಿಸಬಹುದು ಅಥವಾ ನಿಮ್ಮ ಮಾದರಿಯ ನಕಲನ್ನು ನಿರ್ಮಿಸಬಹುದು.

OWASP ಈ ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು “ವೆಚ್ಚದ ಅಸಮತೆ” ಎಂದು ಕರೆಯುತ್ತದೆ. ಒಂದು ಚಿಕ್ಕ, ಅಗ್ಗದ ವಿನಂತಿಯು ನಿಮ್ಮ ಕಡೆ ದುಬಾರಿ ಗಣನೆಯನ್ನು ಪ್ರಚೋದಿಸಬಹುದು.

ಉದಾಹರಣೆ: ಮೇ 2024 ರಲ್ಲಿ, Sysdig ನ Threat Research Team “LLMjacking” ಎಂಬ ಹೊಸ ದಾಳಿಯನ್ನು ಪತ್ತೆಹಚ್ಚಿತು. ದಾಳಿಕೋರರ ಗುಂಪೊಂದು ಕದ್ದ ರುಜುವಾತುಗಳನ್ನು ಬಳಸಿ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಲಾದ 10 LLM ಸೇವೆಗಳನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿತು. ಅವರು Laravel ನ ದುರ್ಬಲ ಆವೃತ್ತಿಯ ಮೂಲಕ ಒಳನುಗ್ಗಿದರು, ನಂತರ ಆ ರುಜುವಾತುಗಳಿಂದ ಏನೆಲ್ಲಾ ಮಾಡಬಹುದು ಮತ್ತು ಯಾವ ಕೋಟಾಗಳಿವೆ ಎಂಬುದನ್ನು ಪತ್ತೆಹಚ್ಚಿದರು—ಪ್ರವೇಶವನ್ನು ಮಾರಾಟ ಮಾಡುವುದು ಅವರ ಸ್ಪಷ್ಟ ಉದ್ದೇಶವಾಗಿತ್ತು. ಬಹುಶಃ ಪತ್ತೆಯಾಗುವುದನ್ನು ತಪ್ಪಿಸಲು, ಅನೇಕ ಲಾಗಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನೂ ಪರಿಶೀಲಿಸಲಾಗಿತ್ತು. Sysdig ಪ್ರಕಾರ, ಅತ್ಯಂತ ಕೆಟ್ಟ ಸನ್ನಿವೇಶದಲ್ಲಿ ಇದು ಸಂತ್ರಸ್ತರಿಗೆ ದಿನಕ್ಕೆ $46,000 ಕ್ಕೂ ಹೆಚ್ಚು ವೆಚ್ಚ ಉಂಟುಮಾಡಬಹುದು.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• ಖರ್ಚನ್ನು ತಡೆಯುವ ಬಜೆಟ್‌ಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ: ಪ್ರತ್ಯೇಕ ಬಳಕೆದಾರರು, API ಕೀಗಳು, ತಂಡಗಳು ಮತ್ತು ಒಟ್ಟಾರೆ ಖಾತೆಗೆ ಕಟ್ಟುನಿಟ್ಟಾದ ಖರ್ಚು ಮಿತಿಗಳನ್ನು ಇರಿಸಿ. ವಿನಂತಿಗಳು ಎಲ್ಲಿಂದ ಪ್ರವೇಶಿಸಬಹುದೋ ಅಲ್ಲೆಲ್ಲಾ ಅವುಗಳನ್ನು ಜಾರಿಗೊಳಿಸಿ.
• ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಕ್ಕೂ ನಿಲುಗಡೆ ಬಿಂದುವನ್ನು ನೀಡಿ: ಒಂದು ಕಾರ್ಯ ಎಷ್ಟು ಹೊತ್ತು ಚಾಲನೆಯಲ್ಲಿರಬಹುದು, ಅದು ಎಷ್ಟು ಪಠ್ಯವನ್ನು ಸಂಸ್ಕರಿಸಬಹುದು ಮತ್ತು ಉತ್ಪಾದಿಸಬಹುದು, ಮತ್ತು ಅದು ಎಷ್ಟು ಉಪಕರಣ ಕರೆಗಳನ್ನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಸೀಮಿತಗೊಳಿಸಿ. ಒಂದೇ ಕೆಲಸವನ್ನು ಪುನರಾವರ್ತಿಸುವ ಅಥವಾ ತಮ್ಮ ಮಿತಿಯನ್ನು ಮೀರುವ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಸ್ವಯಂಚಾಲಿತ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸೇರಿಸಿ.

7. ಕ್ರಮ ಕೈಗೊಳ್ಳುವ ಮೊದಲು ತಪ್ಪು ಮಾಹಿತಿಯನ್ನು ಪತ್ತೆಹಚ್ಚಿ

AI ಸರಿಯೆನಿಸುವ ಆದರೆ ಸುಳ್ಳಾದ ಏನನ್ನಾದರೂ ಉತ್ಪಾದಿಸಿದಾಗ, ಮತ್ತು ಯಾರಾದರೂ, ಅಥವಾ ಯಾವುದಾದರೂ ವ್ಯವಸ್ಥೆ, ಅದರ ಆಧಾರದ ಮೇಲೆ ಕ್ರಮ ಕೈಗೊಂಡಾಗ, ಅದನ್ನು ತಪ್ಪು ಮಾಹಿತಿ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಮುಖ್ಯ ಅಪಾಯ ತಪ್ಪು ಉತ್ತರವಷ್ಟೇ ಅಲ್ಲ, ಬದಲಿಗೆ ಆ ತಪ್ಪು ಉತ್ತರವನ್ನು ನಂಬಿ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದು.

ತಪ್ಪು ಮಾಹಿತಿಯ ಬಗ್ಗೆ ವೃತ್ತಿಪರರು ಚಿಂತಿಸಬೇಕಾದಷ್ಟು ಚಿಂತಿಸಿರಲಿಲ್ಲ ಎಂದು ಘಟನೆಗಳ ದಾಖಲೆ ಸೂಚಿಸುತ್ತದೆ. 2026 ರ ಆವೃತ್ತಿಯ ಆರಂಭಿಕ ಪತ್ರದ ಪ್ರಕಾರ, ಮತದಾರರು ಇದನ್ನು ಪಟ್ಟಿಯ ಕೆಳಭಾಗದ ಸಮೀಪ ಇರಿಸಿದ್ದರು, ಆದರೆ ನೈಜ ಘಟನೆಗಳ ಪ್ರಕಾರ ಇದು ಮೇಲ್ಭಾಗದ ಸಮೀಪದಲ್ಲಿದೆ.

ಉದಾಹರಣೆ: 2025 ರಲ್ಲಿ, Deloitte Australia A$440,000 ಮೌಲ್ಯದ ಸರ್ಕಾರಿ ಒಪ್ಪಂದದಡಿ ಕಲ್ಯಾಣ IT ವ್ಯವಸ್ಥೆಗಳ ವಿಮರ್ಶೆಯನ್ನು ಸಲ್ಲಿಸಿತು. ಸಿಡ್ನಿ ವಿಶ್ವವಿದ್ಯಾಲಯದ ಸಂಶೋಧಕರಾದ ಕ್ರಿಸ್ ರಡ್ಜ್ ಅಸ್ತಿತ್ವದಲ್ಲೇ ಇಲ್ಲದ ಸಂಶೋಧನೆಯ ಉಲ್ಲೇಖಗಳನ್ನು ಮತ್ತು ಫೆಡರಲ್ ನ್ಯಾಯಾಲಯದ ತೀರ್ಪಿನಿಂದ ಕಲ್ಪಿತ ಉದ್ಧರಣೆಯೊಂದನ್ನು ಪತ್ತೆಹಚ್ಚಿದರು. Deloitte ತನ್ನ ಕಾರ್ಯವಿಧಾನದಲ್ಲಿ Azure OpenAI GPT-4o ಅನ್ನು ಬಳಸಿತ್ತು ಎಂದು ಪರಿಷ್ಕೃತ ವರದಿಯು ಬಹಿರಂಗಪಡಿಸಿತು, ಮತ್ತು ಸಂಸ್ಥೆಯು ಅಂತಿಮ ಕಂತನ್ನು ಮರುಪಾವತಿಸಲು ಒಪ್ಪಿಕೊಂಡಿತು. ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಒಂದು ಖಾತರಿ ವಿಮರ್ಶೆ (assurance review) ಆಗಿತ್ತು.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• ಪುರಾವೆಯು ಉತ್ತರವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ: ಹೇಳಿಕೆಗಳನ್ನು ಪ್ರಸ್ತುತ, ಅಧಿಕೃತ ಮೂಲಗಳ ಮೇಲೆ ಆಧರಿಸಿ. ನೀತಿ ಸಂಬಂಧಿತ ಉತ್ತರಕ್ಕಾಗಿ, ಅನುಮೋದಿತ ನೀತಿಯನ್ನು ಹಿಂಪಡೆದು, ಅದರ ವಿನಾಯಿತಿಗಳನ್ನೂ ಒಳಗೊಂಡಂತೆ ಅದು ತೀರ್ಮಾನವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
• ವ್ಯವಸ್ಥೆ ಕ್ರಮ ಕೈಗೊಳ್ಳುವ ಮೊದಲು ಪರಿಶೀಲಿಸಿ: ಗ್ರಾಹಕರು ಗುರುತಿನ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗಿದ್ದಾರೆ ಎಂದು ಏಜೆಂಟ್ ಹೇಳಿದರೆ, ಪಾವತಿಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ಅದನ್ನು ಪರಿಶೀಲನಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ದೃಢೀಕರಿಸಿ. ಮಹತ್ವದ ನಿರ್ಧಾರಗಳಿಗೆ ಮಾನವ ಅನುಮೋದನೆಯನ್ನು ಕಡ್ಡಾಯಗೊಳಿಸಿ, ಮತ್ತು ಪೂರಕ ಪುರಾವೆಗಳು ವಿಮರ್ಶಕರಿಗೆ ಲಭ್ಯವಿರುವಂತೆ ನೋಡಿಕೊಳ್ಳಿ.

8. ಗುಪ್ತ ಸಂದರ್ಭ ಬಹಿರಂಗಗೊಳ್ಳುವಿಕೆಯಿಂದಾಗುವ ಹಾನಿಯನ್ನು ಸೀಮಿತಗೊಳಿಸಿ

AI ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಬಳಕೆದಾರರು ಸಾಮಾನ್ಯವಾಗಿ ನೋಡದ ಸೂಚನೆಗಳು ಮತ್ತು ಹಿನ್ನೆಲೆ ಮಾಹಿತಿಯನ್ನು ಮಾದರಿಗೆ ನೀಡುತ್ತವೆ. ಇದರಲ್ಲಿ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ಆಂತರಿಕ ನೀತಿಗಳು, ಲಭ್ಯವಿರುವ ಉಪಕರಣಗಳ ವಿವರಣೆಗಳು, ಮತ್ತು ಅವುಗಳನ್ನು ಯಾರು ಬಳಸಬಹುದು ಎಂಬ ನಿಯಮಗಳು ಸೇರಿರಬಹುದು. ಮಾದರಿಯು ಆ ಮಾಹಿತಿಯನ್ನು ಯಾರಿಗಾದರೂ ಬಹಿರಂಗಪಡಿಸಿದಾಗ ಗುಪ್ತ ಸಂದರ್ಭ ಬಹಿರಂಗಗೊಳ್ಳುವಿಕೆ ಸಂಭವಿಸುತ್ತದೆ.

ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಹೊರಹೋಗಬಹುದಾದ ಮಾಹಿತಿಯ ಒಂದು ಭಾಗ ಮಾತ್ರ ಆಗಿರುವುದರಿಂದ, OWASP 2026 ರಲ್ಲಿ ಈ ನಮೂದನ್ನು “ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಸೋರಿಕೆ”ಯಿಂದ ವಿಸ್ತರಿಸಿತು. ಅಪಾಯವು ನೀವು ಅಲ್ಲಿ ಏನನ್ನು ಇರಿಸಿದ್ದೀರಿ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಸೋರಿಕೆಯಾದ ಬರವಣಿಗೆ-ಶೈಲಿಯ ಮಾರ್ಗದರ್ಶಿ ಸ್ವಲ್ಪ ಮುಜುಗರ ತರಬಹುದು, ಆದರೆ ಸೋರಿಕೆಯಾದ API ಕೀ ನಿಮ್ಮ ಗೌಪ್ಯ ಡೇಟಾಬೇಸ್‌ಗೆ ಯಾರಿಗಾದರೂ ಪ್ರವೇಶವನ್ನು ನೀಡುತ್ತದೆ.

ಉದಾಹರಣೆ: ಫೆಬ್ರವರಿ 2023 ರಲ್ಲಿ, ಬಳಕೆದಾರರು Microsoft ನ Bing Chat ತನ್ನ ಆಂತರಿಕ ಸೂಚನೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವಂತೆ ಮಾಡಿದರು. ಅಂತಹ ಒಂದು ಯಶಸ್ವಿ ಪ್ರಯತ್ನ ಮಾರ್ವಿನ್ ವಾನ್ ಹ್ಯಾಗನ್ ಅವರಿಂದ ಬಂದಿತು; ಅವರು ತಾವು OpenAI ಡೆವಲಪರ್ ಎಂದು ಹೇಳಿಕೊಂಡು, ಮಾದರಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಸೂಚನೆಗಳನ್ನು ಕೇಳಿದರು. Bing ತನ್ನ ಹುಡುಕಾಟಗಳು, ಪ್ರತಿಕ್ರಿಯೆಗಳು ಮತ್ತು ಸುರಕ್ಷತಾ ನಡವಳಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸುವ ನಿಯಮಗಳನ್ನು, ಜೊತೆಗೆ ತನ್ನ ಆಂತರಿಕ ಹೆಸರು Sydney ಅನ್ನು ಬಹಿರಂಗಪಡಿಸಿತು. ಬಹಿರಂಗವಾದ ಸೂಚನೆಗಳಲ್ಲಿ, ಆ ಸೂಚನೆಗಳನ್ನು ಗೌಪ್ಯವಾಗಿಡುವಂತೆ ಹೇಳುವ ಒಂದು ಸೂಚನೆಯೂ ಇತ್ತು.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• ರಹಸ್ಯ ಮಾಹಿತಿಯನ್ನು ಮಾಡೆಲ್‌ನ ಸಂದರ್ಭದಿಂದ ಹೊರಗಿಡಿ: ಮಾಡೆಲ್ ಓದಬಹುದಾದ ಯಾವುದೇ ವಿಷಯವು ಬಳಕೆದಾರರಿಗೆ ಗೋಚರಿಸಬಹುದು ಎಂದು ಭಾವಿಸಿ—ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, API ಕೀಗಳು ಮತ್ತು ಆಕ್ಸೆಸ್ ಟೋಕನ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ರಹಸ್ಯ ಮಾಹಿತಿ ನಿರ್ವಹಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ.
• ನಿಯಮಗಳು ಸೋರಿಕೆಯಾದರೂ ಅನುಮತಿಗಳು ಜಾರಿಯಲ್ಲಿರುವಂತೆ ಮಾಡಿ: ಆಕ್ಸೆಸ್ ಪರಿಶೀಲನೆಗಳನ್ನು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲಿಯೇ ಜಾರಿಗೊಳಿಸಿ. ಒಂದು ಟೂಲ್ ಅನ್ನು ನಿರ್ವಾಹಕರಿಗೆ ಮಾತ್ರ ಸೀಮಿತಗೊಳಿಸಿದ್ದರೆ, ಅದನ್ನು ಚಲಾಯಿಸುವ ಮೊದಲು ಬಳಕೆದಾರರ ಖಾತೆಯ ಅನುಮತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

9. ನಿಮ್ಮ ವೆಕ್ಟರ್‌ಗಳು ಮತ್ತು ಎಂಬೆಡಿಂಗ್‌ಗಳನ್ನು ಭದ್ರಪಡಿಸಿ

ನಿಮ್ಮ ಕಂಪನಿಯ ದಾಖಲೆಗಳಲ್ಲಿ ಉತ್ತರಗಳನ್ನು ಹುಡುಕಲು AI ವೆಕ್ಟರ್ ಸರ್ಚ್ ಬಳಸಿದಾಗ, ಅದು ಪಠ್ಯವನ್ನು ನೇರವಾಗಿ ಹುಡುಕುವುದಿಲ್ಲ. ದಾಖಲೆಗಳನ್ನು “ಎಂಬೆಡಿಂಗ್‌ಗಳು” ಆಗಿ ಪರಿವರ್ತಿಸಿ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಎಂಬೆಡಿಂಗ್‌ಗಳು ಎಂದರೆ ಪ್ರತಿಯೊಂದು ಭಾಗದ ಅರ್ಥವನ್ನು ಸೆರೆಹಿಡಿಯುವ ಸಂಖ್ಯೆಗಳ ಉದ್ದನೆಯ ಪಟ್ಟಿಗಳು. ಪ್ರಶ್ನೆಯನ್ನೂ ಇದೇ ರೀತಿಯಲ್ಲಿ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಯಾವ ಭಾಗಗಳ ಸಂಖ್ಯೆಗಳು ಅತ್ಯಂತ ಹತ್ತಿರದಲ್ಲಿವೆಯೋ ಆ ಭಾಗಗಳನ್ನು ವ್ಯವಸ್ಥೆಯು ಹೊರತೆಗೆಯುತ್ತದೆ.

ಇದು ವಿಫಲವಾಗುವ ನಾಲ್ಕು ವಿಧಾನಗಳನ್ನು OWASP ಹೀಗೆ ಸಂಕ್ಷೇಪಿಸುತ್ತದೆ: ಪಾಯ್ಸನಿಂಗ್ ವ್ಯವಸ್ಥೆಯು ತಪ್ಪು ಫಲಿತಾಂಶ ನೀಡುವಂತೆ ಮಾಡುತ್ತದೆ, ಇನ್ವರ್ಶನ್ ಅದು ಮಾಹಿತಿಯನ್ನು ಸೋರಿಕೆ ಮಾಡುವಂತೆ ಮಾಡುತ್ತದೆ, ಜಾಮಿಂಗ್ ಅದನ್ನು ಮೌನವಾಗಿಸುತ್ತದೆ, ಮತ್ತು ದೋಷಪೂರಿತ ಆಕ್ಸೆಸ್ ನಿಯಂತ್ರಣವು ಅದು ಯಾರಿಗೆ ಬೇಕಾದರೂ ಏನನ್ನು ಬೇಕಾದರೂ ಒಪ್ಪಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.

ಈ ಸಂಖ್ಯೆಗಳು ತೋರುವಷ್ಟು ಸುರಕ್ಷಿತ ಅಮೂರ್ತ ರೂಪವಲ್ಲ. ಸಂಗ್ರಹಿಸಲಾದ ಎಂಬೆಡಿಂಗ್‌ಗಳನ್ನು ಮತ್ತೆ ಪಠ್ಯವಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು, ಮತ್ತು ಒಂದು ವಿಧಾನವು ತನ್ನ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ 32-ಟೋಕನ್‌ಗಳ ಸಣ್ಣ ಭಾಗಗಳಲ್ಲಿ 92% ರಷ್ಟನ್ನು ನಿಖರವಾಗಿ ಮರುಪಡೆಯಿತು. ಹೀಗಾಗಿ, ಸೋರಿಕೆಯಾದ “ಎಂಬೆಡಿಂಗ್‌ಗಳು-ಮಾತ್ರ” ಬ್ಯಾಕಪ್ ಕೂಡ ದಾಖಲೆಗಳ ವಿಷಯವನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು.

ಉದಾಹರಣೆ: USENIX Security 2025 ರಲ್ಲಿ ಮಂಡಿಸಲಾದ ಸಂಶೋಧನೆಯಲ್ಲಿ, ಎಚ್ಚರಿಕೆಯಿಂದ ರೂಪಿಸಲಾದ ಒಂದೇ ಒಂದು ದಾಖಲೆಯು ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆಗೆ AI ಉತ್ತರಿಸುವುದನ್ನು ತಡೆಯಬಲ್ಲದು ಎಂದು ಸಂಶೋಧಕರು ತೋರಿಸಿದರು. AI ಹುಡುಕುತ್ತಿದ್ದ ಸಂಗ್ರಹಕ್ಕೆ ಅವರು ಆ ದಾಖಲೆಯನ್ನು ಸೇರಿಸಿದರು. AI ಅದನ್ನು ಕಂಡುಕೊಂಡಾಗ, ತನ್ನ ಬಳಿ ಸಾಕಷ್ಟು ಮಾಹಿತಿ ಇಲ್ಲ ಅಥವಾ ಉತ್ತರಿಸುವುದು ಅಸುರಕ್ಷಿತ ಎಂದು ಅದು ಹೇಳಬಹುದಿತ್ತು. ತನ್ನ ನಿಯಮಗಳನ್ನು ಕಡೆಗಣಿಸುವಂತೆ AI ಗೆ ಹೇಳುವ ಅಗತ್ಯವೂ ಆ ದಾಖಲೆಗೆ ಇರಲಿಲ್ಲ. ಇದನ್ನು “ರಿಟ್ರೀವಲ್ ಜಾಮಿಂಗ್” ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• ಸಾರ್ವಜನಿಕ ಮತ್ತು ಖಾಸಗಿ ಡೇಟಾಗೆ ಪ್ರತ್ಯೇಕ ಇಂಡೆಕ್ಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಿ: ವೆಬ್‌ನಿಂದ ಸ್ಕ್ರೇಪ್ ಮಾಡಿದ ವಿಷಯವನ್ನು ಪಾಲುದಾರರ ಡೇಟಾ ಅಥವಾ ಗೌಪ್ಯ ಆಂತರಿಕ ದಾಖಲೆಗಳೊಂದಿಗೆ ಬೆರೆಸಬೇಡಿ. ಒಂದೇ ಇಂಡೆಕ್ಸ್‌ನಲ್ಲಿ ವಿಷಯವನ್ನು ಟ್ಯಾಗ್ ಮಾಡುವ ಬದಲು, ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಮಟ್ಟಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಭೌತಿಕವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿ. ಇದು ಒಂದು ಇಡೀ ವರ್ಗದ ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ, ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನಿಂದ ಸ್ಕ್ರೇಪ್ ಮಾಡಿದ ವಿಷಯವು ನಿಮ್ಮ ಆಡಳಿತ ಮಂಡಳಿಯ ದಾಖಲೆಗಳ ಪಕ್ಕದಲ್ಲಿ ಸೇರುವ ಸಾಧ್ಯತೆಯೇ ಇರುವುದಿಲ್ಲ.
• ಎಂಬೆಡಿಂಗ್‌ಗಳನ್ನು ಅವುಗಳ ಮೂಲ ದಾಖಲೆಗಳಂತೆಯೇ ಪರಿಗಣಿಸಿ: ಅವುಗಳನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿ, ಮೂಲ ಫೈಲ್‌ಗಳ ಜೊತೆಗೆ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ ಬ್ಯಾಕಪ್‌ಗಳನ್ನೂ ಸಂರಕ್ಷಿಸಿ, ಮತ್ತು ಮೂಲ ದಾಖಲೆಯನ್ನು ಅಳಿಸಿದಾಗ ಅದರ ಎಂಬೆಡಿಂಗ್‌ಗಳನ್ನೂ ಅಳಿಸಿ. ನಿಮ್ಮ ಎಂಬೆಡಿಂಗ್ ಸೇವೆಯ API ಕೀಗಳನ್ನು ರಹಸ್ಯವಾಗಿಡಬೇಕು.

10. AI ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮುಂದಕ್ಕೆ ರವಾನಿಸುವ ಮೊದಲು ಪರಿಶೀಲಿಸಿ

ಒಂದು ಅಪ್ಲಿಕೇಶನ್ AI ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮತ್ತೊಂದು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಬಳಸಲು ಸುರಕ್ಷಿತವೇ ಎಂದು ಪರಿಶೀಲಿಸದೆ ಅದಕ್ಕೆ ರವಾನಿಸಿದಾಗಲೆಲ್ಲಾ, ಅದು LLM ಔಟ್‌ಪುಟ್ ಅನ್ನು ಅಸಮರ್ಪಕವಾಗಿ ನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದರ್ಥ.

AI ಕೋಡಿಂಗ್ ಸಹಾಯಕಗಳು ದೊಡ್ಡ ಪ್ರಮಾಣದಲ್ಲಿ ರಚಿಸುವ ಅಸುರಕ್ಷಿತ ಕೋಡ್ ಅನ್ನೂ ಈ ನಮೂದು ಒಳಗೊಂಡಿದೆ. ಆದ್ದರಿಂದ, ಸಹಾಯಕವು ಬರೆಯುವ ಪ್ರತಿಯೊಂದು ಸಾಲೂ ಕೂಡ ಔಟ್‌ಪುಟ್ ಆಗಿದೆ.

ಉದಾಹರಣೆ: 2025 ರಲ್ಲಿ, Sourcegraph ನ Amp ಕೋಡಿಂಗ್ ಸಹಾಯಕವು ಕೇವಲ ಒಂದು ಚಿತ್ರವನ್ನು ಪ್ರದರ್ಶಿಸುವ ಮೂಲಕ ಚಾಟ್ ವಿಷಯವನ್ನು ಹೇಗೆ ಸೋರಿಕೆ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ಸಂಶೋಧಕ Johann Rehberger ತೋರಿಸಿದರು. ಚಿತ್ರವೊಂದರ ವೆಬ್ ವಿಳಾಸದಲ್ಲಿ Amp ಖಾಸಗಿ ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸುವಂತೆ ಮಾಡಲು ಅವರು ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್ ಬಳಸಿದರು. ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ಆ ಚಿತ್ರವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತರಿಸಿಕೊಂಡಿತು, ಹೀಗೆ ಮಾಹಿತಿಯನ್ನು ಅವರ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಿತು. ಔಟ್‌ಪುಟ್ ನಿರ್ವಹಣೆಯ ವೈಫಲ್ಯವೆಂದರೆ ಆ ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿ—ಮಾಡೆಲ್ ರಚಿಸಿದ ಪಠ್ಯವು ಹೊರಗಿನ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕವಾಗಿ ಮಾರ್ಪಟ್ಟು, ತನ್ನೊಂದಿಗೆ ಖಾಸಗಿ ಡೇಟಾವನ್ನು ಕೊಂಡೊಯ್ದಿತು.

ನೀವು ಏನು ಮಾಡಬಹುದು:

• ಔಟ್‌ಪುಟ್ ಅನ್ನು ಅದರ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸುರಕ್ಷಿತವಾಗಿಸಿ: ಪ್ರತಿಕ್ರಿಯೆಗಳು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಅವುಗಳನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ನಿರ್ವಹಿಸಿ. ವೆಬ್‌ಪುಟಕ್ಕಾಗಿ, ರಚಿತ ಪಠ್ಯವು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಕೋಡ್ ಆಗುವುದನ್ನು ತಡೆಯಿರಿ. ಡೇಟಾಬೇಸ್‌ಗಾಗಿ, ಒದಗಿಸಲಾದ ಮೌಲ್ಯಗಳನ್ನು ಕಮಾಂಡ್‌ಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡುವ ಪ್ರಿಪೇರ್ಡ್ ಕ್ವೆರಿಗಳನ್ನು ಬಳಸಿ.
• ಉತ್ತರಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊರಗಿನ ಸಂಪರ್ಕಗಳನ್ನು ಮಾಡುವುದನ್ನು ತಡೆಯಿರಿ: ಮಾಡೆಲ್ ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿ ಚಿತ್ರಗಳು, ಲಿಂಕ್ ಪ್ರಿವ್ಯೂಗಳು ಮತ್ತು ಎಂಬೆಡ್ ಮಾಡಿದ ಪುಟಗಳ ಸ್ವಯಂಚಾಲಿತ ಲೋಡಿಂಗ್ ಅನ್ನು ಡೀಫಾಲ್ಟ್ ಆಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ. ಅಗತ್ಯ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಅನುಮೋದಿಸಲಾದ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಮಾತ್ರ ಸೀಮಿತಗೊಳಿಸಿ.

Perplexity ಹೇಗೆ LLM ಗಳನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುತ್ತದೆ?

ಮೇಲಿನ ಪ್ರತಿಯೊಂದು ಅಪಾಯವೂ ಅಂತಿಮವಾಗಿ ಎದುರಾಗುತ್ತದೆ ಎಂದೇ ನಾವು ಭಾವಿಸುತ್ತೇವೆ, ಮತ್ತು ಅದು ಎದುರಾದಾಗ ಹೆಚ್ಚು ಹಾನಿ ಮಾಡದಂತೆ ನಾವು ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತೇವೆ. ಇದನ್ನು ಹೇಗೆ ಮಾಡುತ್ತೇವೆ ಎಂಬುದನ್ನು ನಮ್ಮ CISO, Kyle Polley ಅವರು ಇತ್ತೀಚಿನ ಕಾರ್ಯಾಗಾರವೊಂದರಲ್ಲಿ ವಿವರಿಸಿದರು.

• ಏಜೆಂಟ್‌ಗೆ ತನ್ನದೇ ಆದ ಕಂಪ್ಯೂಟರ್ ಸಿಗುತ್ತದೆ, ಮತ್ತು ಅದು ಖಾಲಿಯಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಲಾದ ಏಜೆಂಟ್ ಟೂಲ್‌ಗಳು ಅದರಲ್ಲಿರುವ ಫೈಲ್‌ಗಳು, ಆ್ಯಪ್‌ಗಳು ಮತ್ತು ಉಳಿಸಲಾದ ರುಜುವಾತುಗಳಿಗೆ ಆಕ್ಸೆಸ್ ಪಡೆಯಬಹುದು. Perplexity Computer ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಕಾರ್ಯವೂ ತನ್ನದೇ ಆದ ಪ್ರತ್ಯೇಕ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, ಮತ್ತು Polley ಅವರು ಹೇಳುವಂತೆ, “ಡೀಫಾಲ್ಟ್ ಆಗಿ ಅದಕ್ಕೆ ಯಾವುದಕ್ಕೂ ಆಕ್ಸೆಸ್ ಇರುವುದಿಲ್ಲ.”
• ಏಜೆಂಟ್ ಎಂದಿಗೂ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ: ಸಂಪರ್ಕಿತ ಸೇವೆಗಳ ರುಜುವಾತುಗಳನ್ನು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಏಜೆಂಟ್ GitHub ನಂತಹ ಸೇವೆಯನ್ನು ತಲುಪಬೇಕಾದಾಗ, ಅದು ಯಾವುದೇ ರುಜುವಾತುಗಳನ್ನು ಲಗತ್ತಿಸದೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ವಿನಂತಿ ತಾನು ನಿರೀಕ್ಷಿಸಿದಂತೆಯೇ ಇವೆಯೇ ಎಂದು ಗೇಟ್‌ವೇ ಪರಿಶೀಲಿಸುತ್ತದೆ, ನಂತರ ವಿನಂತಿ ಹೊರಹೋಗುವಾಗ ರುಜುವಾತುಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ಹೀಗೆ ಏಜೆಂಟ್ ಕೀಗಳನ್ನು ಪಡೆಯದೆಯೇ ಸಂಪರ್ಕವನ್ನು ಬಳಸಬಹುದು.
• ನಿಮ್ಮ ಅನುಮತಿಗಳು ಹಾಗೆಯೇ ಮುಂದುವರಿಯುತ್ತವೆ, ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಇನ್ನಷ್ಟು ಬಿಗಿಗೊಳಿಸಬಹುದು: OAuth ಮೂಲಕ ಮಾಡಿದ ಸಂಪರ್ಕಗಳು ಸಂಪರ್ಕಿತ ಸೇವೆಯಲ್ಲಿನ ನಿಮ್ಮ ಆಕ್ಸೆಸ್ ಅನುಮತಿಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತವೆ. ನಿಮಗೆ ಏನನ್ನಾದರೂ ನೋಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಿಮ್ಮ ಏಜೆಂಟ್‌ಗೂ ಸಾಧ್ಯವಿಲ್ಲ.
• ಪ್ರತಿಯೊಂದು ವೆಬ್ ಪುಟವನ್ನೂ ಅಪರಿಚಿತವೆಂದೇ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ: ನಾವು ಪರೀಕ್ಷಿಸಿದ ಟೂಲ್‌ಗಳು ನೈಜ ಬಳಕೆಯಲ್ಲಿ ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸದ ಕಾರಣ, ನಮ್ಮ ಏಜೆಂಟಿಕ್ ಬ್ರೌಸರ್ Comet ಗಾಗಿ ನಾವು BrowseSafe ಅನ್ನು ನಿರ್ಮಿಸಿದೆವು. ಬ್ರೌಸರ್ ವೆಬ್ ಪುಟಗಳನ್ನು ಮತ್ತು ಇಮೇಲ್‌ಗಳು ಸೇರಿದಂತೆ ಇತರ ಹೊರಗಿನ ವಿಷಯವನ್ನು ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್‌ಗಾಗಿ ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತದೆ. ನಾವು ಮಾಡೆಲ್ ಮತ್ತು ಡೇಟಾಸೆಟ್ ಎರಡನ್ನೂ ಓಪನ್-ಸೋರ್ಸ್ ಮಾಡಿದ್ದೇವೆ.
• ನಾವು ಏಜೆಂಟ್ ಅನ್ನು ಮತ್ತು ಅದು ಚಲಿಸುವ ಯಂತ್ರಗಳನ್ನು ಗಮನಿಸುತ್ತೇವೆ: ಏಜೆಂಟ್ ಒಂದು ಕ್ರಿಯೆಯನ್ನು ಕೈಗೊಳ್ಳಲು ನಿರ್ಧರಿಸುವ ಮತ್ತು ಟೂಲ್ ನಿಜವಾಗಿ ಚಲಿಸುವ ಹಂತಗಳ ನಡುವೆ Numbat ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. Numbat ಬೆಂಬಲಿತ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್‌ಗಳಾದ್ಯಂತ ಚಟುವಟಿಕೆಯನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ನೀತಿಗಳನ್ನು ಉಲ್ಲಂಘಿಸುವ ಕ್ರಿಯೆಗಳನ್ನು ಅವು ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಮೊದಲೇ ನಿರ್ಬಂಧಿಸಬಹುದು. Bumblebee ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗಳು, ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಬಿಲ್ಡ್ ಪೈಪ್‌ಲೈನ್‌ಗಳಾದ್ಯಂತ ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ಯಾಕೇಜ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ ಮತ್ತು ತಿಳಿದಿರುವ ದುರುದ್ದೇಶಪೂರಿತ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ. ಇವೆರಡೂ ಓಪನ್ ಸೋರ್ಸ್ ಆಗಿವೆ.
• ಮಾಡೆಲ್ ಪೂರೈಕೆದಾರರು ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದಿಲ್ಲ: ನಮ್ಮ ಮೂರನೇ-ಪಕ್ಷದ LLM ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ನಾವು ಶೂನ್ಯ ಡೇಟಾ ಧಾರಣಾ ಒಪ್ಪಂದಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. Enterprise ನಿರ್ವಾಹಕರು Perplexity ಯ ಸ್ವಂತ ಡೇಟಾ ಧಾರಣಾ ಅವಧಿಯನ್ನು ಕೇವಲ 24 ಗಂಟೆಗಳಷ್ಟು ಕಡಿಮೆಗೂ ಹೊಂದಿಸಬಹುದು.

Polley ಅವರು ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಸಂಕ್ಷೇಪಿಸುವ ಕಾರಣಕ್ಕಾಗಿ ನಾವು Numbat ಅನ್ನು ಮುಂಚಿತವಾಗಿಯೇ ನಿರ್ಮಿಸಿದೆವು: “ನೀವು ಏಜೆಂಟ್‌ಗೆ ಹೆಚ್ಚು ಸ್ವಾಯತ್ತತೆ ನೀಡಿದಷ್ಟೂ, ಅಪಾಯವೂ ಹೆಚ್ಚಾಗುತ್ತದೆ.”

LLM ಭದ್ರತೆ ಕುರಿತು ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

ಅತ್ಯಂತ ಸುರಕ್ಷಿತ LLM ಯಾವುದು?

ಯಾವುದೇ LLM ತಾನಾಗಿಯೇ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುವುದಿಲ್ಲ—ಮಾಡೆಲ್‌ಗಳು ತಾವು ಓದಬೇಕಾದ ವಿಷಯವನ್ನು ತಾವು ಪಾಲಿಸಬೇಕಾದ ಸೂಚನೆಗಳೆಂದು ಈಗಲೂ ತಪ್ಪಾಗಿ ಭಾವಿಸಬಹುದು. ಪ್ರಮಾಣಿತ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಬಲಿಷ್ಠವಾಗಿ ಕಾಣುವ ರಕ್ಷಣಾ ಕ್ರಮಗಳು ಒತ್ತಡಕ್ಕೆ ಸಿಲುಕಿದಾಗ ಕುಸಿಯಲೂಬಹುದು.

ನಿಮ್ಮ ಬಳಕೆಯ ಸಂದರ್ಭಕ್ಕೆ ಯಾವ ಸೆಟಪ್ ಅತ್ಯಂತ ಸುರಕ್ಷಿತ ಎಂಬುದೇ ಉತ್ತಮ ಪ್ರಶ್ನೆ. ಅಂದರೆ, ಸೀಮಿತ ಅನುಮತಿಗಳು, ಮಾಡೆಲ್‌ನಿಂದ ದೂರವಿರಿಸಲಾದ ರುಜುವಾತುಗಳು, ಅಪಾಯಕಾರಿ ಕ್ರಿಯೆಗಳಿಗೆ ಮಾನವ ಅನುಮೋದನೆ, ಮತ್ತು ನಿಮ್ಮ ರಕ್ಷಣಾ ಕ್ರಮಗಳನ್ನು ಚೆನ್ನಾಗಿ ಬಲ್ಲವರಿಂದ ಪರೀಕ್ಷೆ.

LLM ದುರ್ಬಲತೆಗಳು ಎಂದರೇನು?

LLM ದುರ್ಬಲತೆಗಳು ಎಂದರೆ, ದಾಳಿಕೋರರಿಂದಾಗಲಿ ಅಥವಾ ತನ್ನದೇ ತಪ್ಪುಗಳಿಂದಾಗಲಿ, AI ವ್ಯವಸ್ಥೆಯು ಮೋಸಹೋಗಲು, ಡೇಟಾ ಸೋರಿಕೆ ಮಾಡಲು ಅಥವಾ ಹಾನಿಯನ್ನುಂಟುಮಾಡಲು ಅವಕಾಶ ನೀಡುವ ದೌರ್ಬಲ್ಯಗಳು.

ಹತ್ತು ಪ್ರಮುಖ ಅಪಾಯಗಳೆಂದರೆ ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್, ಸೂಕ್ಷ್ಮ ಮಾಹಿತಿಯ ಬಹಿರಂಗಪಡಿಸುವಿಕೆ, ಅತಿಯಾದ ಸ್ವಾಯತ್ತತೆ, ಪೂರೈಕೆ ಸರಪಳಿ, ಡೇಟಾ ಮತ್ತು ಮಾಡೆಲ್ ಪಾಯ್ಸನಿಂಗ್, ಮಿತಿಯಿಲ್ಲದ ಬಳಕೆ, ತಪ್ಪು ಮಾಹಿತಿ, ಗುಪ್ತ ಸಂದರ್ಭದ ಬಹಿರಂಗಗೊಳ್ಳುವಿಕೆ, ವೆಕ್ಟರ್ ಮತ್ತು ಎಂಬೆಡಿಂಗ್ ದೌರ್ಬಲ್ಯಗಳು, ಮತ್ತು ಅಸಮರ್ಪಕ ಔಟ್‌ಪುಟ್ ನಿರ್ವಹಣೆ.

ಖಾಸಗಿ LLM ಸುರಕ್ಷಿತವೇ?

ಕೆಲವು ವಿಷಯಗಳಿಗೆ ಇದು ಹೆಚ್ಚು ಸುರಕ್ಷಿತ ಆಯ್ಕೆ, ಆದರೆ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಅಲ್ಲ. ನಿಮ್ಮ ಸ್ವಂತ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಅಥವಾ ಕ್ಲೌಡ್ ಪರಿಸರದಲ್ಲಿ ಮಾಡೆಲ್ ಅನ್ನು ಚಲಾಯಿಸಿದರೆ, ಡೇಟಾ ನಿರ್ವಹಣೆಯ ಮೇಲೆ ನಿಮಗೆ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣವಿರುತ್ತದೆ. ಆದರೆ ಪ್ರಾಂಪ್ಟ್ ಇಂಜೆಕ್ಷನ್‌ಗಳು, ಅತಿಯಾದ ಸ್ವಾಯತ್ತತೆ, ಪಾಯ್ಸನಿಂಗ್ ಅಥವಾ ತಪ್ಪು ಮಾಹಿತಿಯನ್ನು ತಡೆಯಲು ಯಾವುದೇ ಸ್ವಯಂಚಾಲಿತ ಮಾರ್ಗವಿಲ್ಲ.

ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್‌ನ ಭಾಗವಾಗಿ, ನೀವು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ಮಾಡೆಲ್‌ಗೆ, ಅದರ ಪೂರೈಕೆ ಸರಪಳಿ ಅಪಾಯಗಳು ಮತ್ತು ಅದಕ್ಕೆ ಅಗತ್ಯವಿರುವ ಮೂಲಸೌಕರ್ಯವೂ ಸೇರಿದಂತೆ, ನೀವೇ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತೀರಿ.