CAPMAS, EPFL ਅਤੇ Swisscom ਦਾ ਇੱਕ ਸਾਂਝਾ ਯਤਨ ਹੈ, ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ macaroons ਰਾਹੀਂ AI child agents ਨੂੰ ਸੀਮਤ ਦਾਇਰੇ ਵਾਲੀਆਂ permissions ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ token-handling latency ਨੂੰ 30 ਗੁਣਾ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ full-user JWTs ਨੂੰ agents ਦੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਰੱਖਦਾ ਹੈ।

ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ

ਜਦੋਂ ਇੱਕ LLM downstream tools ਨੂੰ ਸੰਚਾਲਿਤ (orchestrate) ਕਰਦਾ ਹੈ, ਤਾਂ ਟੀਮਾਂ ਅਕਸਰ ਬਣਾਏ ਗਏ “child” agent ਨੂੰ ਉਹੀ JWT ਦੇ ਦਿੰਦੀਆਂ ਹਨ ਜਿਸ ਨਾਲ ਯੂਜ਼ਰ ਨੇ ਲੌਗਇਨ ਕੀਤਾ ਹੁੰਦਾ ਹੈ। JWT ਇੱਕ signed blob ਹੁੰਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਕੋਲ ਮੌਜੂਦ ਹਰ permission ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ—ਜਿਵੇਂ ਕਿ HR ਡੇਟਾ, ਪ੍ਰੋਜੈਕਟ ਫਾਈਲਾਂ, admin rights, ਆਦਿ। ਜੇਕਰ ਮਾਡਲ ਕੋਈ ਵਿਨਾਸ਼ਕਾਰੀ command hallucinate ਕਰਦਾ ਹੈ, ਤਾਂ child agent ਇਸਨੂੰ ਯੂਜ਼ਰ ਦੇ ਪੂਰੇ ਅਧਿਕਾਰ ਨਾਲ ਚਲਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਗਲਤੀ ਪੂਰੀ ਸੰਸਥਾ ਦੇ ਡੇਟਾ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾ ਸਕਦੀ ਹੈ।

ਮੌਜੂਦਾ ਵਰਕ-ਅਰਆਉਂਡ (workaround) ਦੀਆਂ ਕਮੀਆਂ

RFC 8693 token-exchange flow ਨਾਲ ਮੰਗ 'ਤੇ ਇੱਕ ਸੀਮਤ token ਬਣਾਉਣ ਨਾਲ IAM ਸਿਸਟਮ ਵਿੱਚ ਕਈ round-trips ਵਧ ਜਾਂਦੇ ਹਨ, network traffic ਵਧਦਾ ਹੈ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ latency ਪੈਦਾ ਹੁੰਦੀ ਹੈ। ਉਹ ਟੀਮਾਂ ਜੋ ਬਹੁਤ ਸਾਰੇ short-lived agents ਬਣਾਉਂਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਇਹ overhead ਬਹੁਤ ਭਾਰੀ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

CAPMAS ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

CAPMAS permission ਦੇਣ ਨੂੰ ਦੋ ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ:

  1. IAM-side encoding – IAM ਸੇਵਾ ਇੱਕ encoder ਚਲਾਉਂਦੀ ਹੈ ਜੋ natural-language ਦੀ ਬੇਨਤੀ (ਜਿਵੇਂ ਕਿ “finance folder ਵਿੱਚ ਫਾਈਲਾਂ ਦੀ ਸੂਚੀ ਦਿਖਾਓ”) ਨੂੰ ਮਿਲਦੇ-ਜੁਲਦੇ privileges ਦੇ ਇੱਕ ਸਮੂਹ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।
  2. Macaroon creation – ਉਹ privileges ਇੱਕ macaroon ਦੇ ਅੰਦਰ caveats ਬਣ ਜਾਂਦੇ ਹਨ, ਜੋ ਕਿ ਇੱਕ ਲਚਕਦਾਰ token format ਹੈ ਜੋ downstream agents ਨੂੰ ਹੋਰ ਪਾਬੰਦੀਆਂ ਲਗਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਪਰ ਮੌਜੂਦਾ ਪਾਬੰਦੀਆਂ ਨੂੰ ਹਟਾਉਣ ਦੀ ਨਹੀਂ।

ਜਦੋਂ ਇੱਕ agent ਨੂੰ macaroon ਮਿਲਦਾ ਹੈ, ਤਾਂ ਉਹ scope ਨੂੰ ਹੋਰ ਸਖ਼ਤ ਕਰ ਸਕਦਾ ਹੈ—ਉਦਾਹਰਨ ਲਈ, file-list ਬੇਨਤੀ ਨੂੰ ਇੱਕ sub-directory ਤੱਕ ਸੀਮਤ ਕਰਨਾ—ਪਰ ਉਹ ਇਸਨੂੰ ਵਧਾ ਨਹੀਂ ਸਕਦਾ। ਹਰ ਪੜਾਅ (hop) 'ਤੇ, IAM ਸੇਵਾ ਸਾਰੇ caveats ਦੇ intersection ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਕੋਈ ਵੀ agent ਅਸਲ ਇਜਾਜ਼ਤ ਤੋਂ ਵੱਧ ਕੁਝ ਨਾ ਕਰੇ।

ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਅੰਕੜੇ ਜੋ ਆਪਣੇ ਆਪ ਬੋਲਦੇ ਹਨ

  • Speed – CAPMAS ਇੱਕ permission ਬੇਨਤੀ ਨੂੰ 20 ms ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ RFC 8693 exchange ਨਾਲੋਂ ਲਗਭਗ 30 × ਤੇਜ਼ ਹੈ।
  • Accuracy – ਟੂਲਜ਼ ਦੇ ਇੱਕ ਵੱਡੇ ਕੈਟਾਲਾਗ ਦੇ ਬੈਂਚਮਾਰਕ ਵਿੱਚ, ਇੱਕ standard LLM ਨੇ ਲੋੜੀਂਦੇ privileges ਵਿੱਚੋਂ 53% ਗਲਤੀਆਂ ਕੀਤੀਆਂ। CAPMAS ਨੇ ਸਿਰਫ਼ 2.1% miss rate ਦੇ ਨਾਲ 90.9% ਸ਼ੁੱਧਤਾ (accuracy) ਪ੍ਰਾਪਤ ਕੀਤੀ।
  • Bandwidth – ਕਿਉਂਕਿ macaroon ਵਿੱਚ ਸਿਰਫ਼ ਅੰਤਿਮ caveats ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਕੀਤਾ ਗਿਆ ਡੇਟਾ ਇੱਕ full token-exchange flow ਦੀ ਲੋੜ ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਘੱਟ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਵਿਵਹਾਰਕ ਅਪਣਾਉਣ ਦਾ ਵਰਕਫਲੋ (workflow)

  1. Pre-filter the request – ਕਿਸੇ ਵੀ orchestrator ਦੁਆਰਾ tool catalog ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਯੂਜ਼ਰ ਦੇ natural-language ਇਰਾਦੇ ਨੂੰ top-k allowlist ਵਿੱਚ ਬਦਲੋ।
  2. Seal the allowlist – ਉਸ allowlist ਨੂੰ ਇੱਕ macaroon ਵਿੱਚ encode ਕਰੋ ਜਿਸ ਨੂੰ child agent ਵਧਾ ਨਹੀਂ ਸਕਦਾ।
  3. Verify at the service – ਬੇਨਤੀ ਨੂੰ ਪ੍ਰਵਾਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ target service ਨੂੰ ਸਾਰੇ caveats ਦੇ intersection ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ IAM ਨੂੰ ਕਹਿਣ ਦਿਓ।

ਇਹ ਕਦਮ "ਬੱਚੇ ਨੂੰ ਪੂਰੇ ਘਰ ਦੀ ਚਾਬੀ ਦੇਣ" ਦੇ ਪੈਟਰਨ ਨੂੰ "ਇੱਕ ਵਾਰ ਵਰਤੋਂ ਵਾਲੀ, ਸੀਮਤ-ਦਾਇਰੇ ਵਾਲੀ ਚਾਬੀ ਦੇਣ" ਦੇ ਮਾਡਲ ਨਾਲ ਬਦਲ ਦਿੰਦੇ ਹਨ।

CAPMAS ਕੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ

ਇਹ ਫਰੇਮਵਰਕ prompt-injection ਹਮਲਿਆਂ ਨੂੰ ਨਹੀਂ ਰੋਕਦਾ, ਜਿੱਥੇ ਇੱਕ ਹਮਲਾਵਰ ਮਾਲੀਸ਼ੀਅਸ commands ਨੂੰ ਭੇਜਣ ਲਈ LLM ਦੇ prompt ਨਾਲ ਛੇੜਛਾੜ ਕਰਦਾ ਹੈ। ਇਸਦੀ ਸੁਰੱਖਿਆ honest-but-curious agents ਅਤੇ ਅਭਰੋਸੇਯੋਗ LLMs ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ ਜੋ ਹੋਰਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਇੱਕ full JWT 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। Prompt-ਅਧਾਰਤ ਖਤਰਿਆਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਟੀਮਾਂ ਨੂੰ ਅਜੇ ਵੀ ਵੱਖਰੇ ਬਚਾਅ—ਜਿਵੇਂ ਕਿ input sanitisation, sandboxing, ਜਾਂ model-level guardrails—ਦੀ ਲੋੜ ਹੈ।

ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੋਵੇਗਾ

  • Enterprise developers ਜੋ AI-driven assistants ਬਣਾ ਰਹੇ ਹਨ ਜੋ internal APIs ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ।
  • Security teams ਜੋ ਕਿਸੇ compromised ਮਾਡਲ ਦੇ ਪ੍ਰਭਾਵ (blast radius) ਨੂੰ ਘਟਾਉਣਾ ਚਾਹੁੰਦੀਆਂ ਹਨ।
  • Product owners ਜਿਨ੍ਹਾਂ ਨੂੰ ਉੱਚ-ਫ੍ਰੀਕੁਐਂਸੀ agent spawning ਲਈ ਤੇਜ਼ ਅਤੇ ਭਰੋਸੇਯੋਗ permission ਚੈੱਕ ਦੀ ਲੋੜ ਹੈ।

ਅੱਗੇ ਕੀ ਹੈ

CAPMAS ਇੱਕ ਪ੍ਰਸਤਾਵਿਤ ਡਿਜ਼ਾਈਨ ਹੈ।

Takeaway: Full-user JWTs ਨੂੰ ਸੀਮਤ-ਦਾਇਰੇ ਵਾਲੇ macaroons ਨਾਲ ਬਦਲਣ ਨਾਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਰਵਾਇਤੀ token-exchange flows ਦੀ latency ਦੀ ਕੀਮਤ ਚੁਕਾਏ ਬਿਨਾਂ AI agents ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਣ ਦਾ ਤਰੀਕਾ ਮਿਲਦਾ ਹੈ। ਇਸ ਵਿੱਚ prompt-injection ਸੁਰੱਖਿਆ ਦੀ ਨਿਰੰਤਰ ਲੋੜ ਬਣੀ ਰਹੇਗੀ।