ಪ್ರಮುಖ ವಿಷಯಕ್ಕೆ ಬಿಟ್ಟುಬಿಡಿ
ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

Proof of Actor ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಬರುವ interaction ನಿಂದ application ನಿರ್ಧಾರದವರೆಗೆ evidence-first path.

Early Access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿDetection ಮತ್ತು Limits ವೀಕ್ಷಿಸಿ
policy · example-app.test
  • /api/v1/catalogenforceಏಜೆಂಟ್ಅನುಮತಿಸಿ · structured API
  • /support/ticketsenforceಮಾನವ + AIಅನುಮತಿಸಿ · AI-assisted ಎಂದು label ಮಾಡಿ
  • /account/*previewಅಜ್ಞಾತಅಸ್ತಿತ್ವದಲ್ಲಿರುವ checks ಅನ್ನು ಹಾಗೆಯೇ ಇಡಿ
  • /api/v1/orderspreviewಏಜೆಂಟ್ಇನ್ನಷ್ಟು ಬಲವಾದ credential ಅನ್ನು ಅಗತ್ಯಪಡಿಸಿ

interaction ನಿಂದ decision ವರೆಗೆ

  1. 01Application request ಅಥವಾ eventಒಂದು ಪುಟ ವೀಕ್ಷಣೆ, ಒಂದು API ಕರೆ, ಒಂದು MCP ಉಪಕರಣ ಕರೆ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಒಳಗಿನ ಕ್ರಿಯೆ.
  2. 02ಬೆಂಬಲಿತ ಏಕೀಕರಣದಿಂದ ಸಂಕೇತಗಳುಆ contextನಲ್ಲಿ ಆ integration ಗಮನಿಸಬಲ್ಲದ್ದನ್ನು ಮಾತ್ರ.
  3. 03Evidence normalization ಮತ್ತು classificationಸಂಕೇತಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಆಧಾರದ ಪ್ರಕಾರ ಲೇಬಲ್ ಮಾಡಿ, ನಂತರ ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ.
  4. 04ಆಧಾರ ಮತ್ತು ಅನಿಶ್ಚಿತತೆಯೊಂದಿಗೆ Actor ಫಲಿತಾಂಶಮಾನವ, Human + AI, Agent ಅಥವಾ Unknown, ಜೊತೆಗೆ ಅದು ಆಧರಿಸಿರುವುದೇನು.
  5. 05dashboard ಮತ್ತು analyticsನಿಮ್ಮ team ಪರಿಶೀಲಿಸಲು trends, routes ಮತ್ತು evidence.
  6. 06ನಿಮ್ಮ application ನ ಸ್ವಂತ ನಿರ್ಧಾರಕೇವಲ ವೀಕ್ಷಿಸಿ, ಅಥವಾ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ policy ಅನ್ನು ಅನ್ವಯಿಸಿ.
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 ಏಕೀಕರಣ ಮಾರ್ಗದರ್ಶಿಯನ್ನು ಓದಿ

Observation mode default ಆಗಿದೆ

Proof of Actor ಅನ್ನು install ಮಾಡುವುದರಿಂದ ಯಾವುದೇ request ಅನ್ನು block ಮಾಡುವುದಿಲ್ಲ ಅಥವಾ ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಫಲಿತಾಂಶಗಳನ್ನು ದಾಖಲಿಸಲಾಗುತ್ತದೆ, যাতে ನಿಮ್ಮ team ಅವನ್ನು ನಿಜವಾದ application outcomes ಜೊತೆ ಹೋಲಿಸಿ, false positives ಅನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಯಾವುದೇ policy ಸೂಕ್ತವೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬಹುದು.

ಸಾಕ್ಷ್ಯದ ಪ್ರಕಾರಗಳು

ಲಭ್ಯವಿರುವ ಸಾಕ್ಷ್ಯವು integration ಮತ್ತು context ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಪ್ರತಿ workflow ಗಾಗಿ checks ಅನ್ನು onboarding ವೇಳೆ ತಂಡದೊಂದಿಗೆ ಒಪ್ಪಿಕೊಳ್ಳಲಾಗುತ್ತದೆ, ಮತ್ತು signal internals ಖಾಸಗಿಯಾಗಿ ಉಳಿಯುವುದರಿಂದ ಅವನ್ನು ಅನುಕರಿಸುವುದು ಹೆಚ್ಚು ಕಷ್ಟವಾಗುತ್ತದೆ.

  • ವಿನಂತಿ ಸಹಿಗಳು

    ತಮ್ಮ keys ಗಳನ್ನು ಪ್ರಕಟಿಸುವ ಸ್ವಯಂಚಾಲಿತ clients ಗಳಿಂದ cryptographic signatures.

  • ಘೋಷಣೆಗಳು

    ತನ್ನನ್ನು Agent ಎಂದು ಹೆಸರಿಸುವ ಕ್ಲೈಂಟ್, ಅಥವಾ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನೊಳಗಿನ AI ಸಹಾಯ ಬಹಿರಂಗಪಡಿಕೆ.

  • ಅಂತರಕ್ರಿಯಾ ಸಂಕೇತಗಳು

    ಅನುಮೋದಿತ ಬ್ರೌಸರ್ ಸಂಗ್ರಹಕದಿಂದ ಸಂಕೇತಗಳು, ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಪುಟಗಳಲ್ಲಿ.

  • ವಿನಂತಿ ಸಂದರ್ಭ

    server-side integration ಗೆ ಲಭ್ಯವಿರುವ headers ಮತ್ತು protocol ವಿವರಗಳು.

Agent identity authorization ಅಲ್ಲ

ಸ್ವಯಂಚಾಲಿತ ಕ್ಲೈಂಟ್‌ನಿಂದ ಬಂದ ಸಹಿಯಾದ ವಿನಂತಿಯು, ಆ ವಿನಂತಿ ಪ್ರಕಟಿತ ಗುರುತಿನೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಕೀಲಿಯಿಂದ, ಉದಾಹರಣೆಗೆ ಆಪರೇಟರ್‌ನ ಡೊಮೇನ್‌ನೊಂದಿಗೆ, ಸಹಿಯಾಗಿತ್ತು ಎಂಬುದನ್ನು ತೋರಿಸಬಹುದು. ಅದು ಯಾವ ಕ್ಲೈಂಟ್ ಅದನ್ನು ಕಳುಹಿಸಿತು ಎಂಬುದರ ಕುರಿತು ಉಪಯುಕ್ತ ಸಾಕ್ಷ್ಯವಾಗಿದೆ.

ಇದು agentಗೆ ಯಾರು ಸೂಚನೆ ನೀಡಿದರು, ಒಬ್ಬ ವ್ಯಕ್ತಿ ಅದಕ್ಕೆ ಅನುಮತಿಯನ್ನು ಹಂಚಿದ್ದಾರೆಯೇ, ಅದರ ಹಿಂದೆ ಇರುವ ಕಾನೂನು ಗುರುತು ಏನು, ಅಥವಾ ಆ ಕ್ರಿಯೆ ಸುರಕ್ಷಿತವೇ ಎಂಬುದನ್ನು ತೋರಿಸುವುದಿಲ್ಲ. ಅವು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು, ಮತ್ತು ನಿಮ್ಮ application ತನ್ನದೇ authentication, authorization ಮತ್ತು policy ಮೂಲಕ ಅವಕ್ಕೆ ಉತ್ತರಿಸುತ್ತದೆ.

ಮೂರು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು
  • ಯಾರು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ?Proof of Actor: signature, declaration ಅಥವಾ inference
  • ಯಾವ credential?ನಿಮ್ಮ API key, OAuth token ಅಥವಾ session
  • ಇದು ಏನು ಮಾಡಬಹುದು?ನಿಮ್ಮ authorization ಮತ್ತು policy

routing ನಿರ್ಧಾರಗಳು ಹೇಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ

ನಿಮ್ಮ application Proof of Actor ಅನ್ನು ಕರೆದು, ಫಲಿತಾಂಶವನ್ನು ಪಡೆದು, ತನ್ನದೇ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ನೀವು ಪ್ರತಿ route ಮತ್ತು risk tier ಗೆ integration fail open ಆಗಬೇಕೇ (request Proof of Actor ಇಲ್ಲದಂತೆ ಮುಂದುವರಿಯುತ್ತದೆ) ಅಥವಾ fail closed ಆಗಬೇಕೇ (ನಿಮ್ಮ ಈಗಿನ ಬಲವಾದ check ಅನ್ವಯಿಸುತ್ತದೆ) ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೀರಿ.

  • API ಸಮಯ ಮೀರಿಕೆ

    ಫಲಿತಾಂಶವು ಸಮಯಕ್ಕೆ ಲಭ್ಯವಾಗದಿದ್ದರೆ, ನಿಮ್ಮ integration ಆ ಮಾರ್ಗಕ್ಕಾಗಿ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ fallback ಅನ್ನು ಬಳಸುತ್ತದೆ. timeout ಎಂದಿಗೂ Human ಫಲಿತಾಂಶವಾಗುವುದಿಲ್ಲ.

  • ಕಾಣೆಯಾದ telemetry

    browser collector ಕಾರ್ಯನಿರ್ವಹಿಸದಿದ್ದರೆ ಅಥವಾ ಯಾವುದಾದರೂ signal ಇಲ್ಲದಿದ್ದರೆ, ಫಲಿತಾಂಶ ಅದನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಕಾಣೆಯಾದ ಸಾಕ್ಷ್ಯವು ಹೇಳಬಹುದಾದುದನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ; ಅದನ್ನು ಅನುಮಾನಾಸ್ಪದವಾಗಿ ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ.

  • Unknown ವರ್ಗೀಕರಣಗಳು

    Unknown ಒಂದು ಸಾಮಾನ್ಯ outcome ಆಗಿದೆ. ನಿಮ್ಮ policy ಪ್ರತಿಯೊಂದು route ಗೆ Unknown ಏನು ಅರ್ಥವೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ: public pages ಅನ್ನು allow ಮಾಡಿ, account changes ಮೇಲೆ existing checks ಅನ್ನು ಉಳಿಸಿ.

  • ಹಳೆಯದಾದ ಸಾಕ್ಷ್ಯ

    Evidence ಗೆ ಒಂದು time ಮತ್ತು ಒಂದು scope ಇರುತ್ತದೆ. session ನ ಮೊದಲಿನ result ಅನ್ನು ನಂತರದ, ಹೆಚ್ಚು sensitive action ಗೆ ಹೊಸ ಪರಿಶೀಲನೆ ಇಲ್ಲದೆ ಮರುಬಳಸಬಾರದು.

ಬೇಟಾ integration workflow

  1. 01ಅನ್ವಯಿಸಿapp ಮತ್ತು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸುವ interaction ಬಗ್ಗೆ ನಮಗೆ ತಿಳಿಸಿ.
  2. 02ವ್ಯಾಪ್ತಿintegration, routes, usage limits ಮತ್ತು data handling ಬಗ್ಗೆ ಒಪ್ಪಿಕೊಳ್ಳಿ.
  3. 03ಅವಲೋಕನ ಮೋಡ್‌ನಲ್ಲಿ ಒಗ್ಗೂಡಿಸಿನಿಮ್ಮ app ಪ್ರತಿಕ್ರಿಯಿಸುವ ರೀತಿಯಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಇಲ್ಲ.
  4. 04ಮಾನ್ಯಗೊಳಿಸಿನೀವು ತಿಳಿದಿರುವ ground truth ಜೊತೆ ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಸಿ: coverage, unknown rate, false positives, latency.
  5. 05ನಿರ್ಧರಿಸಿEvidence ಬೆಂಬಲಿಸುವ ಕಡೆ ಮಾತ್ರ policy ಅನ್ನು enable ಮಾಡಿ.

Founding ತಂಡಗಳೊಂದಿಗೆ ನಾವು ಅಳೆಯುವುದು

ಪ್ರತಿ ಬೆಂಬಲಿತ context ನಲ್ಲಿ coverage, unknown rate, known outcomes ವಿರುದ್ಧ false positives, ಮತ್ತು ಹೆಚ್ಚುವರಿ latency.

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

founding developer program ಗೆ ಸೇರಲು ಅರ್ಜಿ ಸಲ್ಲಿಸಿ.

Early Access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿDetection ಮತ್ತು Limits ವೀಕ್ಷಿಸಿ

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