ಪ್ರಮುಖ ವಿಷಯಕ್ಕೆ ಬಿಟ್ಟುಬಿಡಿ
DETECTION & LIMITATIONS

Proof of Actor ಏನು ಸ್ಥಾಪಿಸಬಹುದು, ಮತ್ತು ಏನು ಸಾಧ್ಯವಿಲ್ಲ.

ವರ್ಗೀಕರಣಗಳು, ಅವುಗಳ ಹಿಂದೆ ಇರುವ evidence, ಅವು ಅನ್ವಯಿಸುವ ಸಂದರ್ಭಗಳು, ಮತ್ತು ನಾವು ವಿನ್ಯಾಸಗೊಳಿಸುವ ಮಿತಿಗಳ ಸರಳ ವಿವರಣೆ.

ಸಂಕೇತಗಳು · ಪ್ರತಿ ಮೂಲದ ಕೊನೆಯ ವಿನಂತಿ
  • ವಿನಂತಿ ಸಹಿvalid · sample-crawler.exampleverified
  • client ಘೋಷಣೆ"research-assistant/2.1"declared
  • browser ಸಂವಹನpointer + keyboard eventsinferred
  • ಬೆಂಬಲಿತ signals ಇಲ್ಲroute not instrumentedunknown

ಸಂಕ್ಷಿಪ್ತ ಆವೃತ್ತಿ

Proof of Actor ನಿಮಗೆ ಏನು ಹೇಳಬಲ್ಲದು ಮತ್ತು ಏನು ಖಚಿತಪಡಿಸಲಾರದು
Proof of Actor ನಿಮಗೆ ಏನು ಹೇಳಬಲ್ಲದು (ಸಹಾಯಕವಾಗಿದ್ದರೆ)ಇದು ಏನು ಖಚಿತಪಡಿಸಲಾರದು
ಬೆಂಬಲಿತ agent request signature ಮಾನ್ಯವಾಗುತ್ತದೆಯೇಏಜೆಂಟ್ ನಿಷ್ಠವಾಗಿದ್ದು, ಸುರಕ್ಷಿತವಾಗಿದ್ದು, ಅಥವಾ ಯಾವುದೇ ಕ್ರಿಯೆ ಮಾಡಲು ಅನುಮತಿ ಹೊಂದಿದೆ ಎಂಬುದು
ಒಂದು session ಕೆಲವು interaction ಅಥವಾ automation ಸಂಕೇತಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆಯೇಮಾನವರು ನಿಮ್ಮ ಗಮನಿಸಬಹುದಾದ ಏಕೀಕರಣದ ಹೊರಗೆ ಯಾವುದೇ AI ಬಳಸಲಿಲ್ಲ ಎಂಬುದು
AI ಬಳಕೆ ಘೋಷಿಸಲ್ಪಟ್ಟಿತೇ ಅಥವಾ ಬೆಂಬಲಿತ workflow ನಲ್ಲಿ ಗಮನಿಸಬಹುದಾಗಿತೇAI ನೆರವು, ನಕಲಿಸಿದ ವಿಷಯ, ಅಥವಾ ಮತ್ತೊಂದು device ನ universal detection
ಆ ಸಾಕ್ಷ್ಯ ಅಸಮರ್ಪಕವಾಗಿತ್ತು ಎಂಬುದುಅಜ್ಞಾತ interaction ದುರುದ್ದೇಶಪೂರ್ಣವಾಗಿದೆ ಎಂಬುದು

ಲಭ್ಯತೆ ನಿಮ್ಮ ಏಕೀಕರಣ ಮತ್ತು ಸಕ್ರಿಯಗೊಳಿಸಿದ ಪರಿಶೀಲನೆಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಜಾರಿಗೆ ಸಂಬಂಧಿಸಿದ ನಿರ್ಧಾರಗಳ ನಿಯಂತ್ರಣವು ಅಪ್ಲಿಕೇಶನ್ ಮಾಲೀಕರಲ್ಲೇ ಇರುತ್ತದೆ.

ವರ್ಗೀಕರಣಗಳು

ನಾಲ್ಕು public class ಗಳು. ಪ್ರತಿಯೊಂದಕ್ಕೂ ನಿರ್ದಿಷ್ಟ ಅರ್ಥ ಮತ್ತು ಸ್ಪಷ್ಟ ಮಿತಿ ಇದೆ.

  • ಮಾನವ

    ಬೆಂಬಲಿತವಾಗಿ ಕಾಣಿಸಬಹುದಾದ ಸಂಕೇತಗಳು ಮಾನವ-ನಿರ್ದೇಶಿತ ಸಂವಹನವನ್ನು ಸೂಚಿಸುತ್ತವೆ.

    ಅರ್ಥವಲ್ಲ: ಯಾವುದೇ AI ಬಳಸಲಾಗಿಲ್ಲ, ಅಥವಾ ವ್ಯಕ್ತಿಯ ನೈಜ-ಜಗತ್ತಿನ ಗುರುತನ್ನು ಪರಿಶೀಲಿಸಲಾಗಿದೆ ಎಂಬುದು.

  • ಮಾನವ + AI

    AI ಸಹಾಯವನ್ನು ಘೋಷಿಸಲಾಗಿತ್ತು, ಅಥವಾ ಅದನ್ನು ನಿಜವಾಗಿಯೂ ಗಮನಿಸಬಲ್ಲ ಬೆಂಬಲಿತ ಏಕೀಕರಣದಿಂದ ಪತ್ತೆ ಮಾಡಲಾಗಿದೆ.

    ಅರ್ಥವಲ್ಲ: ಮರೆಮಾಡಿದ ಎಲ್ಲಾ AI ಬಳಕೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಬಹುದು ಎಂಬುದು, ಇನ್ನೊಂದು tab ಅಥವಾ ಇನ್ನೊಂದು device ಸಹ ಸೇರಿ.

  • ಏಜೆಂಟ್

    verify ಮಾಡಬಹುದಾದ identity ಅಥವಾ ಎಚ್ಚರಿಕೆಯಿಂದ ಅರ್ಹಗೊಳಿಸಿದ inference ನಿಂದ ಬೆಂಬಲಿತ automated ಅಥವಾ agent-origin interaction.

    ಅರ್ಥವಲ್ಲ: ಏಜೆಂಟ್‌ಗೆ ಅಧಿಕಾರ ಇದೆ, ಅದು ಸುರಕ್ಷಿತವಾಗಿದೆ, ಅಥವಾ ವ್ಯಕ್ತಿಯಿಂದ ಮಾನ್ಯ ನಿಯೋಜನೆಯೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂಬುದು.

  • ಅಜ್ಞಾತ

    ಲಭ್ಯವಿರುವ ಸಾಕ್ಷ್ಯವು ನಂಬಲರ್ಹ ನಿರ್ಧಾರವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.

    ಅರ್ಥವಲ್ಲ: ಆ interaction ಸಂಶಯಾಸ್ಪದ ಅಥವಾ ದುರುದ್ದೇಶಪೂರ್ಣವಾಗಿದೆ ಎಂಬುದು.

Verified, Declared, Inferred, Unknown

ಪ್ರತಿ result ಒಂದು basis ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಒಂದು class ಎಂದಿಗೂ inference ಅನ್ನು cryptographic verification ಎಂದು ಮುಚ್ಚಿಡುವುದಿಲ್ಲ, ಇದು security-sensitive applications ಗೆ ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿದೆ.

verified
ಪರಿಶೀಲಿತ. ಉದಾಹರಣೆಗೆ ಪ್ರಕಟಿತ ಕೀಲಿಯ ವಿರುದ್ಧ ವಿನಂತಿ ಸಹಿಯನ್ನು ಪರಿಶೀಲಿಸುವಂತೆ, ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಅಥವಾ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ಘೋಷಣೆ ಮಾನ್ಯಗೊಂಡಿದೆ. ಅದು ಆ ಪರಿಶೀಲನೆಯನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಏನನ್ನೂ ಅಲ್ಲ.
declared
ಘೋಷಿತ. actor ಅಥವಾ ನಿಮ್ಮ application ಅದನ್ನು ಹೇಳಿದೆ, ಉದಾಹರಣೆಗೆ AI-assistance disclosure ಅಥವಾ ತಾನು ಏಜೆಂಟ್ ಎಂದು ಹೆಸರಿಸಿಕೊಳ್ಳುವ client. ಒಂದು ಘೋಷಣೆ ಸುಳ್ಳಾಗಿರಬಹುದು.
inferred
ಅನೂಹಿತ. ವರ್ತನಾ ಅಥವಾ ಸಂದರ್ಭಾತ್ಮಕ ಸಂಕೇತಗಳಿಂದ ತೆಗೆದುಕೊಳ್ಳುವ ತೀರ್ಮಾನ. Inferredಗಳು ತಪ್ಪಿರಬಹುದು ಮತ್ತು ಸದಾ Inferredಗಳೆಂದು ಲೇಬಲ್ ಮಾಡಲಾಗುತ್ತದೆ.
unknown
ಅಜ್ಞಾತ. ನಿರ್ಣಯಕ್ಕೆ ಸಾಕಷ್ಟು evidence ಇಲ್ಲ. ಫಲಿತಾಂಶವನ್ನು ಊಹಿಸುವ ಬದಲು Unknown ಎಂದು ವರದಿಮಾಡಲಾಗುತ್ತದೆ.

ಒಂದು confidence figure ಗೆ ಹಿಂದೆ ಪರೀಕ್ಷಿತ, ಕ್ಯಾಲಿಬ್ರೇಟ್ ಮಾಡಿದ model ಅಗತ್ಯವಿದ್ದರೆ, ನಾವು ಅದರ ಬದಲು ಗುಣಾತ್ಮಕ evidence ಬಲವನ್ನು ಬಳಸುತ್ತೇವೆ. ಅಳೆಯಲಾಗಿದ್ದು ಮತ್ತು ವಿವರಿಸಲ್ಪಟ್ಟಿಲ್ಲದಿದ್ದರೆ, ನೀವು ನಮ್ಮಿಂದ 99.7% human ಎಂಬಂತೆ ಯಾವುದೇ ಅಂಕೆಯನ್ನು ಕಾಣುವುದಿಲ್ಲ.

ಬೆಂಬಲಿತ contexts ಮತ್ತು ಅವುಗಳ ಮಿತಿಗಳು

  • browser

    ಬ್ರೌಸರ್ ಸಂಗ್ರಹಕವು ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಪುಟಗಳಲ್ಲಿನ ಸಂವಹನಾತ್ಮಕ ಸೆಷನ್‌ಗಳನ್ನು ನೋಡುತ್ತದೆ. JavaScript ಚಾಲನೆ ಮಾಡದ ಕ್ಲೈಂಟ್‌ಗಳು, ಇತರ ಟ್ಯಾಬ್‌ಗಳು, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅಥವಾ ಸಾಧನಗಳಲ್ಲಿನ ಚಟುವಟಿಕೆ, ಅಥವಾ ವ್ಯಕ್ತಿ ಬೇರೆಡೆದಿಂದ ನಕಲಿಸಿ ತಂದ ಪಠ್ಯವನ್ನು ಅದು ನೋಡಲಾಗದು.

  • ಸರ್ವರ್ ಮತ್ತು API

    ಸರ್ವರ್-ಸೈಡ್ ಏಕೀಕರಣವು ವಿನಂತಿ ಸಂದರ್ಭವನ್ನು ಮತ್ತು, ಕ್ಲೈಂಟ್‌ಗಳು ಬೆಂಬಲಿಸುವಲ್ಲಿ, ವಿನಂತಿ ಸಹಿಗಳನ್ನು ನೋಡುತ್ತದೆ. ಅದು ವ್ಯಕ್ತಿಯ ಪರದೆಯನ್ನು ನೋಡಲಾಗದು, ಮತ್ತು ಹೆಚ್ಚಿನ ಸಹಿಯಿಲ್ಲದ ಕ್ಲೈಂಟ್‌ಗಳು ತಮ್ಮನ್ನು ತಾವು ಇಷ್ಟವಾದಂತೆ ವಿವರಿಸಬಹುದು.

  • MCP

    MCP server client ನ declared ವಿವರಗಳು ಮತ್ತು ಅದು ಮಾಡುವ tool calls ಗಳನ್ನು ನೋಡುತ್ತದೆ. declared client ಹೆಸರು ಒಂದು declaration, verification ಅಲ್ಲ.

ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ ಎರಡು ಮಿತಿಗಳು

ಮತ್ತೊಂದು tab ಅಥವಾ device ನಿಂದ ಬಂದ AI-generated ಪಠ್ಯ

ಒಬ್ಬ ವ್ಯಕ್ತಿ ಮತ್ತೊಂದು tab ನಲ್ಲಿ ಅಥವಾ ತಮ್ಮ phone ನಲ್ಲಿ chatbot ಅನ್ನು ಕೇಳಿ, ಉತ್ತರವನ್ನು ನಿಮ್ಮ form ಗೆ ಅಂಟಿಸಿದರೆ, ಸಾಮಾನ್ಯ web traffic ಅದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಏನೂ ತೋರಿಸುವುದಿಲ್ಲ. ಮಾನವ ಅದನ್ನು ನಿರ್ದೇಶಿಸಿದ್ದರಿಂದ session ಮಾನವ ನಿರ್ದೇಶಿತವಾಗಿರುವಂತೆ ಕಾಣುತ್ತದೆ.

ಸಹಾಯವನ್ನು declared ಮಾಡಿದ್ದಾಗ ಮಾತ್ರ, ಅಥವಾ ಅದನ್ನು ನಿಜವಾಗಿಯೂ ನೋಡಬಲ್ಲ supported ಏಕೀಕರಣದಿಂದ ಗಮನಿಸಿದಾಗ ಮಾತ್ರ Proof of Actor Human + AI ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ನಿಮ್ಮ app ನ ಸ್ವಂತ ಸಹಾಯಕ ವೈಶಿಷ್ಟ್ಯ.

signed bot request ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ

ಪ್ರಕಟಿತ key ವಿರುದ್ಧ validate ಆಗುವ HTTP message signature, ಆ request ಅನ್ನು ಆ identifier ಗೆ ಸಂಬಂಧಿಸಿದ key ಯೊಂದಿಗೆ signed ಮಾಡಲಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ operator ನ domain.

ಇದು ವಿನಂತಿಯ ಹಿಂದೆ ಇರುವ ವ್ಯಕ್ತಿಯ ನಿಜಜಗತ್ತಿನ ಗುರುತನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಅಥವಾ ಒಬ್ಬ ವ್ಯಕ್ತಿ ಅದಕ್ಕೆ ಅಧಿಕಾರವನ್ನು ಹಂಚಿದ್ದಾರೆಯೇ, ಅಥವಾ ಆ ಕ್ರಿಯೆ ಸುರಕ್ಷಿತವಾಗಿದೆಯೇ ಅಥವಾ ಅನುಮತಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಎಂಬುದನ್ನೂ ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ. ಈ ಕ್ಷೇತ್ರದ ಮಾನದಂಡಗಳು, IETF Web Bot Auth ಕೆಲಸವನ್ನು ಒಳಗೊಂಡಂತೆ, ಇನ್ನೂ Internet-Drafts ಆಗಿವೆ.

default blocking ಇಲ್ಲ

Proof of Actor ಡಿಫಾಲ್ಟ್ ಆಗಿ ಯಾವುದನ್ನೂ block, reject ಅಥವಾ challenge ಮಾಡುವುದಿಲ್ಲ. ಕೇವಲ inferred actor ಫಲಿತಾಂಶದ ಆಧಾರದಲ್ಲಿ block ಅಥವಾ reject ಮಾಡುವುದನ್ನು ನಾವು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ, ವಿಶೇಷವಾಗಿ ಉದ್ಯೋಗ, ಕ್ರೆಡಿಟ್, ಹಣಕಾಸು ಸೇವೆಗಳು, ಶಿಕ್ಷಣ ಅಥವಾ ಅಗತ್ಯ ಸೇವೆಗಳ ಪ್ರವೇಶದಂತಹ ಜನರ ಮೇಲಿನ ಮಹತ್ವದ ನಿರ್ಧಾರಗಳನ್ನು ಅದರ ಆಧಾರದಲ್ಲಿ ತೆಗೆದುಕೊಳ್ಳಬಾರದು.

Enforcement ನಿಮ್ಮ application ಒಳಗೆ ನಡೆಯುತ್ತದೆ, ನಿಮ್ಮ team ಆಯ್ಕೆಮಾಡಿ ದೃಢೀಕರಿಸಿದ policies ಅಡಿಯಲ್ಲಿ, Unknown ಮತ್ತು timeouts ಗಾಗಿ ಸ್ಪಷ್ಟ fallbacks ಜೊತೆಗೆ.

Unknown ಮತ್ತು abstention

ಸಾಕ್ಷ್ಯವು ವಿಶ್ವಾಸಾರ್ಹ ನಿರ್ಧಾರವನ್ನು ಬೆಂಬಲಿಸದಾಗ ಫಲಿತಾಂಶ Unknown ಆಗಿರುತ್ತದೆ. Unknown ಅನ್ನು ಎಂದಿಗೂ Human ಗೆ ಪರಿವರ್ತಿಸಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಅದು ಸಂಶಯಾಸ್ಪದ ಎಂದು ಅರ್ಥವಲ್ಲ. ಅದನ್ನು ಗೋಚರವಾಗಿಯೇ ಇಡುವುದರಿಂದ ನಿಮ್ಮ coverage ಎಲ್ಲಿಗೆ ಮುಕ್ತಾಯವಾಗುತ್ತದೆ ಎಂಬುದು ತಿಳಿಯುತ್ತದೆ, ಮತ್ತು ಯಾವುದನ್ನಾದರೂ enforce ಮಾಡುವ ಮೊದಲು ನಿಮಗೆ ಬೇಕಾಗುವ ಮಾಹಿತಿ ಅದು.

privacy ಮತ್ತು governance ತತ್ವಗಳು

  • ಉದ್ದೇಶ ಮಿತಿಗೊಳಿಕೆ

    Evidence application owner ಗೆ interactions ಅನ್ನು ವಿವರಿಸುತ್ತದೆ. ಇದನ್ನು cross-site profiles ನಿರ್ಮಿಸಲು ಬಳಸಲಾಗುವುದಿಲ್ಲ.

  • ಕನಿಷ್ಠ ಸಂಗ್ರಹ

    ಪ್ರತಿ integration ತನ್ನ context ಗೆ ಅಗತ್ಯವಿರುವುದನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸುತ್ತದೆ. Sensitive telemetry ಗೆ ಸ್ಪಷ್ಟ opt-in ಅಗತ್ಯವಿದೆ.

  • tenant ಪ್ರತ್ಯೇಕತೆ

    ಒಬ್ಬ customer's evidence ಇನ್ನೊಬ್ಬ customerಗೆ ಎಂದಿಗೂ ಕಾಣಿಸುವುದಿಲ್ಲ.

  • ಸಂರಚಿಸಬಹುದಾದ retention

    ಆನ್‌ಬೋರ್ಡಿಂಗ್ ವೇಳೆ ಪ್ರತಿ founding team ಜೊತೆ retention ಕುರಿತು ಒಪ್ಪಿಗೆಯಾಗುತ್ತದೆ.

  • ಗ್ರಾಹಕ-ನಿಯಂತ್ರಿತ ಪ್ರವೇಶ

    ನಿಮ್ಮ ತಂಡದ ಯಾರು ಸಾಕ್ಷ್ಯ ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡಬಹುದು ಎಂದು ನೀವು ನಿರ್ಧರಿಸುತ್ತೀರಿ.

  • identity checks ಇಲ್ಲ

    ಯಾವುದೇ biometric ಸಂಗ್ರಹಣೆಯೂ identity verification ಕೂಡ Proof of Actorನ ಭಾಗವಲ್ಲ.

ಪ್ರತಿಯೊಂದು ತಂಡದೊಂದಿಗೆ ಒಪ್ಪಂದವಾಗಿದೆ

retention ಅವಧಿಗಳು, data fields ಮತ್ತು processors ಆನ್‌ಬೋರ್ಡಿಂಗ್ ವೇಳೆ ಒಪ್ಪಿಗೆಯಾಗುತ್ತವೆ ಮತ್ತು ಪ್ರತಿ founding team ಗಾಗಿ ದಾಖಲಿಸಲಾಗುತ್ತದೆ.

ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ವಿಧಾನಶಾಸ್ತ್ರ

ಪ್ರತಿ ಬೆಂಬಲಿತ ಸಂದರ್ಭದಲ್ಲಿ, founding ತಂಡಗಳು ಈಗಾಗಲೇ ತಿಳಿದಿರುವ outcomes ವಿರುದ್ಧವಾಗಿ coverage, unknown rate, false positives ಮತ್ತು calibration ಅನ್ನು ಅಳೆಯಲಾಗುತ್ತದೆ. ಪ್ರತಿ context ಪಕ್ವವಾಗುತ್ತಿದ್ದಂತೆ methodology ಮತ್ತು results ಅನ್ನು ಇಲ್ಲಿ ಪ್ರಕಟಿಸಲಾಗುತ್ತದೆ.

Early Access ಗೆ ಅರ್ಜಿ ಸಲ್ಲಿಸಿಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ಗೌಪ್ಯತೆ ಅಥವಾ ಭದ್ರತೆ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗಳಿವೆಯೇ? [email protected]

ಸುರಕ್ಷತೆ ಮತ್ತು ಜವಾಬ್ದಾರಿಯುತ ಬಹಿರಂಗಪಡಿಕೆ