AGENT ಪ್ರವೇಶ ನೀತಿಗಳು

ನೀವು ನಿಯಂತ್ರಿಸುವ ನೀತಿಗಳೊಂದಿಗೆ AI agent ಗಳನ್ನು route ಮಾಡಿ

ನಿಮ್ಮ application ಜನರು, AI-assisted ಬಳಕೆದಾರರು ಮತ್ತು autonomous agent ಗಳನ್ನು route by route ಹೇಗೆ ಕೈಲೂಗೊಳ್ಳಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. Proof of Actor evidence ಒದಗಿಸುತ್ತದೆ; ನಿರ್ಧಾರವನ್ನು ನಿಮ್ಮ ನೀತಿಗಳು ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿ ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅನ್ವೇಷಿಸಿ

ರಚನೆ Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ಎಲ್ಲರಿಗೂ ಒಂದೇ ನೀತಿ ಈಗ ಸಾಕಾಗುವುದಿಲ್ಲ

ಬಹುತೇಕ applications ಒಂದೇ ರೀತಿಯ ಬಳಕೆದಾರರನ್ನು ಮನಸ್ಸಿನಲ್ಲಿ ಇಟ್ಟುಕೊಂಡು ವಿನ್ಯಾಸಗೊಳಿಸಲ್ಪಟ್ಟಿದ್ದವು: account ಗೆ sign in ಮಾಡಿಕೊಂಡು interface ಮೂಲಕ ಕ್ಲಿಕ್ ಮಾಡುವ ವ್ಯಕ್ತಿ. access control ಆ ಊಹೆಯನ್ನು ಅನುಸರಿಸಿತು. session ಮಾನ್ಯವಾಗಿದ್ದರೆ, request ಮುಂದುವರಿಯುತ್ತದೆ. ಅದು automated ಆಗಿರುವಂತೆ ಕಂಡರೆ, CAPTCHA ಅಥವಾ block ಕಾಣಿಸುತ್ತದೆ.

ಆ model ಮುರಿಯುತ್ತಿದೆ. ಇಂದು ಅದೇ application ಜನರು, AI assistants ಜೊತೆ ಕೆಲಸ ಮಾಡುವ ಜನರು, ಮತ್ತು ಯಾರಾದರೊಬ್ಬರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ autonomous agent ಗಳಿಗೆ ಸೇವೆ ನೀಡುತ್ತದೆ. ಕೆಲವು agent ಗಳು customers ಗಳ own integrations ಆಗಿವೆ. ಕೆಲವು documentation ಪಡೆಯುವ AI assistants. ಕೆಲವು crawlers. ಕೆಲವರು ನಿಮ್ಮ product ಅನ್ನು ದುರುಪಯೋಗಪಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾರೆ. ಒಂದೇ yes-or-no ನಿಯಮ ಇವೆಲ್ಲರಿಗೂ ಚೆನ್ನಾಗಿ ಸೇವೆ ನೀಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

AI agent routing ಮತ್ತು access policies ಆ ಒಂದೇ ನಿಯಮವನ್ನು ಉದ್ದೇಶಿತ ನಿರ್ಧಾರಗಳ ಸಮೂಹದಿಂದ ಬದಲಿಸುತ್ತವೆ: ಯಾವ actor ಗಳಿಗೆ ಯಾವ experience, ಯಾವ route ಗಳಲ್ಲಿ, ಯಾವ conditions ಅಡಿಯಲ್ಲಿ. Proof of Actor ನಿಮ್ಮ application ಗೆ ಆ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು evidence ನೀಡುತ್ತದೆ, ಮತ್ತು ನಿರ್ಧಾರಗಳನ್ನೇ ನಿಮ್ಮ ಕೈಯಲ್ಲಿ ಬಿಡುತ್ತದೆ. ಈ approach ನ design principles ಗಾಗಿ designing app policies for humans and AI agents ಓದಿ, ಮತ್ತು policies ನಿಜವಾದ product workflows ಗೆ ಹೇಗೆ map ಆಗುತ್ತವೆ ಎಂಬುದಕ್ಕಾಗಿ SaaS apps use case ನೋಡಿ.

ಉತ್ತಮ agent policy ಹೇಗಿರುತ್ತದೆ

ಉಪಯುಕ್ತ policy ನಿರ್ದಿಷ್ಟವಾಗಿರುತ್ತದೆ. ಅದು route ಅಥವಾ workflow, actor class, ಅಗತ್ಯವಿರುವ evidence strength, ಮತ್ತು response ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ:

Read-only catalog routes: verified agents ಗಳಿಗೆ allow ಮಾಡಿ ಮತ್ತು structured response ನೀಡಿ; standard rate limit ಜೊತೆಗೆ declared agents ಗಳನ್ನು allow ಮಾಡಿ.
Account-changing actions: ಎಲ್ಲರಿಗೂ ನಿಮ್ಮ existing re-authentication ಅನ್ನು ಉಳಿಸಿ; actor Unknown ಆಗಿದ್ದರೆ ಮತ್ತು action high impact ಆಗಿದ್ದರೆ review ಸೇರಿಸಿ.
Support submissions: disclosed AI-assisted content ಅನ್ನು ಸ್ವೀಕರಿಸಿ ಮತ್ತು routing ಗಾಗಿ ಅದನ್ನು label ಮಾಡಿ.
Signup: existing checks ಅನ್ನು ಉಳಿಸಿ; inferred actor ಫಲಿತಾಂಶದಿಂದ ಮಾತ್ರ ಎಂದಿಗೂ ನಿರ್ಧರಿಸಬೇಡಿ.

ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದು actor ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತಿಯೊಂದು agent ನನ್ನು abuse ಎಂದು ಪರಿಗಣಿಸುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರತಿಯೊಂದು agent ನ ಮೇಲೆ blind trust ಇಡುವುದಿಲ್ಲ. ಆ ಸಮತೋಲನವೇ agent-aware access ನ ಸಂಪೂರ್ಣ ಅರ್ಥ, ಮತ್ತು designing app policies for humans and AI agents ಕುರಿತ blog post ಇನ್ನಷ್ಟು ಉದಾಹರಣೆಗಳನ್ನು route by route ವಿವರಿಸುತ್ತದೆ.

ಐದು responses

Proof of Actor ನ Route capability ನಿಮ್ಮ policies ಆಯ್ಕೆಮಾಡಬಹುದಾದ ಐದು responses ಗಳ ಸುತ್ತ ನಿರ್ಮಿಸಲಾಗಿದೆ.

Allow

Request ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮುಂದುವರಿಯಲು ಬಿಡಿ. ಹೆಚ್ಚಿನ traffic, ವಿಶೇಷವಾಗಿ public ಅಥವಾ low-risk routes ಗಳಲ್ಲಿ ಇರುವ ಹೆಚ್ಚಿನ agent traffic, simply allow ಆಗಬೇಕು.

Adapt

Actor ಗೆ ಸೂಕ್ತವಾಗುವಂತೆ experience ಅನ್ನು ಬದಲಿಸಿ. human-shaped interface ಬದಲು verified agent ಗೆ structured API response ಅಥವಾ page ನ Markdown version ನೀಡಿರಿ. serving AI agents structured content ಕುರಿತ guide ಈ pattern ಅನ್ನು ಒಳಗೊಂಡಿದೆ.

Challenge

ಹೆಚ್ಚು ಬಲವಾದ ಯಾವುದನ್ನಾದರೂ ಕೇಳಿ: ಹೊಸ login, additional credential, account owner ನಿಂದ confirmation. ತಪ್ಪಾದ ನಿರ್ಧಾರದ ವೆಚ್ಚ ಹೆಚ್ಚು ಇರುವ routes ಗಳಲ್ಲಿ challenge ಬಳಸಿ.

Review

Action ಅನ್ನು ನೇರ completion ಗೆ ಕಳುಹಿಸುವ ಬದಲು queue ಗೆ ಕಳಿಸಿ, ಅಥವಾ ಅದನ್ನು human ಪರಿಶೀಲನೆಗಾಗಿ flag ಮಾಡಿ. blocking ನಿಂದ legitimate users ಗೆ ಹಾನಿಯಾದರೆ ಆದರೆ unattended completion ತುಂಬಾ risky ಆಗಿದ್ದರೆ review ಉಪಯುಕ್ತ.

Limit

Actor ಮತ್ತು route ಗೆ ಹೊಂದಿಸಿದ rate ಅಥವಾ volume limit ಅನ್ವಯಿಸಿ, જેથી automated callers ಜನರಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ workflow ಅನ್ನು ಮೀರಿಸಬಾರದು.

robots.txt access policy ಅಲ್ಲ ಏಕೆ

ಬಹುತೆಕ teams ಮೊದಲು robots.txt ನಿಂದ ಆರಂಭಿಸುತ್ತವೆ, ಮತ್ತು ಅದು crawlers ಗಾಗಿ sensible first signal ಆಗಿದೆ. ಆದರೆ ಅದು agents ಗಾಗಿ access policy ಅಲ್ಲ. crawler operators ವಿಭಿನ್ನ user agents ಗಾಗಿ ವಿಭಿನ್ನ ನಡೆಗಳನ್ನು ದಾಖಲಿಸುತ್ತಾರೆ: Anthropic ತನ್ನ bots ಗಳು robots.txt ನಿರ್ದೇಶನಗಳನ್ನು ಗೌರವಿಸುತ್ತವೆ ಎಂದು ಹೇಳುತ್ತದೆ (Anthropic crawler documentation), ಆದರೆ OpenAI ಯಲ್ಲಿ ChatGPT-User ಬಗ್ಗೆ, ಬಳಕೆದಾರನು ChatGPT ಗೆ ಪ್ರಶ್ನೆ ಕೇಳಿದಾಗ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ robots.txt ನಿಯಮಗಳು ಅನ್ವಯಿಸದೇ ಇರಬಹುದು ಎಂದು ಹೇಳುತ್ತದೆ (OpenAI crawler documentation). robots.txt APIs, MCP tools ಅಥವಾ signed-in workflows ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

access policy request ಅನ್ನು ನಿರ್ವಹಿಸುವ ಸ್ಥಳದಲ್ಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, RFC 9421 ಅಡಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾದ signature ನಂತಹ evidence ಅನ್ನು ಓದಬೇಕು, ಮತ್ತು ಪ್ರತಿ route ಗೆ response ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕು. MCP servers ಗಾಗಿ, MCP authorization specification clients ಗಳು HTTP ಮೂಲಕ access tokens ಹೇಗೆ ಪಡೆಯುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ; actor policies ಅದಕ್ಕೆ ಮೇಲಾಗಿ context ಸೇರಿಸುತ್ತವೆ, ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

Proof of Actor ನಿಮ್ಮ policies ಗೆ ಹೇಗೆ feed ಆಗುತ್ತದೆ

ನಿಮ್ಮ integration ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಪ್ರತಿಯೊಂದು request ನಾಲ್ಕು ಭಾಗಗಳ actor result ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಅದನ್ನು ನಿಮ್ಮ policy ಓದಬಹುದು:

Class: Human, Human + AI, Agent ಅಥವಾ Unknown.
Basis: verified, declared, inferred ಅಥವಾ unknown, ಆದ್ದರಿಂದ ನಿಮ್ಮ policy ಮಾನ್ಯಗೊಂಡ signature ಮತ್ತು ಸ್ವಯಂ-ಘೋಷಿತ client name ಅನ್ನು ವಿಭಿನ್ನವಾಗಿ ಪರಿಗಣಿಸಬಹುದು.
Evidence summary: ಫಲಿತಾಂಶ ಯಾವ ಆಧಾರದ ಮೇಲೆ ನಿಂತಿದೆ ಎಂಬ ಓದಲು ಸುಲಭವಾದ ವಿವರಣೆ, logging ಮತ್ತು review ಗಾಗಿ ಉಪಯುಕ್ತ.
Context: ಯಾವ integration ಮತ್ತು ಯಾವ route ಅದನ್ನು ಉತ್ಪಾದಿಸಿತು ಎಂಬುದು.

Basis ಸ್ಪಷ್ಟವಾಗಿರುವುದರಿಂದ, ನಿಮ್ಮ policies ನಿಖರವಾಗಿರಬಹುದು. "Allow agents" ಎನ್ನುವುದು "read routes ಗಳಲ್ಲಿ verified agents ಗಳಿಗೆ allow ಮಾಡಿ, declared agents ಗಳಿಗೆ rate-limit ಮಾಡಿ, ಉಳಿದ ಎಲ್ಲದರಿಗೂ Unknown fallback ಅನ್ನು ಅನ್ವಯಿಸಿ" ಆಗುತ್ತದೆ. request ನಿಂದ decision ಗೆ ಇರುವ ಸಂಪೂರ್ಣ flow ಅನ್ನು How It Works ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ.

fallback ಗಳು policy ಯ ಭಾಗವೇ

Evidence ಕೊರತೆಯಾದಾಗ ನಿಮ್ಮ ನಡೆ ಹೇಗಿರುತ್ತದೆ ಎಂಬುದರಷ್ಟೇ policy ಯ ಗುಣಮಟ್ಟ. Proof of Actor ಆ ಸಂದರ್ಭಗಳನ್ನು ಮುಚ್ಚಿಹಾಕದೇ ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ.

Unknown: evidence ನಿರ್ಧಾರಕ್ಕೆ ಸಾಕ್ಷ್ಯ ನೀಡಲಿಲ್ಲ. ನಿಮ್ಮ policy ಪ್ರತಿ route ನಲ್ಲಿ Unknown ಅರ್ಥವೇನು ಎಂದು ಹೇಳುತ್ತದೆ. ಅದನ್ನು ಎಂದಿಗೂ Human ಗೆ ಪರಿವರ್ತಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು default ಆಗಿ malicious ಎಂದು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ.
Timeout: ಫಲಿತಾಂಶ ಸಮಯಕ್ಕೆ ಬರಲಿಲ್ಲ. ನಿಮ್ಮ integration ಆ route ಗಾಗಿ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ fallback ಅನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ.
Missing signals: ಒಂದು collector ಕೆಲಸ ಮಾಡಲಿಲ್ಲ ಅಥವಾ ಒಂದು header ಇರಲಿಲ್ಲ. ಫಲಿತಾಂಶ ಅದನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ policy ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ನಡೆದುಕೊಳ್ಳುತ್ತದೆ.

ಪ್ರತಿ route ಗಾಗಿ fail open or fail closed ಯಾವುದು ಎಂದು ನೀವು ಆಯ್ಕೆ ಮಾಡುತ್ತೀರಿ. fail open ಎಂದರೆ Proof of Actor ಇಲ್ಲದಂತೆ request ಮುಂದುವರಿಯುತ್ತದೆ; fail closed ಎಂದರೆ ನಿಮ್ಮ existing stronger check ಅನ್ವಯಿಸುತ್ತದೆ. low-risk routes ಸಾಮಾನ್ಯವಾಗಿ fail open ಆಗಿರುತ್ತವೆ. sensitive actions ಸಾಮಾನ್ಯವಾಗಿ fail closed ಆಗಿರುತ್ತವೆ. ನೀವು ಇದನ್ನು per risk tier ಹೊಂದಿಸುತ್ತೀರಿ, global ಆಗಿ ಅಲ್ಲ.

identity, credential ಮತ್ತು authorization ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಟ್ಟುಕೊಳ್ಳಿ

Agent access policies ಮೂರು ವಿಭಿನ್ನ layers ಗಳ ಮೇಲೆ ಇರುತ್ತವೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ ಇಡುವುದು ಅತ್ಯಂತ ಹಾನಿಕರ ತಪ್ಪುಗಳನ್ನು ತಡೆಯುತ್ತದೆ.

Identity evidence ಯಾವ ವಿಧದ actor ಕರೆ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಅದನ್ನು ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ. Proof of Actor ಇದನ್ನು ಒದಗಿಸುತ್ತದೆ.
Credentials ಯಾವ account ಹೊಣೆಗಾರ ಎಂಬುದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ. ನಿಮ್ಮ session, token ಅಥವಾ API key ಇದನ್ನು ಒದಗಿಸುತ್ತದೆ.
Authorization ಈ caller ಈ action ನ್ನು ಮಾಡಬಹುದೇ ಎಂಬುದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ. ನಿಮ್ಮ permission model ಇದನ್ನು ಒದಗಿಸುತ್ತದೆ.

Verified agent identity ಇದ್ದರೆ agent authorized ಎಂದು, ಅಥವಾ ಯಾರಾದರೂ ಅದಕ್ಕೆ authority ನೀಡಿದರೆಂದು, ಅಥವಾ ಅದರ action ಸುರಕ್ಷಿತ ಎಂದು ಅರ್ಥವಲ್ಲ. Routing ಮತ್ತು context ಸೇರಿಸಲು actor ಫಲಿತಾಂಶಗಳನ್ನು ಬಳಸಿ. permission ನೀಡಲು ನಿಮ್ಮ authorization model ಬಳಸಿ. Detection & Limitations ಪುಟವು ಯಾವ ರೀತಿಯ evidence ಏನು ಸ್ಥಾಪಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ವಿವರಿಸುತ್ತದೆ.

ಏನನ್ನೂ ಮುರಿಯದೆ ಬಿಡುಗಡೆ ಮಾಡಿರಿ

agent access policies ಪರಿಚಯಿಸಲು ಅತ್ಯಂತ ಸುರಕ್ಷಿತ ಮಾರ್ಗ stages ಗಳಲ್ಲಿದೆ.

Observe. observation mode ನಲ್ಲಿ Proof of Actor ಅನ್ನು install ಮಾಡಿ. ನಿಮ್ಮ users ಗಾಗಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ; ಫಲಿತಾಂಶಗಳನ್ನು ದಾಖಲಿಸಲಾಗುತ್ತದೆ.
Understand. ಯಾವ actor ಗಳು ಯಾವ route ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ, ಪ್ರತಿ ಒಂದರ ಮೇಲೆ unknown rate ಎಷ್ಟು, ಮತ್ತು ನೀವು ಈಗಾಗಲೇ ತಿಳಿದಿರುವುದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿರುವ ಯಾವುದೇ ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
Preview. ಒಂದು policy ಅನ್ನು preview ನಲ್ಲಿ run ಮಾಡಿ, enforce ಮಾಡದೆ ಅದು ಏನು ಮಾಡುತ್ತಿತ್ತು ಎಂಬುದನ್ನು log ಮಾಡಿ.
Enforce narrowly. evidence ಸ್ಪಷ್ಟವಾಗಿ ಅದನ್ನು ಬೆಂಬಲಿಸುವ ಒಂದು route ನಲ್ಲಿ policy ಅನ್ನು enable ಮಾಡಿ. outcomes ಗಳನ್ನು ಗಮನಿಸಿ.
Expand. confidence ಹೆಚ್ಚಾದಂತೆ ಇನ್ನಷ್ಟು routes ಗಳಿಗೆ ವಿಸ್ತರಿಸಿ.

rolling out actor-aware policies safely ಕುರಿತ guide ಪ್ರತಿ stage ಅನ್ನು ವಿವರವಾಗಿ ಕರೆದೊಯ್ಯುತ್ತದೆ, ಮತ್ತು protecting sensitive actions without blocking agents high-stakes routes ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ನಿಮ್ಮ team ಗೆ ಏನು ಸಿಗುತ್ತದೆ

Proof of Actor ಜೊತೆಗೆ, ನಿಮ್ಮ team ಗೆ ಮೂರು capabilities ಇರುವ ಒಂದು integration ಸಿಗುತ್ತದೆ. Detect actor signals ಸಂಗ್ರಹಿಸಿ verified assertions ಗಳನ್ನು inferences ಗಳಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. Understand actor analytics, trends ಮತ್ತು ಪ್ರತಿಯೊಂದು ಫಲಿತಾಂಶದ ಹಿಂದಿನ evidence ಅನ್ನು ತೋರಿಸುತ್ತದೆ, Unknown ಅನ್ನು visible ಆಗಿ ಇಟ್ಟುಕೊಂಡು. Route ಈ ಪುಟದಲ್ಲಿ ವಿವರಿಸಿದ policies ಬರೆಯಲು ಮತ್ತು ನೀವು ಆಯ್ಕೆಮಾಡುವಲ್ಲಿ ಅವನ್ನು ಅನ್ವಯಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ. private beta ಸಮಯದಲ್ಲಿ, routing policies ಪ್ರತಿ founding team ಜೊತೆಗೆ ವಿನ್ಯಾಸಗೊಳಿಸಲ್ಪಟ್ಟು ನಿಮ್ಮ own application code ನಲ್ಲಿ ಚಾಲಿತವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ನೀವು ಸಂಪೂರ್ಣ control ಇಟ್ಟುಕೊಳ್ಳುತ್ತೀರಿ.

ತಪ್ಪಿಸಬೇಕಾದ ಸಾಮಾನ್ಯ policy ತಪ್ಪುಗಳು

ಮೊದಲ ಬಾರಿ agent access ವಿನ್ಯಾಸಗೊಳಿಸುವ teams ಕೆಲವೊಂದು ತಪ್ಪುಗಳನ್ನು ಮರುಕಳಿಸುತ್ತವೆ. ಅವನ್ನು ತಪ್ಪಿಸುವುದರಿಂದ ವಾರಗಳ rework ಉಳಿಯುತ್ತದೆ.

Default ಆಗಿ ಪ್ರತಿಯೊಂದು agent ಅನ್ನು block ಮಾಡುವುದು. Legitimate agents ನಂತರ ನಿಮ್ಮನ್ನು bypass ಮಾಡಲು route ಹುಡುಕುತ್ತಾರೆ, ಬಹುಮಾರ್ಗ interface ನ್ನು scrape ಮಾಡುವ ಮೂಲಕ, ಇದು structured path ಗಿಂತ ರಕ್ಷಿಸಲು ಕಷ್ಟ.
Declared name ನ ಮೇಲೆ trust ಇಡುವುದು. ತನ್ನನ್ನು ಮಾತ್ರ ಹೆಸರಿಸುವ client claim ಮಾಡಿದೆ, proof ನೀಡಿಲ್ಲ. unverified caller ಗೆ ನೀಡುವ ರೀತಿಯಲ್ಲೇ ಅದನ್ನು ಕೈಲೂಗಿ.
ಎಲ್ಲೆಡೆ ಒಂದೇ fallback ಬಳಸುವುದು. public pricing page ನಲ್ಲಿ ಇರುವ Unknown ಮತ್ತು password change ನಲ್ಲಿ ಇರುವ Unknown ವಿಭಿನ್ನ ಸಂದರ್ಭಗಳು. ಪ್ರತಿ route ಗೆ ತನ್ನದೇ ಉತ್ತರ ಬೇಕು.
Inference ನಿಂದ ಜನರ ಕುರಿತು ನಿರ್ಧಾರ ಮಾಡುವುದು. Actor ಫಲಿತಾಂಶಗಳು routing ಗಾಗಿ context ಮಾತ್ರ, ವ್ಯಕ್ತಿಯ ಕುರಿತು verdict ಅಲ್ಲ. consequential decisions ಅನ್ನು ನಿಮ್ಮ own controls ಮತ್ತು review ನಲ್ಲಿ ಇರಿಸಿ.
Observation ಅನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು. day one ನಲ್ಲಿ enforce ಮಾಡುವುದರಿಂದ customer complaints ಮೂಲಕ false positives ಗಳು ಗೊತ್ತಾಗುತ್ತವೆ. ಮೊದಲು observe ಮಾಡಿ, ನಂತರ evidence ಸ್ಪಷ್ಟವಾಗಿರುವ ಸ್ಥಳದಲ್ಲಿ enforce ಮಾಡಿ.

ಪ್ರತಿ enforcement ಹೆಜ್ಜೆಗೆ ಮೊದಲು ನಿಮ್ಮ security, product ಮತ್ತು support leads ಜೊತೆ short policy review ನಡೆಸುವುದರಿಂದ ಇವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಆರಂಭದಲ್ಲೇ ಸಿಗುತ್ತವೆ.

founding developer program ನಿಂದ ಆರಂಭಿಸಿ

Proof of Actor private beta ಯಲ್ಲಿದೆ. ಆಯ್ಕೆಮಾಡಲಾದ founding development teams ಗಳು agreed usage limits ಒಳಗೆ 12 months ವರೆಗೆ ಉಚಿತ access, ಮತ್ತು ನಿಮ್ಮ ಮೊದಲ policies ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ ನಮ್ಮ engineers ನೇರ support ಪಡೆಯಬಹುದು.

ನಿಮ್ಮ application AI agents ಗಳನ್ನು ಹೇಗೆ ಕೈಲೂಗೊಳ್ಳಬೇಕು ಎಂದು ನೀವು ನಿರ್ಧರಿಸುತ್ತಿದ್ದರೆ, apply for early access. ಯಾವ routes ಅತ್ಯಂತ ಮುಖ್ಯ ಮತ್ತು ಯಾವ ನಿರ್ಧಾರಗಳನ್ನು ನೀವು ತೆಗೆದುಕೊಳ್ಳಲು ಬಯಸುತ್ತೀರಿ ಎಂದು ನಮಗೆ ತಿಳಿಸಿ, ಮತ್ತು ನಾವು ನಿಮಗೆ ಹೊಂದುವ policies ನಿರ್ಮಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತೇವೆ. ಇದು APIs ಮತ್ತು MCP servers ಗಳಿಗೂ ಹೇಗೆ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನೂ ನೀವು ನೋಡಬಹುದು.

ಮೂಲಗಳು

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.

DEVELOPERS ಗಾಗಿ

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent ಅಥವಾ Unknown.
basis: ಸಾಕ್ಷ್ಯದ ಬಲ ಎಷ್ಟು ಎಂಬುದು: verified, declared, inferred ಅಥವಾ unknown.
evidence: ಫಲಿತಾಂಶದ ಹಿಂದೆ ಇರುವ signals, ಇದರಿಂದ ನಿಮ್ಮ ತಂಡಕ್ಕೆ ಕಾರಣ ಕಾಣುತ್ತದೆ.

observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ: ನಿಮ್ಮ logs ಗಳ ಪಕ್ಕದಲ್ಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು ನೀವು ಒಂದು policy ಆಯ್ಕೆ ಮಾಡುವವರೆಗೆ ಏನನ್ನೂ ಬದಲಾಯಿಸಬೇಡಿ. Node.js ಏಕೀಕರಣ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಓದಿ

ಪದೇಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

AI agent ಪ್ರವೇಶ ನೀತಿ ಎಂದರೆ ಏನು?

ಅದು ವಿನಂತಿ ಮಾಡುವ actor ನ ವಿಧದ ಆಧಾರದಲ್ಲಿ ನಿಮ್ಮ application ಅನ್ವಯಿಸುವ ನಿಯಮ, ಉದಾಹರಣೆಗೆ read-only route ಗಳಲ್ಲಿ verified agents ಗಳಿಗೆ allow ಮಾಡುವುದು ಅಥವಾ high-impact actions ಗೆ ಹೆಚ್ಚಿನ credential ಕೇಳುವುದು. Proof of Actor actor ಫಲಿತಾಂಶವನ್ನು ಒದಗಿಸುತ್ತದೆ; ನಿಮ್ಮ ನೀತಿ response ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

Proof of Actor ನೀತಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ enforce ಮಾಡುತ್ತದೆಯೇ?

ಇಲ್ಲ. ಪ್ರತಿಯೊಂದು integration ಕೂಡ observation mode ನಲ್ಲಿ ಆರಂಭವಾಗುತ್ತದೆ, ಮತ್ತು ನೀತಿಗಳು ನಿಮ್ಮ team ನಿಂದ, ಪ್ರತಿ route ಗೆ, ಆ workflow ಗೆ ಅವು ಸೂಕ್ತವೆಂದು ನಿಮಗೆ ಖಚಿತವಾದಾಗ enable ಮಾಡಲಾಗುತ್ತವೆ.

actor Unknown ಆಗಿದ್ದರೆ ಅಥವಾ check timeout ಆದರೆ ಏನಾಗುತ್ತದೆ?

ಪ್ರತಿ route ಗಾಗಿ ನೀವು ಸ್ಪಷ್ಟವಾದ fallback ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತೀರಿ, ಉದಾಹರಣೆಗೆ public reads ಗೆ allow ಮಾಡಿ ಮತ್ತು account ಬದಲಾವಣೆಗಳ ಮೇಲೆ existing checks ಅನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. Unknown ಮತ್ತು timeout ಗಳು ಎಂದಿಗೂ Human ಗೆ default ಆಗುವುದಿಲ್ಲ.

ನಾನು ಎಲ್ಲಾ AI agent ಗಳನ್ನು block ಮಾಡಬೇಕೇ?

ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಲ. ಅನೇಕ agent ಗಳು ಮಾನ್ಯ ಪಾಲ್ಗೊಳ್ಳುವವರು. ನೀತಿಗಳು ಅವರಿಗೆ structured path ನೀಡಲು, ಅಗತ್ಯವಿರುವಲ್ಲಿ ಅವರನ್ನು limit ಮಾಡಲು ಮತ್ತು sensitive actions ಗಾಗಿ ಹೆಚ್ಚು ಬಲವಾದ checks ಅನ್ನು ಕಾಯ್ದಿರಿಸಲು ನೆರವಾಗುತ್ತವೆ.

ನೀತಿಗಳು ಜನರ ಬಗ್ಗೆ ನಿರ್ಧಾರಗಳನ್ನು ಮಾಡಬಹುದೇ?

Proof of Actor ಫಲಿತಾಂಶಗಳನ್ನು ಉದ್ಯೋಗ, credit ಅಥವಾ ಅಗತ್ಯ services ಗೆ ಪ್ರವೇಶದಂತಹ ವ್ಯಕ್ತಿಗಳ ಕುರಿತು ಪರಿಣಾಮಕಾರಿ ನಿರ್ಧಾರಗಳಿಗೆ ಏಕೈಕ ಆಧಾರವಾಗಿ ಬಳಸಬಾರದು. ಅವುಗಳನ್ನು ನಿಮ್ಮ own controls ಜೊತೆಗೆ routing ಮತ್ತು context ಗಾಗಿ ಬಳಸಿ.

ನಿಮ್ಮ app ಅನ್ನು ಯಾರು ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.

founding developers ನ ಸಣ್ಣ ಗುಂಪಿಗಾಗಿ private beta.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿ ಮೌಲ್ಯವನ್ನು ವೀಕ್ಷಿಸಿ

ಮೊದಲು ಮಾತನಾಡಲು ಇಷ್ಟವಿದೆಯೆ? ಸ್ಥಾಪಕರೊಂದಿಗೆ ಮಾತನಾಡಿ