AI ਏਜੰਟਸ ਹੁਣ ਸਿਰਫ਼ ਚੈਟ ਵਿੰਡੋਜ਼ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਰਹੇ। ਉਹ ਹੁਣ ਮੀਟਿੰਗਾਂ ਬੁੱਕ ਕਰਦੇ ਹਨ, ਗਾਹਕਾਂ ਦੇ ਰਿਕਾਰਡ ਅਪਡੇਟ ਕਰਦੇ ਹਨ, ਅੰਦਰੂਨੀ ਡੇਟਾਬੇਸਾਂ ਨੂੰ ਕੁਐਰੀ ਕਰਦੇ ਹਨ, ਅਤੇ ਵਿੱਤੀ ਲੈਣ-ਦੇਣ ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੇ ਹਨ। ਸਲਾਹਕਾਰ ਤੋਂ ਆਪਰੇਟਰ ਬਣਨ ਦਾ ਇਹ ਬਦਲਾਅ ਜੋਖਮ (risk) ਬਾਰੇ ਸਭ ਕੁਝ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਸਾਫਟਵੇਅਰ ਸੁਝਾਅ ਦੇਣਾ ਬੰਦ ਕਰਕੇ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਹਰ API endpoint ਇੱਕ ਸੰਭਾਵੀ ਦਰਵਾਜ਼ਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਰਵਾਇਤੀ ਸੁਰੱਖਿਆ ਮਾਡਲ ਅਨੁਮਾਨਿਤ ਮਨੁੱਖੀ ਵਿਵਹਾਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਏ ਗਏ ਸਨ: ਇੱਕ ਵਿਅਕਤੀ ਲੌਗਇਨ ਕਰਦਾ ਹੈ, ਜਾਣੇ-ਪਛਾਣੇ ਰਸਤਿਆਂ ਰਾਹੀਂ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਲੌਗ ਆਊਟ ਕਰਦਾ ਹੈ। ਖੁਦਮੁਖਤਿਆਰ (Autonomous) ਏਜੰਟ ਉਹਨਾਂ ਪੈਟਰਨਾਂ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਦੇ। ਉਹ ਸਕਿੰਟਾਂ ਵਿੱਚ ਸੈਂਕੜੇ ਕਾਲਾਂ ਵਿੱਚ ਲੂਪ ਕਰਦੇ ਹਨ, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਵੱਖ-ਵੱਖ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ ਵੰਡੇ ਜਾਂਦੇ ਹਨ। API ਲੇਅਰ, ਜੋ ਅਸਲ ਵਿੱਚ ਮਨੁੱਖ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀਆਂ ਗਈਆਂ ਬੇਨਤੀਆਂ ਲਈ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸੀ, ਹੁਣ ਲਗਾਤਾਰ ਆਟੋਮੇਟਡ ਦਬਾਅ ਦਾ ਸਾਹਮਣਾ ਕਰ ਰਹੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੇ ਬਚਾਅ ਅਜੇ ਵੀ ਪਿਛਲੀ ਤਿਮਾਹੀ ਵਿੱਚ ਲਿਖੇ ਸਥਿਰ ਨਿਯਮਾਂ 'ਤੇ ਨਿਰਭਰ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਡੇਟਾ ਲੀਕ ਅਤੇ ਅਣਅਧਿਕਾਰਤ ਪਹੁੰਚ ਲਈ ਦਰਵਾਜ਼ਾ ਖੁੱਲ੍ਹਾ ਛੱਡ ਰਹੇ ਹੋ। ਤੁਹਾਨੂੰ ਅਜਿਹੇ ਰੀਅਲ-ਟਾਈਮ ਬਚਾਅ ਦੀ ਲੋੜ ਹੈ ਜੋ ਹਰ ਕਾਲ ਦਾ ਉਸ ਸਮੇਂ ਹੀ ਮੁਲਾਂਕਣ ਕਰੇ।
ਏਜੰਟ ਦੇ ਅਧਿਕਾਰਾਂ (Privileges) ਨੂੰ ਸੀਮਤ ਕਰੋ
ਏਜੰਟ ਤੈਲੇਸ਼ਨ (deployment) ਵਿੱਚ ਸਭ ਤੋਂ ਖ਼ਤਰਨਾਕ ਸ਼ਾਰਟਕੱਟ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ API key ਦੇਣਾ ਹੈ। ਇੱਕ ਕੀ (key) ਹਰ ਸਿਸਟਮ ਵਿੱਚ ਸਾਰੀ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਇੱਕ ਜ਼ਹਿਰੀਲੇ ਪ੍ਰੋਂਪਟ (poisoned prompt) ਜਾਂ ਹਾਈਜੈਕ ਕੀਤੇ ਇੰਟਿਗ੍ਰੇਸ਼ਨ ਰਾਹੀਂ ਏਜੰਟ ਨਾਲ ਛੇੜਛਾੜ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਾਰੇ ਸਿਸਟਮ ਦੀਆਂ ਚਾਬੀਆਂ ਹਾਸਲ ਕਰ ਲੈਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਸੁਧਾਰ ਕਰਨਾ ਇੱਕ ਦੁਸ਼ਵਾਰ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਦਾ ਪ੍ਰਭਾਵ (blast radius) ਤੁਹਾਡੀ ਈਮੇਲ ਸੇਵਾ ਤੋਂ ਲੈ ਕੇ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾਬੇਸ ਤੱਕ ਸਭ ਕੁਝ ਘੇਰ ਲੈਂਦਾ ਹੈ।
ਇਸ ਆਦਤ ਨੂੰ ਤੁਰੰਤ ਤੋੜੋ। ਡੈਲੀਗੇਟਡ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ (delegated authorization) ਲਈ OAuth 2.0 ਤੋਂ ਸ਼ੁਰੂਆਤ ਕਰੋ। ਏਜੰਟ ਨੂੰ ਇੱਕ ਸੁਤੰਤਰ ਸੁਪਰਯੂਜ਼ਰ (superuser) ਵਜੋਂ ਪ੍ਰਮਾਣਿਤ (authenticate) ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ। ਇਸ ਦੀ ਬਜਾਏ, ਇਸ ਕੋਲ ਇੱਕ ਅਜਿਹਾ ਟੋਕਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਏਜੰਟ ਅਤੇ ਉਸ ਉਪਭੋਗਤਾ (end user) ਦੋਵਾਂ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰੇ ਜਿਸਦੀ ਉਹ ਸੇਵਾ ਕਰ ਰਿਹਾ ਹੈ। ਜਦੋਂ ਮਨੁੱਖੀ ਸੈਸ਼ਨ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਏਜੰਟ ਦੀ ਪਹੁੰਚ ਵੀ ਉਸਦੇ ਨਾਲ ਹੀ ਖਤਮ ਹੋ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।
Token Exchange ਇਸ ਨੂੰ ਵਿਹਾਰਕ ਬਣਾਉਂਦਾ ਹੈ। ਅਜਿਹੇ ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ ਟੋਕਨ ਜਾਰੀ ਕਰੋ ਜੋ ਸਿਰਫ਼ ਉਹੀ ਸਕੋਪ (scope) ਰੱਖਦੇ ਹੋਣ ਜਿਸਦੀ ਏਜੰਟ ਨੂੰ ਇਸ ਸਮੇਂ ਲੋੜ ਹੈ। ਇੱਕ ਸ਼ਡਿਊਲਿੰਗ ਏਜੰਟ ਨੂੰ ਕੈਲੰਡਰ ਪੜ੍ਹਨ ਅਤੇ ਸੱਦਾ ਭੇਜਣ ਦੀ ਇਜਾਜ਼ਤ ਮਿਲ ਸਕਦੀ ਹੈ, ਪਰ ਕੈਲੰਡਰ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਨੂੰ ਡਿਲੀਟ ਕਰਨ ਜਾਂ ਪੇਰੋਲ APIs ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਨਹੀਂ। ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਟੋਕਨ ਨੂੰ ਰੋਕ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਦੁਰਵਰਤੋਂ ਲਈ ਸਮਾਂ ਬਹੁਤ ਘੱਟ ਰਹੇਗਾ।
Context-Bound Scopes ਇੱਕ ਹੋਰ ਲੇਅਰ ਜੋੜਦੇ ਹਨ। ਹਰ ਟੋਕਨ ਨੂੰ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ 'ਰੀਡ-ਓਨਲੀ' (read-only) ਰੱਖੋ। ਜੇਕਰ ਏਜੰਟ ਨੂੰ ਡੇਟਾ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ, ਜਿਵੇਂ ਕਿ ਰਿਫੰਡ ਪ੍ਰੋਸੈਸ ਕਰਨਾ ਜਾਂ ਕਿਸੇ ਕੰਟਰੈਕਟ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ, ਤਾਂ ਮਨੁੱਖੀ ਮਨਜ਼ੂਰੀ (human approval gate) ਲਾਜ਼ਮੀ ਕਰੋ। ਕਦੇ ਵੀ ਮਾਡਲ ਨੂੰ ਇਕੱਲੇ ਇਹ ਫੈਸਲਾ ਨਾ ਲੈਣ ਦਿਓ ਕਿ ਪੈਸੇ ਕਦੋਂ ਹਿੱਲਣਗੇ, ਖਾਤੇ ਕਦੋਂ ਬਦਲਣਗੇ, ਜਾਂ ਰਿਕਾਰਡ ਕਦੋਂ ਗਾਇਬ ਹੋਣਗੇ। ਇਜਾਜ਼ਤ ਉਸ ਪਲ ਦੇ ਅਨੁਸਾਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਅਧਿਕਾਰਾਂ ਦੇ ਅਨੁਸਾਰ।
Ephemeral Windows ਇਸ ਚੱਕਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਟੋਕਨ ਦੀ ਉਮਰ ਦਿਨਾਂ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ ਮਿੰਟਾਂ ਵਿੱਚ ਰੱਖੋ। ਜੇਕਰ ਕੋਈ ਟੋਕਨ ਕਿਸੇ ਛੋਟੀ ਜਿਹੀ ਚੋਰੀ ਦੌਰਾਨ ਹਾਸਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਹਮਲਾਵਰ ਦੁਬਾਰਾ ਵਰਤਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਤੱਕ ਉਹ ਬੇਕਾਰ ਹੋ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਨੂੰ ਲਗਾਤਾਰ ਘੁੰਮਦੇ ਤਾਲੇ ਵਜੋਂ ਸਮਝੋ।
ਇੱਕ ਸੇਲਜ਼ ਆਟੋਮੇਸ਼ਨ ਏਜੰਟ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ ਜੋ ਤੁਹਾਡੇ CRM ਤੋਂ ਲੀਡ ਡੇਟਾ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਮੇਲ API ਰਾਹੀਂ ਫਾਲੋ-ਅੱਪ ਈਮੇਲਾਂ ਲਿਖਦਾ ਹੈ। ਇੱਕ ਸਦੀਵੀ ਐਡਮਿਨ ਕੀ (admin key) ਦੀ ਬਜਾਏ, ਏਜੰਟ ਨੂੰ ਤੁਹਾਡੇ ਆਈਡੈਂਟੀਟੀ ਪ੍ਰੋਵਾਈਡਰ ਤੋਂ 15 ਮਿੰਟ ਦਾ ਟੋਕਨ ਮਿਲਦਾ ਹੈ। ਟੋਕਨ CRM ਪੜ੍ਹਨ ਅਤੇ ਮੇਲ ਭੇਜਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਪਰ ਸੰਪਰਕ ਡਿਲੀਟ ਕਰਨ ਅਤੇ ਬਿਲਿੰਗ ਪਹੁੰਚ ਨੂੰ ਰੋਕਦਾ ਹੈ। ਜੇਕਰ ਏਜੰਟ ਨੂੰ ਪੂਰੇ ਡੇਟਾਬੇਸ ਨੂੰ ਐਕਸਪੋਰਟ ਕਰਨ ਲਈ ਕਿਸੇ ਸ਼ੱਕੀ ਨਿਰਦੇਸ਼ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਸਕੋਪ ਸਿਰਫ਼ ਉਸ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਰੋਕ ਦਿੰਦਾ ਹੈ।
ਇਨਡਾਇਰੈਕਟ ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ (Indirect Prompt Injection) ਨੂੰ ਰੋਕੋ
ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਸ਼ਨ ਹੁਣ ਚੈਟਬੋਟਸ ਲਈ ਕੋਈ ਮਾਮੂਲੀ ਚਾਲ ਨਹੀਂ ਰਹੀ। ਏਜੈਂਟਿਕ ਯੁੱਗ (agentic era) ਵਿੱਚ, ਇਹ ਈਮੇਲ ਰਾਹੀਂ ਭੇਜੇ ਗਏ ਰਿਮੋਟ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (remote code execution) ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ।
ਇੱਥੇ ਇੱਕ ਅਸਲ ਸਥਿਤੀ ਹੈ। ਇੱਕ ਏਜੰਟ ਮੀਟਿੰਗਾਂ ਤੈਅ ਕਰਨ ਲਈ ਉਪਭੋਗਤਾ ਦੇ ਇਨਬਾਕਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਸੁਨੇਹੇ ਦੇ ਅੰਦਰ, ਸ਼ਾਇਦ ਅਦਿੱਖ ਟੈਕਸਟ ਜਾਂ ਅਟੈਚਮੈਂਟ ਦੇ ਅੰਦਰ ਮੈਟਾਡਾਟਾ ਵਿੱਚ, ਇੱਕ ਅਜਿਹਾ ਕਮਾਂਡ ਹੋ ਸਕਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਸਾਰੇ ਇਨਵੌਇਸਾਂ ਨੂੰ ਬਾਹਰੀ ਪਤੇ 'ਤੇ ਭੇਜਣਾ ਅਤੇ ਅਸਲ ਨੂੰ ਡਿਲੀਟ ਕਰਨਾ। ਏਜੰਟ ਈਮੇਲ ਪੜ੍ਹਦਾ ਹੈ, ਜ਼ਹਿਰੀਲੇ ਟੈਕਸਟ ਨੂੰ ਇੱਕ ਜਾਇਜ਼ ਸਿਸਟਮ ਨਿਰਦੇਸ਼ ਸਮਝਦਾ ਹੈ, ਅਤੇ APIs ਨੂੰ ਕਾਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ। ਕਿਉਂਕਿ ਏਜੰਟ ਖੁਦ ਅਧਿਕਾਰਤ ਹੈ, ਇਸ ਲਈ ਮਾਲੀਸ਼ੀ ਬੇਨਤੀਆਂ ਆਮ ਚੈਨਲਾਂ ਰਾਹੀਂ ਵਗਦੀਆਂ ਹਨ। ਨਤੀਜਾ ਅਣਅ
Second, deploy data exfiltration filters on the response path. API responses should pass through inspection before they reach the AI. Scan for patterns that match secrets, authentication tokens, or bulk personal information. If a CRM query returns ten thousand records instead of one, block it. If the payload contains an internal API key, redact it. The agent does not need raw secrets to do its job, and outbound channels must not become smuggling routes for stolen data.
Third, enforce domain whitelisting. The agent needs to communicate with your calendar service, your payment processor, and your internal inventory system. It does not need to talk to arbitrary file-sharing sites, pasteboard services, or foreign cloud storage endpoints. Restrict outbound DNS resolution and HTTP requests to an explicit allow-list. Even if an attacker tricks the agent into trying to ship data elsewhere, the network layer simply refuses the connection.
Build Zero-Trust Architectures
Zero-trust is not a product you install. It is a design philosophy built on one assumption: the agent is already compromised. Act accordingly.
That means splitting identity cleanly. The human user and the agent are not the same entity, even when the agent acts on the user’s behalf. Maintain separate service identities for the agent itself, distinct from the human’s SSO session. Your audit logs should capture both identities side by side. When something goes wrong, you