ਤੁਹਾਡਾ AI-ਸੰਚਾਲਿਤ ਸਹਾਇਕ ਲਗਭਗ 99% ਸਮੇਂ ਆਪਣੀਆਂ ਹਦਾਇਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ, ਪਰ ਉਹ ਗੁੰਮ ਹੋਇਆ 1% ਉਹ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਹਮਲਾਵਰ ਹਮਲਾ ਕਰਦੇ ਹਨ। ਇੱਕ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਪ੍ਰੋਂਪਟ (crafted prompt) ਦੇ ਕੇ, ਇੱਕ ਮਾੜਾ ਯੂਜ਼ਰ ਮਾਡਲ ਨੂੰ ਅਜਿਹੇ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਉਸਨੂੰ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ, ਜਿਸ ਨਾਲ ਡੇਟਾ ਚੋਰੀ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਵਾਲੇ ਕਾਰਜ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਇਸਦਾ ਹੱਲ ਵਧੇਰੇ ਨਿਮਰ ਸ਼ਬਦਾਵਲੀ ਨਹੀਂ ਹੈ—ਇਸਦਾ ਹੱਲ ਇਸ ਖਾਮੀ ਨੂੰ ਇੱਕ ਅਧਿਕਾਰ (authorization) ਦੀ ਸਮੱਸਿਆ ਵਜੋਂ ਦੇਖਣਾ ਅਤੇ ਮਾਡਲ ਦੀ ਪਹੁੰਚ ਤੋਂ ਖ਼ਤਰਨਾਕ ਟੂਲਸ ਨੂੰ ਹਟਾਉਣਾ ਹੈ।
ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਸਿਰਫ਼ ਸ਼ਬਦਾਵਲੀ ਦੀ ਸਮੱਸਿਆ ਕਿਉਂ ਨਹੀਂ ਹੈ
ਡਿਵੈਲਪਰ ਅਕਸਰ ਐਜੰਟਾਂ ਨੂੰ ਵੱਡੇ ਅੱਖਰਾਂ ਵਾਲੀ ਚੇਤਾਵਨੀ, ਨੰਬਰਾਂ ਵਾਲੇ ਨਿਯਮ, ਜਾਂ "ਐਡਮਿਨ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕਾਲ ਨਾ ਕਰੋ" ਵਰਗੇ ਕਲੌਜ਼ਾਂ ਨਾਲ ਮਜ਼ਬੂਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਇਹ ਰੱਖਿਆਵਾਂ ਇਹ ਮੰਨ ਕੇ ਚੱਲਦੀਆਂ ਹਨ ਕਿ ਮਾਡਲ ਉਸ ਵਾਕ ਦੀ ਪਾਲਣਾ ਕਰੇਗਾ ਜੋ ਕਹਿੰਦਾ ਹੈ "X ਨਾ ਕਰੋ।" ਅਸਲ ਵਿੱਚ, ਬੇਨਤੀ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਕੇ, ਕਿਸੇ ਵੱਖਰੇ ਕਿਰਦਾਰ (persona) ਦਾ ਰੋਲ-ਪਲੇਅ ਕਰਕੇ, ਜਾਂ ਸਿਰਫ਼ ਵਾਧੂ ਸੰਦਰਭ (context) ਜੋੜ ਕੇ ਮਾਡਲ ਨੂੰ ਹਦਾਇਤ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਲਈ ਮਨਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਅੰਗਰੇਜ਼ੀ ਦੀ ਸੀਮਾ ਨੂੰ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ; ਹਮਲਾਵਰ ਦਾ ਪ੍ਰੋਂਪਟ ਅਸੀਮਤ ਹੈ ਅਤੇ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਕੋਈ ਖਰਚਾ ਨਹੀਂ ਲੱਗਦਾ।
ਅਸਲ ਕਮਜ਼ੋਰੀ ਉਸ ਟੂਲ ਲਿਸਟ ਵਿੱਚ ਹੈ ਜੋ ਐਜੰਟ ਨੂੰ ਮਿਲਦੀ ਹੈ। ਜਦੋਂ ਪ੍ਰੋਂਪਟ ਸਕੀਮਾ ਵਿੱਚ ਅਜਿਹਾ ਫੰਕਸ਼ਨ ਹੁੰਦਾ ਹੈ ਜੋ ਐਡਮਿਨ ਅਧਿਕਾਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਮਾਡਲ ਕੋਲ ਹੁਣ ਉਸ ਸ਼ਕਤੀ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਇੱਕ ਨਕਸ਼ਾ ਹੁੰਦਾ ਹੈ। ਭਾਵੇਂ ਪ੍ਰੋਂਪਟ ਕਹਿੰਦਾ ਹੋਵੇ ਕਿ "ਗਾਹਕਾਂ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ," ਮਾਡਲ ਨੂੰ ਫਿਰ ਵੀ ਇਸਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਮਨਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਫੰਕਸ਼ਨ ਉਸਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਐਨਵਾਇਰਨਮੈਂਟ ਵਿੱਚ ਮੌਜੂਦ ਹੈ। ਇਸ ਲਈ ਸਮੱਸਿਆ ਇੱਕ ਅਧਿਕਾਰ (authorization) ਦੀ ਘਾਟ ਹੈ: ਸਿਸਟਮ ਇੱਕ ਅਜਿਹੇ ਕਾਲਰ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਸਮਰੱਥਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸ ਕੋਲ ਉਹਨਾਂ ਦਾ ਕੋਈ ਅਧਿਕਾਰ ਨਹੀਂ ਹੈ।
ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਸੀਮਤ ਕਰਕੇ ਐਜੰਟਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ
ਇਸ ਘਾਟ ਨੂੰ ਭਰਨ ਦਾ ਸਭ ਤੋਂ ਸੌਖਾ ਤਰੀਕਾ ਮਾਡਲ ਨੂੰ ਉਹਨਾਂ ਟੂਲਸ ਤੱਕ ਪਹੁੰਚ ਦੇਣਾ ਬੰਦ ਕਰਨਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਉਸ ਕੋਲ ਅਧਿਕਾਰ ਨਹੀਂ ਹੈ। ਟੂਲ ਲਿਸਟ ਨੂੰ ਇੱਕ API key ਵਜੋਂ ਸਮਝੋ: ਜੇਕਰ ਕੀ (key) ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਤਾਂ ਕਾਲ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਕੋਈ ਵੀ ਚਲਾਕ ਸ਼ਬਦਾਵਲੀ ਉਸ ਫੰਕਸ਼ਨ ਨੂੰ ਨਹੀਂ ਬੁਲਾ ਸਕਦੀ ਜੋ ਮੌਜੂਦ ਸੰਦਰਭ ਵਿੱਚ ਨਹੀਂ ਹੈ।
ਗਲਤ ਤਰੀਕਾ
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 ਕਦੇ ਵੀ ਸਾਹਮਣੇ ਨਹੀਂ ਆਉਂਦਾ, ਇਸ ਲਈ ਮਾਡਲ ਕੋਲ ਇਸਨੂੰ ਕਾਲ ਕਰਨ ਦਾ ਕੋਈ ਰਸਤਾ ਨਹੀਂ ਹੁੰਦਾ।
ਡਿਵੈਲਪਰਾਂ ਲਈ ਤਿੰਨ ਵਿਵਹਾਰਕ ਨਿਯਮ
- ਪ੍ਰਤੀ-ਬੇਨਤੀ ਟੂਲ ਲਿਸਟ ਬਣਾਓ – ਪ੍ਰਮਾਣਿਤ (authenticated) ਕਾਲਰ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਦੇ ਅਧਾਰ 'ਤੇ ਫੰਕਸ਼ਨ ਕੈਟਾਲਾਗ ਨੂੰ ਡਾਇਨਾਮਿਕ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕਰੋ। ਇੱਕ ਗਾਹਕ ਨੂੰ ਸਿਰਫ਼ ਉਹ ਫੰਕਸ਼ਨ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਹੈ; ਇੱਕ ਐਡਮਿਨ ਨੂੰ ਪੂਰਾ ਸੈੱਟ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।
- Fail closed (ਫੇਲ ਕਲੋਜ਼ਡ) – ਜੇਕਰ ਯੂਜ਼ਰ ਦੀ ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਤਾਂ ਇੱਕ ਆਮ "ਸਾਰੇ ਟੂਲ ਉਪਲਬਧ ਹਨ" ਦੀ ਬਜਾਏ ਇੱਕ ਖਾਲੀ ਲਿਸਟ ਵਾਪਸ ਕਰੋ। ਇਹ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਇੱਕ ਅਣ-ਪ੍ਰਮਾਣਿਤ ਬੇਨਤੀ ਕਦੇ ਵੀ ਅਣਚਾਹੇ ਸ਼ਕਤੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੀ।
- Avoid shared state (ਸਾਂਝੀ ਸਟੇਟ ਤੋਂ ਬਚੋ) – ਟੂਲ ਡੈਫੀਨੇਸ਼ਨਾਂ ਨੂੰ ਕੈਸ਼ (cache) ਕਰਦੇ ਸਮੇਂ, ਕਦੇ ਵੀ ਸਾਂਝੇ ਆਬਜੈਕਟ 'ਤੇ ਯੂਜ਼ਰ-ਵਿਸ਼ੇਸ਼ ਡੇਟਾ ਨਾ ਲਿਖੋ। ਕਾਪੀ-ਆਨ-ਰਾਈਟ (copy-on-write) ਜਾਂ ਪ੍ਰਤੀ-ਸੈਸ਼ਨ ਕਾਪੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਤਾਂ ਜੋ ਇੱਕ ਯੂਜ਼ਰ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਦੂਜੇ ਦੀ ਬੇਨਤੀ ਵਿੱਚ ਨਾ ਮਿਲ ਸਕਣ।
ਜੇਕਰ ਇੱਕ ਆਮ ਯੂਜ਼ਰ ਨੂੰ ਦਿਖਾਈ ਦੇਣ ਵਾਲਾ ਸਕੀਮਾ ਐਡਮਿਨ ਨੂੰ ਦਿਖਾਏ ਜਾਣ ਵਾਲੇ ਸਕੀਮਾ ਦੇ ਬਿਲਕੁਲ ਸਮਾਨ ਹੈ, ਤਾਂ ਸੁਰੱਖਿਆ ਸੀਮਾ ਅਜੇ ਵੀ ਪ੍ਰੋਂਪਟ ਟੈਕਸਟ ਹੀ ਹੈ, ਅਤੇ ਪ੍ਰੋਂਪਟ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੁਰੱਖਿਆ ਮਕੈਨਿਜ਼ਮ ਨਹੀਂ ਹਨ।
ਸਾਨੂੰ ਇੱਥੇ ਕੀ ਲੈ ਕੇ ਆਇਆ
ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਉਦੋਂ ਸਾਹਮਣੇ ਆਇਆ ਜਦੋਂ ਡਿਵੈਲਪਰਾਂ ਨੇ ਲਾਰਜ ਲੈਂਗੂਏਜ ਮਾਡਲ (LLMs) ਨੂੰ ਅਜਿਹੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਰਕਫਲੋ ਵਿੱਚ ਲਗਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਜਿਸ ਲਈ ਮਾਡਲ ਨੂੰ ਬਾਹਰੀ API ਨੂੰ ਕਾਲ ਕਰਨ, ਕੋਡ ਚਲਾਉਣ, ਜਾਂ ਡੇਟਾਬੇਸ ਨੂੰ ਸੋਧਣ ਦੀ ਲੋੜ ਸੀ। ਮਾਡਲ ਦੀ "ਤਰਕਸ਼ੀਲਤਾ" (reasoning) ਇੱਕ ਪ੍ਰੋਂਪਟ ਦੁਆਰਾ ਅਗਵਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਉਪਲਬਧ ਟੂਲਸ ਦੀ ਇੱਕ ਲਿਸਟ ਵੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਟੋਟਾਈਪਾਂ ਨੇ ਮੰਨ ਲਿਆ ਸੀ ਕਿ ਮਾਡਲ "ਗੈਰ-ਐਡਮਿਨਾਂ ਲਈ ਰਿਕਾਰਡ ਡਿਲੀਟ ਨਾ ਕਰੋ" ਵਰਗੇ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦੇ ਨਿਯਮ ਦੀ ਪਾਲਣਾ ਕਰੇਗਾ। ਹਮਲਾਵਰਾਂ ਨੇ ਜਲਦੀ ਹੀ ਸਾਬਤ ਕਰ ਦਿੱਤਾ ਕਿ ਕੁਝ ਵਾਧੂ ਵਾਕ ਉਹਨਾਂ ਨਿਯਮਾਂ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਮਾਡਲ ਉਹੀ ਡਿਲੀਟ ਫੰਕਸ਼ਨ ਕਾਲ ਕਰਨ ਲਈ ਮ
ਕੁਝ ਲੋਕ ਦਾਅਵਾ ਕਰਦੇ ਹਨ ਕਿ ਲੋੜੀਂਦੀ instruction engineering—ਲੇਅਰਡ ਪ੍ਰੋਂਪਟਸ, ਸਿਸਟਮ ਮੈਸੇਜ, ਅਤੇ ਰੀਇਨਫੋਰਸਮੈਂਟ ਲਰਨਿੰਗ ਫ੍ਰੌਮ ਹਿਊਮਨ ਫੀਡਬੈਕ (reinforcement learning from human feedback)—ਦੇ ਨਾਲ ਮਾਡਲ ਨੂੰ “ਨਾ ਕਰੋ” (do not) ਸ਼ਰਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਸਲੀਅਤ ਇਹ ਹੈ ਕਿ ਲੈਂਗੂਏਜ ਮਾਡਲ ਪ੍ਰੋਬੇਬਲਿਸਟਿਕ ਜਨਰੇਟਰ (probabilistic generators) ਹੁੰਦੇ ਹਨ; ਉਹ ਸਭ ਤੋਂ ਸੰਭਾਵਨਾਯੋਗ ਅਗਲੇ ਹਿੱਸੇ ਦਾ ਭਾਰ ਲੈਂਦੇ ਹਨ, ਨਾ ਕਿ ਕਿਸੇ ਸਖ਼ਤ ਸੁਰੱਖਿਆ ਨਿਯਮ ਦਾ। ਫਾਈਨ-ਟਿਊਨਡ ਗਾਰਡਰੇਲਜ਼ (fine-tuned guardrails) ਦੇ ਬਾਵਜੂਦ, ਇੱਕ ਨਵਾਂ ਤਰੀਕਾ ਜਾਂ ਸ਼ਬਦਾਵਲੀ (novel phrasing) ਨਿਕਲ ਸਕਦੀ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਹਮਲਾਵਰ ਬਿਨਾਂ ਕਿਸੇ ਲਾਗਤ ਦੇ ਲਗਾਤਾਰ ਕੋਸ਼ਿਸ਼ਾਂ ਕਰ ਸਕਦਾ ਹੋਵੇ। ਗਾਰਡਰੇਲਜ਼ ਸ਼ੋਰ (noise) ਨੂੰ ਘਟਾਉਣ ਲਈ ਲਾਭਦਾਇਕ ਹਨ ਪਰ ਇਹ ਰੱਖਿਆ ਦੀ ਇਕਲੌਤੀ ਲਾਈਨ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
- ਉਹ ਫਰੇਮਵਰਕਸ ਜੋ ਟੂਲ ਸਕੋਪਿੰਗ (tool scoping) ਨੂੰ ਫਸਟ-ਕਲਾਸ API ਵਜੋਂ ਪੇਸ਼ ਕਰਦੇ ਹਨ – ਨਵੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਉਮੀਦ ਰੱਖੋ ਜੋ ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਸਮਰੱਥਾਵਾਂ (per-user capabilities) ਨੂੰ ਘੋਸ਼ਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਗੀਆਂ ਅਤੇ ਪ੍ਰੋਂਪਟ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਆਪ ਫੰਕਸ਼ਨ ਲਿਸਟ ਨੂੰ ਛਾਂਟ ਦੇਣਗੀਆਂ।
- ਸਟੈਂਡਰਡਾਈਜ਼ਡ “ਫੰਕਸ਼ਨ ਮੈਨੀਫੈਸਟਸ” (function manifests) – ਉਦਯੋਗ ਸਮੂਹ ਇੱਕ JSON schema ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹਨ ਜੋ ਜਨਤਕ ਅਤੇ ਵਿਸ਼ੇਸ਼ (privileged) ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਰਿਕਵੈਸਟ-ਵਿਸ਼ੇਸ਼ ਮੈਨੀਫੈਸਟ ਬਣਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
- ਰਨਟਾਈਮ ਇਨਫੋਰਸਮੈਂਟ (Runtime enforcement) – ਕੁਝ ਪਲੇਟਫਾਰਮ ਸੈਂਡਬਾਕਸਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (sandboxed execution) ਨਾਲ ਪ੍ਰਯੋਗ ਕਰ ਰਹੇ ਹਨ ਜੋ ਪ੍ਰੋਂਪਟ ਸਕੋਪਿੰਗ ਤੋਂ ਇਲਾਵਾ ਇੱਕ ਦੂਜੀ ਲੇਅਰ ਜੋੜਦੇ ਹੋਏ, ਬੁਲਾਏ ਜਾ ਰਹੇ ਫੰਕਸ਼ਨ ਦੇ ਵਿਰੁੱਧ ਕਾਲਰ ਦੇ ਟੋਕਨ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ।
ਸਿੱਟਾ ਸਪੱਸ਼ਟ ਹੈ: ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ (prompt injection) ਨੂੰ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਦੀ ਖਾਮੀ (authorization flaw) ਵਜੋਂ ਮੰਨੋ। ਮਾਡਲ ਦੇ ਟੂਲਬਾਕਸ ਵਿੱਚੋਂ ਅਣਅਧਿਕਾਰਤ ਟੂਲਸ ਨੂੰ ਹਟਾ ਕੇ, ਤੁਸੀਂ ਉਸ ਅਟੈਕ ਸਰਫੇਸ (attack surface) ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦੇ ਹੋ ਜਿਸਦਾ ਫਾਇਦਾ ਚੁੱਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਇੱਕ ਚਲਾਕੀ ਨਾਲ ਲਿਖਿਆ ਗਿਆ ਪ੍ਰੋਂਪਟ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਂਪਟ ਵਿਵਹਾਰ ਦਾ ਮਾਰਗਦਰਸ਼ਨ ਕਰ ਸਕਦੇ ਹਨ; ਉਹ ਸਹੀ ਐਕਸੈਸ ਕੰਟਰੋਲ (access control) ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲੈ ਸਕਦੇ।