ప్రధాన కంటెంట్‌కు దాటవేయండి
AGENT యాక్సెస్ విధానాలు

మీరు నియంత్రించే విధానాలతో AI agents ను route చేయండి

మీ application మనుషులు, AI-సహాయంతో పనిచేసే users, మరియు autonomous agents ను route by route ఎలా నిర్వహించాలో నిర్ణయించండి. Proof of Actor evidence ను అందిస్తుంది; మీ policies నిర్ణయాన్ని తీసుకుంటాయి.

Toshendra Sharma

రచన Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

అందరికీ ఒకే policy ఇప్పుడేమీ సరిపోదు

చాలా applications ఒకే రకమైన user ను దృష్టిలో ఉంచుకుని నిర్మించబడ్డాయి: account లో sign in అయి interface లో క్లిక్ చేస్తూ వెళ్లే person. Access control ఆ అంచనాను అనుసరించింది. session valid అయితే request ముందుకు వెళుతుంది. అది automated గా కనిపిస్తే CAPTCHA లేదా block కనిపిస్తుంది.

ఆ model ఇప్పుడు విరుగుతోంది. ఈ రోజు అదే application మనుషులను, AI assistants తో పనిచేసే మనుషులను, మరియు ఎవరో ఒకరి తరఫున పనిచేసే autonomous agents ను సేవ చేస్తోంది. కొన్ని agents customer యొక్క own integrations. కొన్ని AI assistants, documentation ను fetch చేస్తున్నవి. కొన్ని crawlers. మరికొన్ని మీ product ను దుర్వినియోగం చేయడానికి ప్రయత్నిస్తున్నాయి. ఒకే yes-or-no rule ఇవన్నింటికీ బాగా సరిపోదు.

AI agent routing and access policies ఆ ఒకే rule ను deliberate నిర్ణయాల సమితితో మారుస్తాయి: ఏ actor కు ఏ experience, ఏ routes లో, ఏ పరిస్థితుల్లో ఇవ్వాలి. 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: వెల్లడించిన AI-assisted content ను accept చేసి, routing కోసం label చేయండి.
  • Signup: existing checks ను కొనసాగించండి; inferred actor result ఆధారంగా మాత్రమే ఎప్పుడూ నిర్ణయించవద్దు.

ఈ ప్రతీది ప్రతి agent ను abuse గా చూడకుండా, అలాగే ప్రతి agent ను అంధంగా నమ్మకుండా actor కు స్పందిస్తుంది. ఆ సమతుల్యతే 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 సాధారణంగా ముందుకు సాగనివ్వండి. public లేదా low-risk routes పై ఎక్కువ traffic, ఎక్కువ 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, అదనపు credential, account owner నుండి confirmation. తప్పు నిర్ణయం ఖర్చుతో కూడుకున్న routes లో challenges ను ఉపయోగించండి.

Review

Action ను straight to completion కు కాకుండా queue లోకి పంపండి లేదా human పరిశీలన కోసం flag చేయండి. blocking వల్ల legitimate users కు నష్టం వాటిల్లే, కానీ unattended completion చాలా ప్రమాదకరమైన చోట review ఉపయోగపడుతుంది.

Limit

Actor మరియు route కు సరిపోయే rate లేదా volume limit ను వర్తింపజేయండి, తద్వారా people కోసం రూపొందించిన workflow ను automated callers ముంచెత్తలేరు.

robots.txt ఎందుకు access policy కాదు

చాలా teams robots.txt తో ప్రారంభిస్తాయి, మరియు అది crawlers కోసం sensible మొదటి signal. కానీ అది agents కోసం access policy కాదు. Crawler operators వేర్వేరు user agents కోసం వేర్వేరు behaviour ను document చేస్తారు: Anthropic తన bots robots.txt directives ను గౌరవిస్తాయని చెబుతుంది (Anthropic crawler documentation), అయితే OpenAI ChatGPT-User విషయంలో, user ChatGPT కు ఒక question అడిగినప్పుడు ఇది పనిచేస్తుంది కాబట్టి robots.txt rules వర్తించకపోవచ్చని పేర్కొంటుంది (OpenAI crawler documentation). robots.txt APIs, MCP tools లేదా signed-in workflows గురించి ఏమీ చెప్పదు.

Access policy request నిర్వహించబడే చోటే నడవాలి, RFC 9421 కింద verify చేసిన signature వంటి evidence ను చదవాలి, మరియు ప్రతి route కు ఒక response ఎంచుకోవాలి. MCP servers కోసం, MCP authorization specification clients HTTP ద్వారా access tokens ఎలా పొందాలో నిర్వచిస్తుంది; actor policies దాని పైన context ను జోడిస్తాయి, దాన్ని భర్తీ చేయవు.

మీ policies కు Proof of Actor ఎలా feed చేస్తుంది

మీ integration మూల్యాంకనం చేసే ప్రతి request నాలుగు భాగాలతో actor result ను ఉత్పత్తి చేస్తుంది, దాన్ని మీ policy చదవగలదు:

  • Class: Human, Human + AI, Agent లేదా Unknown.
  • Basis: verified, declared, inferred లేదా unknown, కాబట్టి మీ policy validated signature ను self-declared client name నుండి వేరుగా పరిగణించగలదు.
  • Evidence summary: result ఏదానిపై ఆధారపడి ఉందో చదవదగిన వివరణ, logging మరియు review కు ఉపయోగకరం.
  • Context: ఏ integration మరియు ఏ route అది ఉత్పత్తి చేసిందో.

Basis explicit గా ఉండటం వల్ల, మీ policies ఖచ్చితంగా ఉండగలవు. "Allow agents" అంటే "read routes పై verified agents ను allow చేయండి, declared agents కు rate-limit వర్తింపజేయండి, మిగతా అన్నిటికీ Unknown fallback ను ఉపయోగించండి." request నుండి decision వరకు పూర్తి flow How It Works లో వివరించబడింది.

Fallbacks policy లో భాగమే

Evidence లేనప్పుడు policy ఎలా ప్రవర్తిస్తుందో దానిపైనే దాని quality ఆధారపడి ఉంటుంది. Proof of Actor ఆ సందర్భాలను దాచకుండా explicit గా చేస్తుంది.

  • Unknown: evidence ఒక determination కు మద్దతు ఇవ్వలేదు. ప్రతి route లో Unknown అంటే ఏమిటో మీ policy చెబుతుంది. దాన్ని ఎప్పుడూ Human గా మార్చరు, default గా malicious గా కూడా పరిగణించరు.
  • Timeout: result సమయానికి రాలేదు. మీ integration ఆ route కోసం మీరు ఎంచుకున్న fallback ను వర్తింపజేస్తుంది.
  • Missing signals: ఒక collector run కాలేదు లేదా ఒక header అందుబాటులో లేదు. Result అది ప్రతిబింబిస్తుంది, మరియు మీ 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 అవుతాయి. మీరు దీన్ని globally కాదు, ప్రతి risk tier కు విడిగా సెట్ చేస్తారు.

Identity, credentials మరియు authorization ను వేరు ఉంచండి

Agent access policies మూడు వేర్వేరు layers పైన ఉంటాయి, వాటిని వేరు ఉంచడం అత్యంత హానికరమైన తప్పులను నివారిస్తుంది.

  1. Identity evidence ఏ kind of actor calling చేస్తోంది, దాన్ని ఏది నిరూపిస్తోంది అనే ప్రశ్నకు సమాధానం ఇస్తుంది. Proof of Actor ఇది అందిస్తుంది.
  2. Credentials ఏ account బాధ్యత వహిస్తోంది అనే ప్రశ్నకు సమాధానం ఇస్తాయి. మీ session, token లేదా API key ఇది అందిస్తుంది.
  3. Authorization ఈ caller ఈ action చేయగలడా అనే ప్రశ్నకు సమాధానం ఇస్తుంది. మీ permission model ఇది అందిస్తుంది.

Verified agent identity ఉండటం అంటే agent authorized అని, లేదా ఒక వ్యక్తి దానికి authority అప్పగించాడని, లేదా దాని action safe అని అర్థం కాదు. Actor results ను route చేయడానికి మరియు context జోడించడానికి ఉపయోగించండి. Permission ఇవ్వడానికి మీ authorization model ను ఉపయోగించండి. Detection & Limitations పేజీ ప్రతి evidence రకం ఏమి స్థాపించగలదో ఖచ్చితంగా వివరిస్తుంది.

ఏదీ పాడుచేయకుండా rollout చేయండి

Agent access policies ను introduce చేయడానికి అత్యంత సురక్షిత మార్గం దశల వారీగా చేయడం.

  1. Observe. observation mode లో Proof of Actor ను install చేయండి. మీ users కోసం ఏదీ మారదు; results record అవుతాయి.
  2. Understand. ఏ actors ఏ routes ను ఉపయోగిస్తున్నారు, ప్రతి route లో unknown rate ఎంత ఉంది, మరియు మీకు ఇప్పటికే తెలిసినదానితో విరుద్ధంగా ఉన్న ఏ results అయినా సమీక్షించండి.
  3. Preview. Policy ను preview లో నడపండి, enforce చేయకుండా అది ఏమి చేసేదో log చేయండి.
  4. Enforce narrowly. Evidence స్పష్టంగా మద్దతు ఇచ్చే ఒక route పై policy ను enable చేయండి. Outcomes ను గమనించండి.
  5. Expand. Confidence పెరిగేకొద్దీ మరిన్ని routes కు విస్తరించండి.

rolling out actor-aware policies safely అనే guide ప్రతి దశను వివరిస్తుంది, మరియు 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, మరియు ప్రతి result వెనుక ఉన్న evidence ను చూపిస్తుంది, Unknown ను కనిపించేలా ఉంచుతుంది. Route ఈ పేజీలో వివరించిన policies ను రాయడానికి మరియు మీరు ఎంచుకున్న చోట వర్తింపజేయడానికి అవకాశం ఇస్తుంది. Private beta సమయంలో, routing policies ప్రతి founding team తో కలిసి రూపొందించబడతాయి మరియు మీ own application code లో నడుస్తాయి, కాబట్టి మీరు పూర్తి control ను ఉంచుకుంటారు.

నివారించాల్సిన సాధారణ policy తప్పులు

మొదటిసారి agent access రూపొందించే teams కొన్ని తప్పులను మళ్లీ మళ్లీ చేస్తాయి. వాటిని నివారించడం వారాల rework ను ఆదా చేస్తుంది.

  • ప్రతి agent ను default గా block చేయడం. Legitimate agents అప్పుడు మీ చుట్టూ route అవుతాయి, తరచుగా మీరు people కోసం నిర్మించిన interface ను scrape చేయడం ద్వారా, అది structured path కంటే రక్షించడం మరింత కష్టం.
  • Declared name ను నమ్మడం. తాను తానూ పేరు చెప్పుకున్న client ఒక claim మాత్రమే చేసింది, proof ఇవ్వలేదు. మీరు unverified caller కు ఇచ్చే treatment నే దీనికీ ఇవ్వండి.
  • ప్రతిచోటా ఒకే fallback ఉపయోగించడం. Public pricing page పై Unknown మరియు password change పై Unknown వేర్వేరు పరిస్థితులు. ప్రతి route కు దాని own answer అవసరం.
  • Inference ఆధారంగా మనుషుల గురించి నిర్ణయించడం. Actor results routing కోసం context మాత్రమే, వ్యక్తిపై తీర్పు కాదు. Consequential decisions ను మీ own controls మరియు review వద్దే ఉంచండి.
  • Observation ను దాటవేయడం. Day one నుంచే enforce చేస్తే customer complaints ద్వారా false positives బయటపడతాయి. ముందుగా observe చేయండి, evidence స్పష్టంగా ఉన్న చోట మాత్రమే enforce చేయండి.

ప్రతి enforcement step ముందు మీ security, product మరియు support leads తో చిన్న policy review చేయడం వీటిలో చాలా తప్పులను ముందుగానే పట్టుకుంటుంది.

Founding developer program తో ప్రారంభించండి

Proof of Actor private beta లో ఉంది. ఎంపికైన founding development teams కు అంగీకరించిన usage limits లోపు, 12 months వరకు ఉచిత access, అలాగే మీ first policies రూపకల్పనలో మా engineers నుండి direct support లభించవచ్చు.

మీ application AI agents ను ఎలా నిర్వహించాలి అని నిర్ణయిస్తున్నట్లయితే, apply for early access. ఏ routes అత్యంత ముఖ్యమో, ఏ decisions మీరు తీసుకోవాలనుకుంటున్నారో మాకు చెప్పండి, మీకు సరిపోయే policies నిర్మించడంలో మేము సహాయం చేస్తాము. ఇది APIs మరియు MCP servers కు ఎలా వర్తిస్తుందో కూడా చూడవచ్చు.

Sources

డెవలపర్ల కోసం

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
evidence ఎంత బలంగా ఉందో: verified, declared, inferred లేదా unknown.
evidence
result వెనుక ఉన్న signals, అందువల్ల మీ team ఎందుకు అని చూడగలదు.

observation mode లో ప్రారంభించండి: results ను మీ logs పక్కనే నమోదు చేయండి మరియు మీరు ఒక policy ఎంచుకునే వరకు ఏమీ మార్చవద్దు. Node.js integration guide ను చదవండి

తరచుగా అడిగే ప్రశ్నలు

AI agent access policy అంటే ఏమిటి?

ఇది request పంపుతున్న actor రకాన్ని ఆధారంగా మీ application వర్తింపజేసే rule. ఉదాహరణకు, read-only routes లో verified agents ను allow చేయడం లేదా high-impact actions కు మరింత బలమైన credential అడగడం. Proof of Actor actor result ను ఇస్తుంది; మీ policy response ను నిర్ణయిస్తుంది.

Proof of Actor policies ను ఆటోమేటిక్‌గా enforce చేస్తుందా?

లేదు. ప్రతి integration observation mode లోనే ప్రారంభమవుతుంది, మరియు మీ team route by route గా అవి ఆ workflow కు సరిపోతాయని నమ్మినప్పుడు policies ను enable చేస్తుంది.

actor Unknown గా ఉన్నప్పుడు లేదా check timeout అయినప్పుడు ఏమి జరుగుతుంది?

ప్రతి route కోసం మీరు ఒక explicit fallback ను నిర్వచిస్తారు, ఉదాహరణకు public reads ను allow చేయడం మరియు account changes పై existing checks ను కొనసాగించడం. Unknown మరియు timeouts ఎప్పుడూ Human గా default కావు.

అన్ని AI agents ను block చేయాలా?

సాధారణంగా కాదు. చాలా agents చట్టబద్ధమైన పాల్గొనేవారే. Policies వాటికి structured path ఇవ్వడానికి, అవసరమైన చోట వాటిని limit చేయడానికి, మరియు sensitive actions కోసం మరింత బలమైన checks ను నిలిపి ఉంచడానికి సహాయపడతాయి.

Policies మనుషుల గురించి నిర్ణయాలు తీసుకోగలవా?

Proof of Actor results ను ఉద్యోగం, credit లేదా essential services కు access వంటి వ్యక్తులపై ప్రభావం చూపే నిర్ణయాలకు ఏకైక ఆధారంగా ఉపయోగించకూడదు. వాటిని routing మరియు context కోసం, మీ own controls తో కలిసి ఉపయోగించండి.

మీ app ను ఎవరు ఉపయోగిస్తున్నారో తెలుసుకోండి.

founding developers యొక్క చిన్న group కోసం private beta.

ముందుగా మాట్లాడాలనుకుంటున్నారా? foundersతో మాట్లాడండి