ਹਰ ਕਿਸੇ ਲਈ ਇੱਕ policy ਹੁਣ ਕਾਫ਼ੀ ਨਹੀਂ ਰਹੀ
ਜ਼ਿਆਦਾਤਰ applications ਇੱਕੋ ਕਿਸਮ ਦੇ user ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਬਣਾਈਆਂ ਗਈਆਂ ਸਨ: ਇੱਕ ਵਿਅਕਤੀ ਜੋ interface ਰਾਹੀਂ click ਕਰ ਰਿਹਾ ਹੈ, account ਵਿੱਚ signed in ਹੈ। Access control ਨੇ ਵੀ ਉਸੇ ਧਾਰਨਾ ਨੂੰ follow ਕੀਤਾ। ਜੇ session valid ਹੈ, request ਅੱਗੇ ਚਲੀ ਜਾਂਦੀ ਹੈ। ਜੇ ਇਹ automated ਲੱਗੇ, ਤਾਂ CAPTCHA ਜਾਂ block ਆ ਜਾਂਦਾ ਹੈ।
ਉਹ model ਟੁੱਟ ਰਿਹਾ ਹੈ। ਅੱਜ ਇੱਕੋ application ਲੋਕਾਂ, AI assistants ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਲੋਕਾਂ ਅਤੇ ਕਿਸੇ ਹੋਰ ਦੀ ਥਾਂ ਕਾਰਵਾਈ ਕਰਨ ਵਾਲੇ autonomous agents ਨੂੰ serve ਕਰਦੀ ਹੈ। ਕੁਝ agents customers ਦੀਆਂ ਆਪਣੀਆਂ integrations ਹੁੰਦੀਆਂ ਹਨ। ਕੁਝ AI assistants documentation fetch ਕਰਦੇ ਹਨ। ਕੁਝ crawlers ਹੁੰਦੇ ਹਨ। ਕੁਝ ਤੁਹਾਡੇ product ਦਾ ਦੁਰੁਪਯੋਗ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ। ਇੱਕੋ yes-or-no rule ਇਨ੍ਹਾਂ ਸਭ ਲਈ ਢੰਗ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ।
AI agent routing ਅਤੇ access policies ਉਸ ਇਕੱਲੇ rule ਨੂੰ deliberate decisions ਦੇ ਇਕ set ਨਾਲ replace ਕਰਦੀਆਂ ਹਨ: ਕਿਹੜੇ actors ਨੂੰ ਕਿਹੜਾ experience ਮਿਲੇ, ਕਿਹੜੇ routes 'ਤੇ, ਕਿਹੜੀਆਂ conditions ਹੇਠ। Proof of Actor ਤੁਹਾਡੀ application ਨੂੰ ਉਹ evidence ਦਿੰਦਾ ਹੈ ਜਿਸ ਨਾਲ ਇਹ decisions ਲਏ ਜਾ ਸਕਣ, ਅਤੇ ਫੈਸਲੇ ਤੁਹਾਡੇ ਹੱਥਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। ਇਸ approach ਦੇ design principles ਲਈ designing app policies for humans and AI agents ਪੜ੍ਹੋ, ਅਤੇ ਦੇਖੋ ਕਿ policies real product workflows ਨਾਲ ਕਿਵੇਂ map ਹੁੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ SaaS apps use case ਵੇਖੋ।
ਇੱਕ ਚੰਗੀ agent policy ਕਿਵੇਂ ਦਿਖਦੀ ਹੈ
ਇੱਕ useful policy specific ਹੁੰਦੀ ਹੈ। ਇਹ ਇੱਕ route ਜਾਂ workflow, actor ਦੀ class, ਲੋੜੀਂਦੀ evidence ਦੀ strength, ਅਤੇ response ਦੱਸਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ:
- Read-only catalog routes: verified agents ਨੂੰ allow ਕਰੋ ਅਤੇ structured response ਦਿਓ; declared agents ਨੂੰ standard rate limit ਨਾਲ allow ਕਰੋ।
- Account-changing actions: ਹਰ ਕਿਸੇ ਲਈ ਆਪਣੀ ਮੌਜੂਦਾ re-authentication ਕਾਇਮ ਰੱਖੋ; ਜਦੋਂ actor Unknown ਹੋਵੇ ਅਤੇ action high impact ਹੋਵੇ ਤਾਂ review ਜੋੜੋ।
- Support submissions: disclosed AI-assisted content accept ਕਰੋ ਅਤੇ routing ਲਈ ਉਸ ਨੂੰ label ਕਰੋ।
- Signup: ਮੌਜੂਦਾ checks ਕਾਇਮ ਰੱਖੋ; inferred actor result ਦੇ ਆਧਾਰ 'ਤੇ ਕਦੇ ਵੀ ਇਕੱਲਾ ਫੈਸਲਾ ਨਾ ਕਰੋ।
ਇਨ੍ਹਾਂ ਹਰ cases ਵਿੱਚ actor ਦੇ according response ਦਿੰਦੀ ਹੈ, ਨਾ ਕਿ ਹਰ agent ਨੂੰ abuse ਮੰਨਦੀ ਹੈ, ਅਤੇ ਨਾ ਹੀ ਹਰ agent 'ਤੇ ਅੰਨ੍ਹਾ ਭਰੋਸਾ ਕਰਦੀ ਹੈ। ਇਹ ਸੰਤੁਲਨ ਹੀ agent-aware access ਦਾ ਮੁੱਖ ਉਦੇਸ਼ ਹੈ, ਅਤੇ designing app policies for humans and AI agents ਵਾਲੀ blog post route by route ਹੋਰ ਉਦਾਹਰਨਾਂ ਨਾਲ ਇਸਨੂੰ ਸਮਝਾਉਂਦੀ ਹੈ।
ਪੰਜ responses
Proof of Actor ਦੀ Route capability ਪੰਜ responses ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਤੁਹਾਡੀਆਂ policies ਚੁਣ ਸਕਦੀਆਂ ਹਨ।
Allow
Request ਨੂੰ ਆਮ ਤਰ੍ਹਾਂ ਅੱਗੇ ਜਾਣ ਦਿਓ। ਜ਼ਿਆਦਾਤਰ traffic, ਜਿਸ ਵਿੱਚ public ਜਾਂ low-risk routes 'ਤੇ ਆਉਣ ਵਾਲਾ ਜ਼ਿਆਦਾਤਰ agent traffic ਵੀ ਸ਼ਾਮਲ ਹੈ, ਸਿੱਧਾ allow ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
Adapt
Actor ਦੇ ਅਨੁਸਾਰ experience ਬਦਲੋ। Human-shaped interface ਦੀ ਥਾਂ ਇੱਕ verified agent ਨੂੰ structured API response ਜਾਂ page ਦਾ Markdown version ਦਿਓ। serving AI agents structured content ਵਾਲੀ guide ਇਸ pattern ਨੂੰ cover ਕਰਦੀ ਹੈ।
Challenge
ਕੁਝ ਮਜ਼ਬੂਤ ਮੰਗੋ: ਤਾਜ਼ਾ login, ਵਾਧੂ credential, account owner ਤੋਂ confirmation। ਉਹਨਾਂ routes 'ਤੇ challenges ਵਰਤੋ ਜਿੱਥੇ ਗਲਤ ਫੈਸਲੇ ਦੀ ਲਾਗਤ ਉੱਚੀ ਹੋਵੇ।
Review
Action ਨੂੰ ਸਿੱਧੇ completion ਤੱਕ ਜਾਣ ਦੀ ਥਾਂ queue ਵਿੱਚ ਜਾਣ ਦਿਓ, ਜਾਂ human ਲਈ ਇਸ ਨੂੰ check ਕਰਨ ਵਾਸਤੇ flag ਕਰੋ। Review ਉੱਥੇ ਲਾਭਦਾਇਕ ਹੈ ਜਿੱਥੇ blocking legitimate users ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੀ ਹੋਵੇ, ਪਰ unattended completion ਬਹੁਤ risk ਵਾਲੀ ਹੋਵੇ।
Limit
Actor ਅਤੇ route ਦੇ ਅਨੁਸਾਰ ਤੈਅ ਕੀਤਾ rate ਜਾਂ volume limit ਲਾਗੂ ਕਰੋ, ਤਾਂ ਜੋ automated callers ਉਸ workflow ਨੂੰ overwhelm ਨਾ ਕਰ ਸਕਣ ਜੋ ਲੋਕਾਂ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ।
robots.txt ਇੱਕ access policy ਨਹੀਂ ਹੈ
ਕਈ teams robots.txt ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ crawlers ਲਈ ਇਹ ਇੱਕ sensible first signal ਹੈ। ਪਰ ਇਹ agents ਲਈ access policy ਨਹੀਂ ਹੈ। Crawler operators ਵੱਖ-ਵੱਖ user agents ਲਈ ਵੱਖਰਾ behavior ਦਰਜ ਕਰਦੇ ਹਨ: Anthropic ਦੱਸਦਾ ਹੈ ਕਿ ਉਸ ਦੇ bots robots.txt directives ਨੂੰ honor ਕਰਦੇ ਹਨ (Anthropic crawler documentation), ਜਦਕਿ OpenAI ਨੋਟ ਕਰਦਾ ਹੈ ਕਿ ChatGPT-User ਲਈ, ਜੋ ਤਦ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ user ChatGPT ਨੂੰ ਕੋਈ question ਪੁੱਛਦਾ ਹੈ, robots.txt rules ਲਾਗੂ ਨਹੀਂ ਵੀ ਹੋ ਸਕਦੇ ਕਿਉਂਕਿ ਕਾਰਵਾਈ user ਵੱਲੋਂ initiate ਕੀਤੀ ਜਾਂਦੀ ਹੈ (OpenAI crawler documentation). Robots.txt APIs, MCP tools ਜਾਂ signed-in workflows ਬਾਰੇ ਵੀ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।
ਇੱਕ access policy ਨੂੰ ਉੱਥੇ ਚਲਣਾ ਪੈਂਦਾ ਹੈ ਜਿੱਥੇ request handle ਕੀਤੀ ਜਾਂਦੀ ਹੈ, RFC 9421 ਹੇਠ check ਕੀਤੇ ਗਏ signature ਵਰਗੀ evidence ਪੜ੍ਹਨੀ ਪੈਂਦੀ ਹੈ, ਅਤੇ ਹਰ route ਲਈ response ਚੁਣਨਾ ਪੈਂਦਾ ਹੈ। MCP servers ਲਈ, MCP authorization specification ਇਹ define ਕਰਦੀ ਹੈ ਕਿ clients HTTP ਰਾਹੀਂ access tokens ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ; actor policies ਉਸ ਦੇ ਉੱਪਰ context ਜੋੜਦੀਆਂ ਹਨ, ਉਹ ਉਸਨੂੰ replace ਨਹੀਂ ਕਰਦੀਆਂ।
Proof of Actor ਤੁਹਾਡੀਆਂ policies ਲਈ input ਕਿਵੇਂ ਦਿੰਦਾ ਹੈ
ਤੁਹਾਡੀ integration ਵੱਲੋਂ evaluate ਕੀਤੀ ਹਰ request ਇੱਕ actor result ਦਿੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਚਾਰ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ ਜੋ ਤੁਹਾਡੀ policy ਪੜ੍ਹ ਸਕਦੀ ਹੈ:
- Class: Human, Human + AI, Agent ਜਾਂ Unknown.
- Basis: Verified, Declared, Inferred ਜਾਂ Unknown, ਤਾਂ ਜੋ ਤੁਹਾਡੀ policy validated signature ਨੂੰ self-declared client name ਤੋਂ ਵੱਖਰਾ treat ਕਰ ਸਕੇ।
- Evidence summary: ਇੱਕ readable description ਕਿ result ਕਿਸ ਆਧਾਰ 'ਤੇ ਟਿਕਿਆ ਹੈ, ਜੋ logging ਅਤੇ review ਲਈ useful ਹੈ।
- Context: ਕਿਹੜੀ integration ਅਤੇ ਕਿਹੜੇ route ਨੇ ਇਹ result produce ਕੀਤਾ।
ਕਿਉਂਕਿ basis explicit ਹੈ, ਤੁਹਾਡੀਆਂ policies precise ਹੋ ਸਕਦੀਆਂ ਹਨ। "Allow agents" ਦਾ ਮਤਲਬ ਬਣ ਜਾਂਦਾ ਹੈ "allow verified agents on read routes, rate-limit declared agents, apply the Unknown fallback to everything else." Request ਤੋਂ decision ਤੱਕ ਪੂਰਾ flow How It Works 'ਤੇ describe ਕੀਤਾ ਗਿਆ ਹੈ।
Fallbacks policy ਦਾ ਹਿੱਸਾ ਹਨ
ਇੱਕ policy ਉੱਨੀ ਹੀ ਚੰਗੀ ਹੁੰਦੀ ਹੈ ਜਿੰਨੀ ਚੰਗੀ ਉਹ evidence ਨਾ ਹੋਣ 'ਤੇ ਵਰਤਾਓ ਕਰਦੀ ਹੈ। Proof of Actor ਉਹ cases explicit ਕਰਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਲੁਕਾਉਂਦਾ ਨਹੀਂ।
- Unknown: evidence ਨੇ determination ਨੂੰ support ਨਹੀਂ ਕੀਤਾ। ਤੁਹਾਡੀ policy ਹਰ route 'ਤੇ ਦੱਸਦੀ ਹੈ ਕਿ Unknown ਦਾ ਕੀ ਮਤਲਬ ਹੈ। ਇਸਨੂੰ ਕਦੇ Human ਵਿੱਚ convert ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਅਤੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਕਦੇ malicious ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ।
- Timeout: result ਸਮੇਂ 'ਤੇ ਨਹੀਂ ਆਇਆ। ਤੁਹਾਡੀ integration ਉਸ route ਲਈ ਚੁਣਿਆ ਗਿਆ fallback apply ਕਰਦੀ ਹੈ।
- Missing signals: ਕੋਈ collector run ਨਹੀਂ ਹੋਇਆ ਜਾਂ ਕੋਈ header absent ਸੀ। Result ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ policy ਉਸ ਦੇ ਅਨੁਸਾਰ ਵਰਤਾਓ ਕਰਦੀ ਹੈ।
ਹਰ route ਲਈ ਤੁਸੀਂ ਚੁਣਦੇ ਹੋ ਕਿ fail open or fail closed ਕਰਨਾ ਹੈ ਜਾਂ ਨਹੀਂ। Fail open ਦਾ ਮਤਲਬ ਹੈ ਕਿ request ਬਿਨਾਂ Proof of Actor ਦੇ ਜਿਵੇਂ ਅੱਗੇ ਵਧਦੀ, ਉਸੇ ਤਰ੍ਹਾਂ ਵਧੇ; fail closed ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੀ ਮੌਜੂਦਾ stronger check ਲਾਗੂ ਰਹੇ। Low-risk routes ਆਮ ਤੌਰ 'ਤੇ fail open ਹੁੰਦੇ ਹਨ। Sensitive actions ਆਮ ਤੌਰ 'ਤੇ fail closed ਹੁੰਦੇ ਹਨ। ਤੁਸੀਂ ਇਹ per risk tier set ਕਰਦੇ ਹੋ, globally ਨਹੀਂ।
Identity, credentials ਅਤੇ authorization ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ
Agent access policies ਤਿੰਨ ਵੱਖਰੀਆਂ layers ਦੇ ਉੱਪਰ ਬੈਠਦੀਆਂ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਸਭ ਤੋਂ ਨੁਕਸਾਨਦਾਇਕ ਗਲਤੀਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
- Identity evidence ਇਹ answer ਕਰਦੀ ਹੈ ਕਿ ਕਿਹੜਾ actor call ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ। Proof of Actor ਇਹ ਦਿੰਦਾ ਹੈ।
- Credentials ਇਹ answer ਕਰਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜਾ account ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਤੁਹਾਡਾ session, token ਜਾਂ API key ਇਹ ਦਿੰਦੀ ਹੈ।
- Authorization ਇਹ answer ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਇਹ caller ਇਹ action ਕਰ ਸਕਦਾ ਹੈ। ਤੁਹਾਡਾ permission model ਇਹ ਦਿੰਦਾ ਹੈ।
ਇੱਕ verified agent identity ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ agent authorized ਹੈ, ਨਾ ਇਹ ਕਿ ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ ਇਸ ਨੂੰ authority ਦਿੱਤੀ ਹੈ, ਅਤੇ ਨਾ ਇਹ ਕਿ ਇਸ ਦੀ action safe ਹੈ। Actor results ਨੂੰ routing ਅਤੇ context ਜੋੜਨ ਲਈ ਵਰਤੋ। Permission ਦੇਣ ਲਈ ਆਪਣੇ authorization model ਨੂੰ ਵਰਤੋ। Detection & Limitations ਵਾਲਾ page ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਕਿਸਮ ਦੀ evidence ਕੀ establish ਕਰ ਸਕਦੀ ਹੈ।
ਕੁਝ ਵੀ ਤੋੜੇ ਬਿਨਾਂ rollout ਕਰੋ
Agent access policies introduce ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ stages ਵਿੱਚ ਹੈ।
- Observe. observation mode ਵਿੱਚ Proof of Actor install ਕਰੋ। ਤੁਹਾਡੇ users ਲਈ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ; results record ਹੁੰਦੇ ਹਨ।
- Understand. ਦੇਖੋ ਕਿ ਕਿਹੜੇ actors ਕਿਹੜੇ routes ਵਰਤਦੇ ਹਨ, ਹਰ ਇੱਕ 'ਤੇ unknown rate ਕੀ ਹੈ, ਅਤੇ ਕਿਹੜੇ results ਤੁਹਾਡੀ ਪਹਿਲਾਂ ਦੀ ਜਾਣਕਾਰੀ ਨਾਲ disagree ਕਰਦੇ ਹਨ।
- Preview. ਇੱਕ policy ਨੂੰ preview ਵਿੱਚ ਚਲਾਓ, ਇਹ log ਕਰਦੇ ਹੋਏ ਕਿ enforce ਕੀਤੇ ਬਿਨਾਂ ਉਸ ਨੇ ਕੀ ਕੀਤਾ ਹੁੰਦਾ।
- Enforce narrowly. Policy ਨੂੰ ਇੱਕ route 'ਤੇ enable ਕਰੋ ਜਿੱਥੇ evidence ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਸ ਨੂੰ support ਕਰਦੀ ਹੋਵੇ। Outcomes 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ।
- Expand. Confidence ਵਧਣ ਨਾਲ ਹੋਰ routes ਤੱਕ ਫੈਲਾਓ।
rolling out actor-aware policies safely ਵਾਲੀ guide ਹਰ stage ਨੂੰ ਸਮਝਾਉਂਦੀ ਹੈ, ਅਤੇ protecting sensitive actions without blocking agents high-stakes routes ਨੂੰ cover ਕਰਦੀ ਹੈ।
ਤੁਹਾਡੀ team ਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ
Proof of Actor ਨਾਲ, ਤੁਹਾਡੀ team ਨੂੰ ਤਿੰਨ capabilities ਦੇ ਨਾਲ ਇੱਕ integration ਮਿਲਦੀ ਹੈ। Detect actor signals ਇਕੱਠੇ ਕਰਦਾ ਹੈ ਅਤੇ verified assertions ਨੂੰ inferences ਤੋਂ ਵੱਖਰਾ ਕਰਦਾ ਹੈ। Understand actor analytics, trends ਅਤੇ ਹਰ result ਦੇ ਪਿੱਛੇ ਦੀ evidence ਦਿਖਾਉਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ Unknown visible ਰਹਿੰਦਾ ਹੈ। Route ਤੁਹਾਨੂੰ ਇਸ page 'ਤੇ ਵਰਣਿਤ policies ਲਿਖਣ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜਿੱਥੇ ਚਾਹੋ ਉੱਥੇ ਲਾਗੂ ਕਰਨ ਦਿੰਦਾ ਹੈ। private beta ਦੌਰਾਨ, routing policies ਹਰ founding team ਦੇ ਨਾਲ design ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਆਪਣੇ application code ਵਿੱਚ run ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਪੂਰਾ control ਬਣਿਆ ਰਹੇ।
Common policy mistakes ਤੋਂ ਬਚੋ
ਜੋ teams ਪਹਿਲੀ ਵਾਰ agent access design ਕਰਦੀਆਂ ਹਨ, ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਗਲਤੀਆਂ ਦੁਹਰਾਉਂਦੀਆਂ ਹਨ। ਇਨ੍ਹਾਂ ਤੋਂ ਬਚਣਾ ਹਫ਼ਤਿਆਂ ਦੀ rework ਬਚਾਉਂਦਾ ਹੈ।
- ਹਰ agent ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ block ਕਰਨਾ। ਇਸ ਨਾਲ legitimate agents ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਆਲੇ-ਦੁਆਲੇ route ਕਰ ਲੈਂਦੇ ਹਨ, ਅਕਸਰ ਉਸ interface ਨੂੰ scrape ਕਰਕੇ ਜੋ ਤੁਸੀਂ ਲੋਕਾਂ ਲਈ ਬਣਾਇਆ ਸੀ, ਜਿਸ ਨੂੰ structured path ਨਾਲੋਂ protect ਕਰਨਾ ਔਖਾ ਹੁੰਦਾ ਹੈ।
- Declared name 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ। ਜੋ client ਸਿਰਫ਼ ਆਪਣਾ ਨਾਮ ਦੱਸਦਾ ਹੈ, ਉਸ ਨੇ claim ਕੀਤਾ ਹੈ, proof ਨਹੀਂ ਦਿੱਤਾ। ਉਸ ਨਾਲ ਉਹੀ treatment ਕਰੋ ਜੋ ਤੁਸੀਂ ਇੱਕ unverified caller ਨਾਲ ਕਰਦੇ ਹੋ।
- ਹਰ ਜਗ੍ਹਾ ਇੱਕੋ fallback ਵਰਤਣਾ। Public pricing page 'ਤੇ Unknown ਅਤੇ password change 'ਤੇ Unknown ਵੱਖ-ਵੱਖ situations ਹਨ। ਹਰ route ਨੂੰ ਆਪਣਾ answer ਚਾਹੀਦਾ ਹੈ।
- Inference ਤੋਂ ਲੋਕਾਂ ਬਾਰੇ ਫੈਸਲਾ ਕਰਨਾ। Actor results routing ਲਈ context ਹਨ, ਕਿਸੇ individual ਬਾਰੇ verdict ਨਹੀਂ। Consequential decisions ਆਪਣੇ controls ਅਤੇ review ਕੋਲ ਹੀ ਰੱਖੋ।
- Observation ਛੱਡ ਦੇਣਾ। Day one ਤੋਂ enforce ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ false positives customer complaints ਰਾਹੀਂ ਖੋਜੋਗੇ। ਪਹਿਲਾਂ observe ਕਰੋ, ਫਿਰ ਜਿੱਥੇ evidence ਸਪਸ਼ਟ ਹੋਵੇ ਉੱਥੇ enforce ਕਰੋ।
ਹਰ enforcement step ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ security, product ਅਤੇ support leadership ਨਾਲ ਇੱਕ ਛੋਟੀ policy review ਕਰਨ ਨਾਲ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤੀਆਂ ਗਲਤੀਆਂ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਪਤਾ ਲੱਗ ਜਾਂਦੀਆਂ ਹਨ।
Founding developer program ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
Proof of Actor private beta ਵਿੱਚ ਹੈ। ਚੁਣੀਆਂ ਗਈਆਂ founding development teams ਨੂੰ agreed usage limits ਦੇ ਅੰਦਰ, 12 months ਤੱਕ ਮੁਫ਼ਤ access ਮਿਲ ਸਕਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਆਪਣੀਆਂ ਪਹਿਲੀਆਂ policies design ਕਰਦੇ ਹੋ, ਤਾਂ ਸਾਡੀਆਂ engineers ਵੱਲੋਂ direct support ਮਿਲਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਹ ਫੈਸਲਾ ਕਰ ਰਹੇ ਹੋ ਕਿ ਤੁਹਾਡੀ application AI agents ਨਾਲ ਕਿਵੇਂ ਵਰਤਾਓ ਕਰੇ, ਤਾਂ apply for early access ਕਰੋ। ਸਾਨੂੰ ਦੱਸੋ ਕਿਹੜੇ routes ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਤੁਸੀਂ ਕਿਹੜੇ decisions ਲੈਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਅਸੀਂ ਤੁਹਾਨੂੰ ਉਹ policies ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਾਂਗੇ ਜੋ fit ਕਰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਇਹ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਹ APIs ਅਤੇ MCP servers 'ਤੇ ਕਿਵੇਂ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।
Sources
- Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.
- Overview of OpenAI crawlers, OpenAI.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- MCP authorization, modelcontextprotocol.io.