ஏஜெண்ட் அணுகல் கொள்கைகள்

நீங்கள் கட்டுப்படுத்தும் policies-உடன் AI agents-ஐ route செய்யுங்கள்

உங்கள் application, people, AI உதவியுடன் செயல்படும் users, மற்றும் autonomous agents ஆகியவற்றை route by route எப்படி கையாள வேண்டும் என்பதைத் தீர்மானியுங்கள். Proof of Actor evidence-ஐ வழங்குகிறது; முடிவை உங்கள் policies எடுக்கின்றன.

முன்கூட்டிய அணுகலைப் பெறுக எப்படி செயல்படுகிறது என்பதை ஆராய்க

ஆசிரியர் Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

அனைவருக்கும் ஒரே policy இனி போதுமானதல்ல

பெரும்பாலான applications, ஒரு interface-ஐக் கிளிக் செய்து, account-க்கு sign in செய்த ஒரு person என்ற ஒரே வகை user-ஐ மனதில் கொண்டு வடிவமைக்கப்பட்டன. Access control அந்த கருதுகோளைப் பின்தொடர்ந்தது. Session valid என்றால் request செல்லும். அது automated போலத் தெரிந்தால் CAPTCHA அல்லது block தோன்றும்.

அந்த model உடைந்து வருகிறது. இன்று அதே application people-ஐ, AI assistants-உடன் பணியாற்றும் people-ஐ, மற்றும் ஒருவரின் சார்பில் செயல்படும் autonomous agents-ஐ சேவைக்கிறது. சில agents customers-ன் சொந்த integrations. சில AI assistants documentation-ஐ fetch செய்கின்றன. சில crawlers. சில உங்கள் product-ஐ abuse செய்ய முயல்கின்றன. ஒரு yes-or-no rule மட்டும் அனைத்திற்கும் சரியாக சேவை செய்ய முடியாது.

AI agent routing and access policies அந்த ஒரே rule-ஐ, deliberate decisions-களின் தொகுப்பாக மாற்றுகின்றன: எந்த actor-க்கு எந்த அனுபவம், எந்த routes-ல், எந்த நிபந்தனைகளில். Proof of Actor உங்கள் application-க்கு இந்த decisions-ஐ எடுக்க 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, ஒரு class of actor, தேவையான evidence-ன் strength, மற்றும் response-ஐ குறிப்பிடும். உதாரணமாக:

Read-only catalog routes: verified agents-ஐ allow செய்து structured response-ஐ வழங்குங்கள்; declared agents-க்கு standard rate limit-ஐ அனுமதியுங்கள்.
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 result-ன் அடிப்படையில் மட்டும் ஒருபோதும் முடிவெடுக்க வேண்டாம்.

இவற்றில் ஒவ்வொன்றும் ஒவ்வொரு agent-ஐயும் abuse என்று கருதாமல், மற்றும் ஒவ்வொரு agent-ஐயும் blind-ஆக நம்பாமல், 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-ல் உள்ள பெரும்பாலான agent traffic உட்பட, simply allow செய்யப்பட வேண்டும்.

Adapt

Actor-க்கு ஏற்றவாறு அனுபவத்தை மாற்றவும். Human-shaped interface-க்கு பதிலாக ஒரு verified agent-க்கு structured API response அல்லது பக்கத்தின் Markdown version-ஐ வழங்கவும். serving AI agents structured content என்ற guide இந்த pattern-ஐ விரிவாகப் பார்க்கிறது.

Challenge

மேலும் வலுவான ஒன்றைக் கேளுங்கள்: புதிய login, கூடுதல் credential, account owner-இருந்து confirmation. தவறான முடிவின் செலவு உயர்ந்த routes-ல் challenges-ஐப் பயன்படுத்துங்கள்.

Review

Action-ஐ நேரடியாக completion-க்கு அனுப்பாமல் queue-க்கு கொண்டு செல்லவும், அல்லது மனிதர் சரிபார்க்க flag செய்யவும். Blocking legitimate users-க்கு பாதிப்பை ஏற்படுத்தும், ஆனால் unattended completion மிக ஆபத்தான இடங்களில் Review பயனுள்ளதாக இருக்கும்.

Limit

Actor மற்றும் route-க்கு ஏற்ப ஒழுங்கமைக்கப்பட்ட rate அல்லது volume limit-ஐப் பயன்படுத்துங்கள், ώστε automated callers people-க்கு வடிவமைக்கப்பட்ட workflow-ஐ overwhelmed செய்ய முடியாது.

robots.txt access policy அல்லாதது ஏன்

பல teams robots.txt-இல் தொடங்குகின்றன, அது crawlers-க்கு ஒரு நியாயமான first signal. ஆனால் அது agents-க்கு access policy அல்ல. Crawler operators, வெவ்வேறு user agents-க்கு வெவ்வேறு behaviour-ஐ ஆவணப்படுத்துகிறார்கள்: Anthropic அதன் bots robots.txt directives-ஐ பின்பற்றுகின்றன என்று கூறுகிறது (Anthropic crawler documentation), OpenAI, பயனர் ChatGPT-க்கு ஒரு கேள்வி கேட்கும் போது செயல்படும் ChatGPT-User-க்கு, அந்த action ஒரு user-ஆல் தொடங்கப்படுவதால் robots.txt rules பொருந்தாமல் போகலாம் என்று குறிப்பிடுகிறது (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-மும் உங்கள் policy படிக்கக்கூடிய நான்கு பகுதிகளைக் கொண்ட actor result-ஐ உருவாக்குகிறது:

Class: Human, Human + AI, Agent அல்லது Unknown.
Basis: verified, declared, inferred அல்லது unknown, எனவே validated signature-ஐ self-declared client name-இலிருந்து உங்கள் policy வேறுபடுத்திக் கையாள முடியும்.
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-ல் விவரிக்கப்பட்டுள்ளது.

Fallbacks policy-இன் ஒரு பகுதி

Evidence இல்லாதபோது policy எப்படி நடக்கும் என்பதே அதன் மதிப்பை நிர்ணயிக்கிறது. Proof of Actor அந்த நிலைகளை மறைக்காமல் தெளிவாகக் காட்டுகிறது.

Unknown: evidence ஒரு determination-க்கு போதுமான ஆதரவு அளிக்கவில்லை. ஒவ்வொரு route-க்கும் Unknown என்றால் என்ன என்பதை உங்கள் policy வரையறுக்கிறது. அது ஒருபோதும் Human-ஆக மாற்றப்படுவதில்லை, மேலும் default-ஆக malicious என்று கருதப்படுவதில்லை.
Timeout: result நேரத்தில் வரவில்லை. உங்கள் integration அந்த route-க்கு நீங்கள் தேர்ந்த fallback-ஐப் பயன்படுத்துகிறது.
Missing signals: ஒரு collector இயங்கவில்லை அல்லது ஒரு 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 ஆகும். இதை நீங்கள் risk tier-க்கு ஏற்ப தனித்தனியாக அமைக்கிறீர்கள், globally அல்ல.

Identity, credentials மற்றும் authorization-ஐ தனித்தனியாக வைத்திருங்கள்

Agent access policies மூன்று distinct layers-ன் மேல் அமைக்கப்படுகின்றன, அவற்றைத் தனியாக வைத்திருப்பது மிகப்பெரிய தவறுகளைத் தடுக்கும்.

Identity evidence எந்த வகை actor அழைக்கிறது, அதை எது நிரூபிக்கிறது என்பதைக் கூறுகிறது. Proof of Actor இதை வழங்குகிறது.
Credentials எந்த account பொறுப்பானது என்பதை கூறுகின்றன. உங்கள் session, token அல்லது API key இதை வழங்குகிறது.
Authorization இந்த caller இந்த action-ஐ செய்யலாமா என்பதை கூறுகிறது. உங்கள் permission model இதை வழங்குகிறது.

Verified agent identity என்பது agent-க்கு authorization இருப்பதைக் குறிக்காது, ஒரு person அதற்கு authority-ஐ அளித்தார் என்பதையும் குறிக்காது, அல்லது அதன் action பாதுகாப்பானது என்பதையும் குறிக்காது. Actor result-ஐ routing-க்கு மற்றும் context-ஐச் சேர்க்கப் பயன்படுத்துங்கள். Permission வழங்க உங்கள் authorization model-ஐப் பயன்படுத்துங்கள். Detection & Limitations பக்கம் ஒவ்வொரு வகை evidence எதை நிரூபிக்க முடியும் என்பதைத் துல்லியமாக விளக்குகிறது.

எதையும் முறியடிக்காமல் rollout செய்யுங்கள்

Agent access policies-ஐ அறிமுகப்படுத்தும் மிக பாதுகாப்பான வழி, படிப்படியாக முன்னேறுவதுதான்.

Observe. observation mode-ல் Proof of Actor-ஐ நிறுவுங்கள். உங்கள் users-க்கு எதுவும் மாறாது; results பதிவு செய்யப்படும்.
Understand. எந்த actors எந்த routes-ஐ பயன்படுத்துகின்றனர், ஒவ்வொன்றிலும் unknown rate என்ன, மேலும் ஏற்கனவே நீங்கள் அறிந்தவற்றுடன் எந்த results வேறுபடுகின்றன என்பதை மதிப்பாய்வு செய்யுங்கள்.
Preview. Enforcement இல்லாமல், policy என்ன செய்திருக்கும் என்பதை பதிவு செய்து, preview-ல் policy-ஐ இயக்குங்கள்.
Enforce narrowly. evidence அதை தெளிவாக ஆதரிக்கும் ஒரு route-ல் policy-ஐ enable செய்யுங்கள். முடிவுகளை கவனியுங்கள்.
Expand. நம்பிக்கை அதிகரிக்கும் போது மேலும் 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-உடனும் சேர்ந்து வடிவமைக்கப்பட்டு, உங்கள் சொந்த application code-ல் இயங்குகின்றன, எனவே முழு கட்டுப்பாடும் உங்களிடமே இருக்கும்.

தவிர்க்க வேண்டிய பொதுவான policy தவறுகள்

முதன்முறையாக agent access வடிவமைக்கும் teams சில தவறுகளை மீண்டும் மீண்டும் செய்கின்றன. அவற்றைத் தவிர்ப்பது வாரக்கணக்கான rework-ஐக் காப்பாற்றும்.

By default எல்லா agents-ஐயும் block செய்வது. Legitimate agents பின்னர் உங்களைத் தவிர்த்து route ஆகின்றன, பெரும்பாலும் people-க்காக நீங்கள் உருவாக்கிய interface-ஐ scrape செய்வதன் மூலம், இது structured path-ஐ விட பாதுகாப்பது கடினம்.
Declared name-ஐ நம்புவது. தன்னைப் பெயரிட்டு கூறும் client ஒரு claim-ஐ மட்டுமே செய்துள்ளது, proof-ஐ வழங்கவில்லை. அதை நீங்கள் unverified caller-க்கு அளிக்கும் முறையிலேயே கையாளுங்கள்.
எங்கும் ஒரே fallback-ஐப் பயன்படுத்துவது. Public pricing page-ல் உள்ள Unknown மற்றும் password change-ல் உள்ள Unknown என்பது வெவ்வேறு நிலைகள். ஒவ்வொரு route-க்கும் அதன் சொந்த பதில் தேவை.
Inference-இருந்து people-ஐப் பற்றித் தீர்மானிப்பது. Actor results routing-க்கு context, தனிநபர் குறித்த verdict அல்ல. முக்கிய முடிவுகளை உங்கள் controls மற்றும் review-இடம் வைத்திருங்கள்.
Observation-ஐத் தவிர்ப்பது. Day one-ல் enforce செய்வது false positives-ஐ customer complaints மூலம் கண்டறியச் செய்கிறது. முதலில் observe செய்யுங்கள், பின்னர் evidence தெளிவாக இருக்கும் இடங்களில் enforce செய்யுங்கள்.

ஒவ்வொரு enforcement படியும் முன்னர் உங்கள் security, product மற்றும் support leads-உடன் ஒரு குறுகிய policy review செய்வது இவற்றில் பெரும்பாலானவற்றை முன்கூட்டியே கண்டறியும்.

Founding developer program-உடன் தொடங்குங்கள்

Proof of Actor private beta-வில் உள்ளது. தேர்ந்தெடுக்கப்பட்ட founding development teams, ஒப்புக்கொண்ட usage limits-உடன், முதல் policies-ஐ வடிவமைக்கும் போது எங்கள் engineers-இருந்து நேரடி support-உடன், 12 months வரை free access பெறலாம்.

உங்கள் application AI agents-ஐ எப்படி கையாள வேண்டும் என்பதை நீங்கள் தீர்மானித்து வருகிறீர்கள் என்றால், apply for early access. எந்த routes மிக முக்கியம், எந்த decisions-ஐ நீங்கள் எடுக்க விரும்புகிறீர்கள் என்பதைக் கூறுங்கள், அவற்றுக்குப் பொருந்தும் policies-ஐ உருவாக்க நாங்கள் உதவுவோம். இது 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.

உருவாக்குநர்களுக்காக

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: முடிவுக்குப் பின்னுள்ள signals, அதனால் உங்கள் team ஏன் என்பதைப் பார்க்க முடியும்.

observation mode-இல் தொடங்கவும்: முடிவுகளை உங்கள் logs-க்கு அடுத்ததாக பதிவு செய்யவும், நீங்கள் ஒரு policy-ஐத் தேர்வு செய்யும் வரை எதையும் மாற்றாதீர்கள். Node.js integration guide-ஐப் படிக்கவும்

அடிக்கடி கேட்கப்படும் கேள்விகள்

AI agent access policy என்றால் என்ன?

ஒரு request-ஐ உருவாக்கும் actor-ன் வகையின் அடிப்படையில் உங்கள் application பயன்படுத்தும் rule இது. உதாரணமாக, read-only routes-ல் verified agents-ஐ allow செய்வது அல்லது high-impact actions-க்கு stronger credential கேட்பது போன்றது. Proof of Actor actor result-ஐ வழங்குகிறது; உங்கள் policy response-ஐ தீர்மானிக்கிறது.

Proof of Actor policies-ஐ தானாக enforce செய்கிறதா?

இல்லை. ஒவ்வொரு integration-மும் observation mode-ல் தொடங்குகிறது, மேலும் உங்கள் team policy-களை route by route, அந்த workflow-க்கு அவை பொருத்தமானவை என்று நம்பும்போது மட்டுமே enable செய்கிறது.

Actor Unknown ஆக இருந்தால் அல்லது check timeout ஆனால் என்ன நடக்கும்?

ஒவ்வொரு route-க்கும் நீங்கள் explicit fallback-ஐ வரையறுக்கிறீர்கள். உதாரணமாக public reads-ஐ allow செய்து, account changes-க்கு existing checks-ஐ தொடரலாம். Unknown மற்றும் timeout-கள் ஒருபோதும் Human-ஆக default ஆகாது.

அனைத்து AI agents-ஐயும் block செய்ய வேண்டுமா?

பொதுவாக இல்லை. பல agents legitimate participants-ஆக உள்ளனர். Policies அவர்களுக்கு structured path கொடுக்க, முக்கியமான இடங்களில் அவர்களின் அணுகலை கட்டுப்படுத்த, மற்றும் sensitive actions-க்கு stronger checks-ஐ ஒதுக்க உதவுகின்றன.

Policies மக்கள் குறித்து முடிவுகள் எடுக்க முடியுமா?

வேலைவாய்ப்பு, கடன், அல்லது அத்தியாவசிய சேவைகளுக்கான அணுகல் போன்ற தனிநபர்களை பற்றிய முக்கிய முடிவுகளுக்கு Proof of Actor results மட்டும் அடிப்படையாக இருக்கக் கூடாது. அவற்றை routing மற்றும் context-க்கு, உங்கள் சொந்த controls-உடன் சேர்த்து பயன்படுத்துங்கள்.

உங்கள் app-ஐ யார் பயன்படுத்துகிறார்கள் என்பதை அறிந்துகொள்ளுங்கள்.

founding developers-இன் சிறிய குழுவுக்கான private beta.

முன்கூட்டிய அணுகலைப் பெறுக விலை விவரங்களை காண்க

முதலில் பேச விரும்புகிறீர்களா? founders-உடன் பேசுங்கள்