ಪ್ರಮುಖ ವಿಷಯಕ್ಕೆ ಬಿಟ್ಟುಬಿಡಿ
MCP ಕರೆಮಾಡುವವರ ಗುರುತింపు

ನಿಮ್ಮ MCP server ಗೆ ಯಾರು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ

ನಿಮ್ಮ MCP server ನೀವು ನಿಯಂತ್ರಿಸದ AI clients ಗೆ tools ಅನ್ನು ತೆರೆದಿಡುತ್ತದೆ. Proof of Actor ಪ್ರತಿ ಕರೆ ಹಿಂದೆ ಏನು ಇದೆ, ಯಾವ ಸಾಕ್ಷ್ಯ ಅದನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಮಗೆ ತಿಳಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ tool ಗೆ policies ಅನ್ನು ಹೊಂದಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ.

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

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

ನಿಮ್ಮ tools ನೀವು ನೋಡಲಾಗದ callers ಗೆ ತೆರೆದಿವೆ

ಒಂದು MCP server ನಿಮ್ಮ ಉತ್ಪನ್ನವನ್ನು AI clients ಗೆ ಬಳಸಬಹುದಾಗಿಸುತ್ತದೆ. ಇದು tools, resources ಮತ್ತು prompts ಅನ್ನು expose ಮಾಡುತ್ತದೆ, assistants ಮತ್ತು agents ಅವುಗಳನ್ನು discover ಮಾಡಿ call ಮಾಡಬಹುದು, ಮತ್ತು ಇದಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ hosts, clients ಮತ್ತು servers ನಡುವಿನ JSON-RPC 2.0 messages ಅನ್ನು Model Context Protocol specification ನಲ್ಲಿ ವಿವರಿಸಿರುವಂತೆ ಬಳಸುತ್ತದೆ. ತಂಡಗಳು ಅವುಗಳನ್ನು ನಿರ್ಮಿಸುವುದೇ ಈ ಕಾರಣಕ್ಕೆ: AI agents ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ workflows ಒಳಗೆ ನಿಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಇಡುವುದು.

ಅದೇ ಅರ್ಥವೆಂದರೆ ನಿಮ್ಮ server ನೀವು ನಿರ್ಮಿಸದ, ಮತ್ತು ನೇರವಾಗಿ observe ಮಾಡಲಾಗದ clients ನಿಂದ calls ಅನ್ನು ಪಡೆಯುತ್ತದೆ. ಒಂದೇ tool ಅನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಪರೀಕ್ಷಿಸುತ್ತಿರುವ developer, signed-in ವ್ಯಕ್ತಿಯ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ desktop assistant, ರಾತ್ರಿ ಪೂರ್ತಿ ದೀರ್ಘ task ಓಡಿಸುತ್ತಿರುವ autonomous agent, ಅಥವಾ ನಿಮ್ಮ server ನಲ್ಲಿ ದುರ್ಬಲತೆಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ಯಾವುದೋ process ಕರೆ ಮಾಡಬಹುದು. protocol ಯಾವ tool ಕರೆ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಯಾವ arguments ಜೊತೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಆದರೆ, ಅದು ಸ್ವತಃ, ಕರೆ ಹಿಂದೆ ಯಾವ ತರದ actor ಇದೆ ಅಥವಾ ನೀವು ಅದನ್ನು ಎಷ್ಟು ನಂಬಬೇಕು ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ.

MCP server caller identification ಆ ಅಂತರವನ್ನು ತುಂಬುತ್ತದೆ. Proof of Actor ಪ್ರತಿ tool call ಗೆ ಸಾಕ್ಷ್ಯಾಧಾರಿತ actor result ಸೇರಿಸುತ್ತದೆ, ಆಗ ನಿಮ್ಮ server ಯಾರು ಏನು ಪಡೆಯಬೇಕು ಎಂಬುದರ ಕುರಿತು informed decisions ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಸಮಸ್ಯೆಯನ್ನು ಆಳವಾಗಿ ನೋಡಲು, who is calling your MCP server ಅನ್ನು ಓದಿ, ಮತ್ತು ತಂಡಗಳು ಇದನ್ನು ಹೇಗೆ ಅನ್ವಯಿಸುತ್ತವೆ ಎಂಬುದಕ್ಕೆ MCP servers use case ನೋಡಿ.

ಪದಗಳ ಕುರಿತು ಒಂದು ಸೂಚನೆ. "Caller identity" ಗೆ cloud infrastructure ನಲ್ಲಿ well-known ಅರ್ಥವೂ ಇದೆ. ಉದಾಹರಣೆಗೆ, AWS STS GetCallerIdentity ಕಾರ್ಯಾಚರಣೆಯನ್ನು call ಮಾಡಲು ಬಳಸಿದ credentials ಹೊಂದಿರುವ IAM user ಅಥವಾ role ಕುರಿತು ವಿವರಗಳನ್ನು ನೀಡುತ್ತದೆ. ಅದು ಯಾವ cloud credential ಕರೆ ಮಾಡಿತು ಎಂಬುದಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ. ಈ ಪುಟದಲ್ಲಿನ MCP server caller identification ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ನಿಮ್ಮ MCP server ಗೆ ಇರುವ tool call ಹಿಂದೆ Human, Human + AI, Agent ಅಥವಾ Unknown ಯಾವ ತರದ actor ಇದೆ, ಮತ್ತು ಆ ಉತ್ತರವನ್ನು ಯಾವ ಸಾಕ್ಷ್ಯ ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬುದು.

MCP callers ಏಕೆ ವಿಭಿನ್ನವಾಗಿದ್ದಾರೆ

MCP callers policy ಗೆ ಮಹತ್ವವಾದ ರೀತಿಯಲ್ಲಿ browser visitors ಮತ್ತು ಪರಂಪರাগত API clients ಗಳಿಗಿಂತ ವಿಭಿನ್ನವಾಗಿದ್ದಾರೆ.

  • ಅವರು ಬಹುತೇಕ ಯಾವಾಗಲೂ automated ಆಗಿರುತ್ತಾರೆ. ಪ್ರಶ್ನೆ "ಮಾನವ ಅಥವಾ bot?" ಎಂಬುದಕ್ಕಿಂತ "ಯಾವ agent, ಯಾವ ರೀತಿಯಲ್ಲಿ, ಯಾವ ಸಾಕ್ಷ್ಯೊಂದಿಗೆ?" ಎಂಬುದಾಗಿದೆ.
  • ಅವರು ಹಲವಾರು ಬಾರಿ ವ್ಯಕ್ತಿಯ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ. assistant ನಿಮ್ಮ tool ಅನ್ನು user ಕೇಳಿದ ಕಾರಣದಿಂದ call ಮಾಡುತ್ತಿರಬಹುದು, ಅಥವಾ ಸ್ವತಂತ್ರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರಬಹುದು. ಆ ಸಂದರ್ಭಗಳು ಬೇರೆ ರೀತಿಯ treatment ಅನ್ನು deserve ಮಾಡುತ್ತವೆ.
  • ಅವರು ತಮ್ಮನ್ನು ತಾವೇ ವಿವರಿಸುತ್ತಾರೆ. MCP lifecycle specification ನಲ್ಲಿ client ತನ್ನ clientInfo object ಅನ್ನು name ಮತ್ತು version ಜೊತೆಗೆ ತನ್ನ initialize request ನಲ್ಲಿ send ಮಾಡುತ್ತದೆ. ಆ declaration ಉಪಯುಕ್ತ context, ಆದರೆ ಅದು proof ಅಲ್ಲ.
  • Tools ಗಳ impact ಅತಿ ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಒಂದು search tool ಮತ್ತು records ಅಳಿಸುವ tool ಒಂದೇ policy ಹಂಚಿಕೊಳ್ಳಬಾರದು.

ಉತ್ತಮ MCP caller identification ಇವು ನಾಲ್ಕನ್ನೂ ಗೌರವಿಸಬೇಕು.

Proof of Actor MCP callers ಅನ್ನು ಹೇಗೆ identify ಮಾಡುತ್ತದೆ

ನಿಮ್ಮ server ನಿಂದ signals

ನಿಮ್ಮ MCP integration ಪ್ರತಿ call ಗೆ ಲಭ್ಯವಿರುವ context ಅನ್ನು Proof of Actor ಗೆ pass ಮಾಡುತ್ತದೆ: client ನ declared details, transport ಮತ್ತು request context, client ನೀಡುವ ಯಾವುದಾದರೂ cryptographic request signatures, ಉದಾಹರಣೆಗೆ RFC 9421 ನಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಿರುವ HTTP Message Signatures, ಮತ್ತು call ಮಾಡಲಾಗುತ್ತಿರುವ tool. ಪ್ರತಿ signal ಅದನ್ನು ಎಲ್ಲಿಂದ ಬಂದಿತು ಎಂಬುದರೊಂದಿಗೆ labelled ಆಗಿರುತ್ತದೆ.

basis ಜೊತೆಗೆ classification

Proof of Actor ನಾಲ್ಕು classes ಗಳಲ್ಲಿ ಒಂದನ್ನು ನೀಡುತ್ತದೆ, Human, Human + AI, Agent ಅಥವಾ Unknown, ಜೊತೆಗೆ result ಗೆ ಇರುವ basis:

  • verified ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಪರಿಶೀಲನೆ, ಉದಾಹರಣೆಗೆ published key ವಿರುದ್ಧ request signature, pass ಆದಾಗ;
  • declared client ಅಥವಾ ನಿಮ್ಮ application ಅದನ್ನು ಹೇಳಿದಾಗ, ಉದಾಹರಣೆಗೆ session ನಲ್ಲಿ client name;
  • inferred result calls ನಲ್ಲಿನ patterns ಮೇಲೆ ಆಧಾರಿತವಾಗಿರುವಾಗ;
  • unknown evidence ನಿರ್ಧಾರವನ್ನು ಬೆಂಬಲಿಸದಾಗ.

declared client name ಅನ್ನು ಎಂದಿಗೂ verification ಎಂದು ತೋರಿಸಲಾಗುವುದಿಲ್ಲ. ಸಾಕ್ಷ್ಯ ತೆಳುವಾಗಿದ್ದರೆ, result Unknown ಆಗಿರುತ್ತದೆ, confident guess ಅಲ್ಲ, ಮತ್ತು ನಿಮ್ಮ server ನಿಖರವಾಗಿ ಅದು ಏನೊಂದಿಗೇ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ತಿಳಿದಿರುತ್ತದೆ.

ನಿಮ್ಮ tools ಬಳಸಬಹುದಾದ result

actor result tool call ಜೊತೆಗೆ ಬರುತ್ತದೆ, ನಿಮ್ಮ server ನ logic ಗೆ ಸಿದ್ಧವಾಗಿ. observation mode ನಲ್ಲಿ ನೀವು ಅದನ್ನು ದಾಖಲಿಸುತ್ತೀರಿ. ನೀವು ಸಿದ್ಧರಾದಾಗ, ನಿಮ್ಮ tool-level policies ಅದನ್ನು ಅನ್ವಯಿಸುತ್ತವೆ.

ನಿಮ್ಮ ತಂಡಕ್ಕೆ ಸಿಗುವುದು: Detect, Understand, Route

Detect

ಪ್ರತಿ tool call ನಲ್ಲಿ ಲಭ್ಯವಿರುವ caller evidence ಅನ್ನು capture ಮಾಡಿ ಮತ್ತು verified, declared ಮತ್ತು inferred evidence ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿರಿಸಿ.

Understand

ಯಾವ clients ಯಾವ tools ಗಳನ್ನು call ಮಾಡುತ್ತವೆ, ಎಷ್ಟು ಬಾರಿ, ಯಾವ ಸಾಕ್ಷ್ಯೊಂದಿಗೆ, ಮತ್ತು ಅದು ಸಮಯದೊಂದಿಗೆ ಹೇಗೆ ಬದಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ. ಬಹುಪಾಲು Unknown callers ಅನ್ನು ಆಕರ್ಷಿಸುವ tools, ವರ್ತನೆಯನ್ನು ಬದಲಿಸುವ clients, ಮತ್ತು verifiable identity ಹೊಂದಿರುವ calls ನ share ಅನ್ನು ಗುರುತಿಸಿ.

Route

ಪ್ರತಿ tool ಮತ್ತು risk tier ಗೆ policies ಬರೆಯಿರಿ. ಸಾಮಾನ್ಯ patterns:

  • Low-impact tools ಉದಾಹರಣೆಗೆ search ಅಥವಾ read-only lookups: ವ್ಯಾಪಕವಾಗಿ allow ಮಾಡಿ, standard rate limit ಜೊತೆಗೆ.
  • Moderate-impact tools ಉದಾಹರಣೆಗೆ drafts ರಚಿಸುವುದು: verified ಮತ್ತು declared callers ಅನ್ನು allow ಮಾಡಿ, Unknown ಅನ್ನು rate-limit ಮಾಡಿ.
  • High-impact tools ಉದಾಹರಣೆಗೆ data ಅಳಿಸುವುದು, settings ಬದಲಿಸುವುದು ಅಥವಾ user ನ ಪರವಾಗಿ messages send ಮಾಡುವುದು: ನಿಮ್ಮ strongest authorization ಅನ್ನು ಅಗತ್ಯವಿರಿಸಿ, ಮತ್ತು caller Unknown ಆಗಿರುವಾಗ ಅಥವಾ autonomously ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವಾಗ confirmation ಅಥವಾ review ಸೇರಿಸಿ.

sensitive actions without blocking agents ಗೆ ರಕ್ಷಣೆ ನೀಡುವುದು ಕುರಿತ guide ಈ tiers ಅನ್ನು ಹೇಗೆ design ಮಾಡುವುದು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

Identity evidence, credentials ಮತ್ತು authorization ಪ್ರತ್ಯೇಕವಾಗಿವೆ

MCP security ಉತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡುವುದು ಮೂರು ಪ್ರಶ್ನೆಗಳು ವಿಭಿನ್ನವಾಗಿರುವಾಗ:

  1. Identity evidence: ಯಾವ ತರದ client ಕರೆ ಮಾಡುತ್ತಿದೆ, ಮತ್ತು ಅದನ್ನು ಏನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ? Proof of Actor ಇದನ್ನು ಒದಗಿಸುತ್ತದೆ.
  2. Credentials: ಈ call ಯಾವ account ಅಥವಾ token ನಿಂದ ಮಾಡಲಾಗಿದೆ? ನಿಮ್ಮ MCP server ನ authentication ಇದನ್ನು ಒದಗಿಸುತ್ತದೆ. MCP authorization specification authorization ಅನ್ನು optional ಮಾಡುತ್ತದೆ ಮತ್ತು HTTP-based transports ಗಳಿಗೆ ಅದನ್ನು OAuth 2.1 ಮೇಲೆ ಆಧರಿಸುತ್ತದೆ, ಇಲ್ಲಿ MCP server resource server ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿ access tokens ಅನ್ನು validate ಮಾಡುತ್ತದೆ.
  3. Authorization: ಈ caller ಗೆ ಈ account ಗಾಗಿ, ಈ arguments ಜೊತೆಗೆ, ಈ tool ಬಳಸಲು ಅನುಮತಿ ಇದೆಯೇ? ನಿಮ್ಮ permission model ಇದನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಗುರುತಿಸಲ್ಪಟ್ಟ client ಸ್ವಯಂಚಾಲಿತವಾಗಿ authorized ಆಗಿರುವುದಿಲ್ಲ. ಮಾನ್ಯ signature ಈ session ಹಿಂದಿರುವ ವ್ಯಕ್ತಿ ಈ ನಿರ್ದಿಷ್ಟ action ಗೆ authority ಅನ್ನು delegated ಮಾಡಿದ್ದಾರೆ ಎಂದು ತೋರಿಸುವುದಿಲ್ಲ. delegated authority ಮತ್ತು agent authorization ಕುರಿತು ಇನ್ನಷ್ಟು ಓದಿ. Proof of Actor ನಿಮ್ಮ server ಗೆ ಮೊದಲ ಪ್ರಶ್ನೆಗೆ ಉತ್ತಮ context ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡನೆಯ ಮತ್ತು ಮೂರನೆಯ ಪ್ರಶ್ನೆಗಳ ಉತ್ತರಗಳು ಹೆಚ್ಚು informed ಆಗಿರುತ್ತವೆ.

client name ಅನ್ನು ಮಾತ್ರ ನಂಬಬಾರದೆಂದು ಏಕೆ?

ಯಾವ client ಕೂಡ ಯಾವುದೇ name ಅನ್ನು send ಮಾಡಬಹುದು. declared name ಅನ್ನು proof ಎಂದು ಪರಿಗಣಿಸುವುದು imitation ಗೆ ಆಹ್ವಾನ ನೀಡುತ್ತದೆ: hostile client ಗೆ ಜನಪ್ರಿಯ assistant ನ name ಅನ್ನು ನಕಲಿಸುವಷ್ಟೇ ಸಾಕು. Proof of Actor name ಅನ್ನು declared evidence ಆಗಿ ದಾಖಲಿಸುತ್ತದೆ, ಅದು ಹೊಂದಿರುವ ಯಾವುದೇ stronger evidence ಜೊತೆಗೆ ಅದನ್ನು combine ಮಾಡುತ್ತದೆ, ಮತ್ತು basis ಅನ್ನು ನಿಮಗೆ ಹೇಳುತ್ತದೆ. ನಂತರ ನಿಮ್ಮ policy verified callers ಗೆ declared ಮಾತ್ರ ಮಾಡಿರುವ callers ಗಿಂತ ಹೆಚ್ಚು ಸ್ವಾತಂತ್ರ್ಯ ನೀಡಬಹುದು, ಮತ್ತು ಯಾವುದೂ ಅನ್ವಯಿಸದಾಗ ನಿಮ್ಮ Unknown fallback ಅನ್ನು ಬಳಸಬಹುದು.

observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ

ನಿಮ್ಮ MCP server ನಲ್ಲಿ Proof of Actor ಅನ್ನು install ಮಾಡುವುದು ಯಾವುದೇ tool ಹೇಗೆ respond ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ. results ಅನ್ನು ದಾಖಲಿಸಲಾಗುತ್ತದೆ, ಆಗ ಯಾವವರು ನಿಮ್ಮ tools ಗೆ call ಮಾಡುತ್ತಾರೆ, ಸಾಕ್ಷ್ಯ ಎಷ್ಟು strong ಇದೆ, ಮತ್ತು ಯಾವ ಕಡೆ policies ಸಹಾಯ ಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು. ನೀವು ವಿಶ್ವಾಸ ಹೊಂದಿದಾಗ, ಒಂದು high-impact tool ಮೇಲೆ ಒಂದೇ policy ಅನ್ನು enable ಮಾಡಿ, outcomes ಅನ್ನು ಗಮನಿಸಿ, ನಂತರ ವಿಸ್ತರಿಸಿ. How It Works ಸಂಪೂರ್ಣ flow ಅನ್ನು ಒಳಗೊಂಡಿದೆ, ಮತ್ತು Detection & Limitations ಪ್ರತಿ ತರದ evidence ಏನು ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಏನು ಸ್ಥಾಪಿಸಲಾರದು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

MCP servers ಮತ್ತು APIs ನಡೆಸುವ teams ಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ

Proof of Actor ನಿಮ್ಮ existing authentication, rate limiting ಮತ್ತು logging ಜೊತೆಗೆ ನಿಮ್ಮ server ಒಳಗೆ ಇರುತ್ತದೆ. integrations ಅನ್ನು ಪ್ರತಿ founding team ಜೊತೆ hands-on ರೀತಿಯಲ್ಲಿ deliver ಮಾಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ setup ನಿಮ್ಮ transport, hosting ಮತ್ತು tool design ಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ. MCP Servers ಮತ್ತು APIs use cases ಒಂದೇ approach ನಿಮ್ಮ tools ಮತ್ತು ನಿಮ್ಮ API ನಲ್ಲಿ ಹೇಗೆ ಅನ್ವಯಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ.

ನೀವು expose ಮಾಡುವ ಪ್ರತಿಯೊಂದು tool ಬಗ್ಗೆ ಕೇಳಬೇಕಾದ ಪ್ರಶ್ನೆಗಳು

tool-level policies ಬರೆಯುವ ಮೊದಲು, ನಿಮ್ಮ MCP server expose ಮಾಡುವ ಪ್ರತಿಯೊಂದು tool ಅನ್ನು ಚಿಕ್ಕ checklist ಜೊತೆಗೆ ಪರಿಶೀಲಿಸುವುದು ಸಹಾಯಕವಾಗಿದೆ:

  • ಈ tool ಏನು ಬದಲಾಯಿಸಬಹುದು? read-only tools ಮತ್ತು data modify ಮಾಡುವ, messages send ಮಾಡುವ ಅಥವಾ billing ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ tools ಗೆ ಬೇರೆ treatment ಬೇಕು.
  • ಇದು ಯಾರಿಗಾಗಿ? ಕೆಲವು tools signed-in ವ್ಯಕ್ತಿಯ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ assistants ಗಾಗಿ ಇರುತ್ತವೆ; ಇನ್ನಾವು autonomous workflows ಗಾಗಿ. ನಿರೀಕ್ಷಿತ caller ಸರಿಯಾದ policy ಅನ್ನು ರೂಪಿಸುತ್ತದೆ.
  • ಒಂದು ತಪ್ಪಿನ ವೆಚ್ಚ ಎಷ್ಟು? ತಪ್ಪಾದ search result ಅಗ್ಗ. ತಪ್ಪಾದ deletion ಅಲ್ಲ. ಪ್ರತಿ tool ಅನ್ನು risk tier ಗೆ ಮ್ಯಾಪ್ ಮಾಡಿ.
  • ಯಾವ ಸಾಕ್ಷ್ಯವನ್ನು ಅಗತ್ಯವಿರಿಸಬೇಕು? declared client ಸಾಕೇ ಅಥವಾ tool ಗೆ verified identity ಜೊತೆಗೆ ನಿಮ್ಮ strongest authorization ಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ.
  • Unknown ಬಂದಾಗ ಏನಾಗುತ್ತದೆ? ಪ್ರತಿ tool ಗೆ ಸ್ಪಷ್ಟ fallback ಆಯ್ಕೆ ಮಾಡಿ: allow, rate-limit, user ಗೆ confirm ಮಾಡಲು ಕೇಳಿ, ಅಥವಾ review ಗೆ route ಮಾಡಿ.
  • ಇದು ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ನೀವು ಹೇಗೆ ತಿಳಿಯುತ್ತೀರಿ? ನೀವು ಏನನ್ನಾದರೂ enforce ಮಾಡುವ ಮುನ್ನ observation mode ನಲ್ಲಿ ಯಾವ outcomes ಗಳನ್ನು ಗಮನಿಸುವಿರಿ ಎಂದು ನಿರ್ಧರಿಸಿ.

ಪ್ರತಿ tool ಗೆ ಒಂದೇ ಬಾರಿ ಇವುಗಳಿಗೆ ಉತ್ತರಿಸುವುದು caller identification ಅನ್ನು ಸ್ಪಷ್ಟ, ಪರೀಕ್ಷಿಸಬಹುದಾದ rules ಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಮತ್ತು ಅದು integrate ಮಾಡುವ clients ಗೆ ನಿಮ್ಮ server ನ behavior ಅನ್ನು ವಿವರಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

founding developer program ಗೆ ಸೇರಿ

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

ನೀವು ಒಂದು MCP server ನಡೆಸುತ್ತಿದ್ದು ಅದು ಯಾರು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ತಿಳಿಯಲು ಬಯಸಿದರೆ, apply for early access. ನಿಮ್ಮ server, ನೀವು expose ಮಾಡುವ tools ಮತ್ತು ನಿಮಗೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ calls ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿಸಿ.

sources

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 ಏಕೀಕರಣ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಓದಿ

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

MCP server ಗೆ caller identification ಏಕೆ ಬೇಕು?

MCP servers ಜನರ ಪರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಅಥವಾ ಸ್ವತಂತ್ರವಾಗಿ ನಡೆಯುವ AI clients ಗೆ tools ಅನ್ನು expose ಮಾಡುತ್ತವೆ. tool call ಹಿಂದೆ ಯಾವ ತರದ caller ಇದೆ ಎಂಬುದನ್ನು ತಿಳಿದರೆ, ಕಡಿಮೆ ಪರಿಣಾಮದ tools ಅನ್ನು ಮುಕ್ತವಾಗಿ ಅನುಮತಿಸಬಹುದು ಮತ್ತು ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ tools ಗೆ ಹೆಚ್ಚುವರಿ ನಿಯಂತ್ರಣಗಳನ್ನು ಕೇಳಬಹುದು.

MCP session ನಲ್ಲಿ client name ಒಂದು verification ಆಗಿದೆಯೇ?

ಇಲ್ಲ. client name ಎಂದರೆ client ಮಾಡುವ declaration. Proof of Actor ಅದನ್ನು declared evidence ಆಗಿ ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು cryptographically verified identity ಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡುತ್ತದೆ.

Caller identification MCP authorization ಅನ್ನು ಬದಲಿಸುತ್ತದೆಯೇ?

ಇಲ್ಲ. caller identity evidence, ಬಳಸಿದ credential, ಮತ್ತು caller ಗೆ ಏನು ಮಾಡಲು ಅನುಮತಿ ಇದೆ ಎಂಬುದು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು. Proof of Actor ಮೊದಲನೆಯದಕ್ಕೆ context ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು authorization ಅನ್ನು ನಿಮ್ಮ server ಗೆ ಬಿಡುತ್ತದೆ.

Proof of Actor tool calls ಅನ್ನು block ಮಾಡುತ್ತದೆಯೇ?

ನಿಮ್ಮ policies ಹಾಗೆ ಹೇಳಿದರೆ ಮಾತ್ರ. ಪ್ರತಿ integration observation mode ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಮತ್ತು ನೀವು ಸಿದ್ಧರಾದಾಗ tool-level policies ಅನ್ನು enable ಮಾಡುತ್ತೀರಿ.

ನಾನು ಇದನ್ನು ಹೇಗೆ ಪ್ರಯತ್ನಿಸಬಹುದು?

early access ಗೆ apply ಮಾಡಿ. ಆಯ್ಕೆಯಾದ founding developer teams ಗೆ ಒಪ್ಪಂದಿತ usage limits ಒಳಗೆ 12 months ವರೆಗೆ ಉಚಿತ access, ಮತ್ತು hands-on integration support ಲಭ್ಯವಿರಬಹುದು.

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

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

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

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