ਮੁੱਖ ਸਮੱਗਰੀ 'ਤੇ ਜਾਓ
ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

Proof of Actor ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਆਉਣ ਵਾਲੀ interaction ਤੋਂ application decision ਤੱਕ 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. 01ਐਪਲੀਕੇਸ਼ਨ request ਜਾਂ eventਇੱਕ page view, ਇੱਕ API call, ਇੱਕ MCP tool call ਜਾਂ ਇੱਕ in-app action।
  2. 02supported integration ਤੋਂ signalsਸਿਰਫ਼ ਉਹ ਜੋ ਉਹ integration ਉਸ context ਵਿੱਚ observe ਕਰ ਸਕਦਾ ਹੈ।
  3. 03Evidence normalization ਅਤੇ classificationsignals ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ basis ਅਨੁਸਾਰ label ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ।
  4. 04ਆਧਾਰ ਅਤੇ ਅਣਿਸ਼ਚਿਤਤਾ ਨਾਲ ਐਕਟਰ ਨਤੀਜਾHuman, Human + AI, Agent ਜਾਂ Unknown, ਨਾਲ ਹੀ ਇਹ ਕਿਸ ਆਧਾਰ 'ਤੇ ਟਿਕਿਆ ਹੈ।
  5. 05dashboard ਅਤੇ analyticsਤੁਹਾਡੀ team ਵੱਲੋਂ review ਕਰਨ ਲਈ trends, routes ਅਤੇ evidence।
  6. 06ਤੁਹਾਡੇ application ਦਾ ਆਪਣਾ decisionਸਿਰਫ਼ observe ਕਰੋ, ਜਾਂ ਉਹ policy ਲਾਗੂ ਕਰੋ ਜੋ ਤੁਸੀਂ ਚੁਣੀ ਹੈ।
ਡਿਵੈਲਪਰਾਂ ਲਈ

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
result ਦੇ ਪਿੱਛੇ ਦੇ signals, ਤਾਂ ਜੋ ਤੁਹਾਡੀ team ਵੇਖ ਸਕੇ ਕਿ ਕਿਉਂ।

observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ: results ਨੂੰ ਆਪਣੇ logs ਦੇ ਨਾਲ record ਕਰੋ ਅਤੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕੋਈ policy ਨਾ ਚੁਣੋ, ਕੁਝ ਵੀ ਨਾ ਬਦਲੋ। Node.js integration guide ਪੜ੍ਹੋ

Observation mode ਡਿਫਾਲਟ ਹੈ

Proof of Actor install ਕਰਨ ਨਾਲ ਕੋਈ request block ਜਾਂ change ਨਹੀਂ ਹੁੰਦੀ। Results record ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਤਾਂ ਜੋ ਤੁਹਾਡੀ team ਉਨ੍ਹਾਂ ਦੀ compare real application outcomes ਨਾਲ ਕਰ ਸਕੇ, false positives review ਕਰ ਸਕੇ, ਅਤੇ decide ਕਰ ਸਕੇ ਕਿ ਕੋਈ policy ਉਚਿਤ ਹੈ ਜਾਂ ਨਹੀਂ।

evidence ਦੇ ਪ੍ਰਕਾਰ

ਉਪਲਬਧ evidence integration ਅਤੇ context 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਹਰ workflow ਲਈ checks onboarding ਦੌਰਾਨ ਟੀਮ ਨਾਲ ਤੈਅ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ signal internals private ਰਹਿੰਦੇ ਹਨ ਤਾਂ ਜੋ ਉਨ੍ਹਾਂ ਦੀ ਨਕਲ ਕਰਨਾ ਔਖਾ ਹੋਵੇ।

  • request signatures

    ਉਹਨਾਂ automated clients ਤੋਂ cryptographic signatures ਜੋ ਆਪਣੀਆਂ keys publish ਕਰਦੇ ਹਨ।

  • ਘੋਸ਼ਣਾਵਾਂ

    ਇੱਕ client ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ Agent ਵਜੋਂ ਦਰਸਾਉਂਦਾ ਹੈ, ਜਾਂ ਤੁਹਾਡੀ app ਦੇ ਅੰਦਰ AI-assistance disclosure।

  • ਕਿਰਿਆ ਸੰਕੇਤ

    ਇੱਕ approved browser collector ਤੋਂ signals, ਉਹਨਾਂ pages 'ਤੇ ਜਿੱਥੇ ਇਹ ਚਲਦਾ ਹੈ।

  • request context

    server-side integration ਲਈ ਉਪਲਬਧ headers ਅਤੇ protocol ਵੇਰਵੇ।

Agent identity authorization ਨਹੀਂ ਹੈ

ਇੱਕ automated client ਤੋਂ ਆਇਆ signed request ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ request ਨੂੰ published identifier, ਜਿਵੇਂ ਕਿ operator ਦੇ domain, ਨਾਲ ਜੁੜੀ key ਨਾਲ sign ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਇਸ ਗੱਲ ਬਾਰੇ ਲਾਭਦਾਇਕ evidence ਹੈ ਕਿ ਕਿਹੜੇ client ਨੇ ਇਸਨੂੰ ਭੇਜਿਆ।

ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਕਿ agent ਨੂੰ ਕਿਸਨੇ instruction ਦਿੱਤੀ, ਕੀ ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ ਇਸ ਨੂੰ permission ਸੌਂਪੀ, ਇਸਦੇ ਪਿੱਛੇ ਕਾਨੂੰਨੀ ਪਹਿਚਾਣ ਕੀ ਹੈ, ਜਾਂ ਕੀ ਇਹ ਕਾਰਵਾਈ ਸੁਰੱਖਿਅਤ ਹੈ। ਇਹ ਵੱਖ-ਵੱਖ ਸਵਾਲ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੇ ਜਵਾਬ ਤੁਹਾਡੀ application ਆਪਣੇ authentication, authorization ਅਤੇ policy ਨਾਲ ਦਿੰਦੀ ਹੈ।

ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲ
  • ਕੌਣ call ਕਰ ਰਿਹਾ ਹੈ?Proof of Actor: signature, declaration ਜਾਂ inference
  • ਕਿਹੜੀ credential?ਤੁਹਾਡੀ API key, OAuth token ਜਾਂ session
  • ਇਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ?ਤੁਹਾਡੀ authorization ਅਤੇ policy

routing decisions ਕਿੱਥੇ fit ਹੁੰਦੇ ਹਨ

ਤੁਹਾਡੀ application Proof of Actor ਨੂੰ call ਕਰਦੀ ਹੈ, ਇੱਕ result ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਆਪਣੇ rules ਲਾਗੂ ਕਰਦੀ ਹੈ। ਤੁਸੀਂ ਹਰ route ਅਤੇ ਹਰ risk tier ਲਈ ਚੁਣਦੇ ਹੋ ਕਿ integration fail open ਹੋਵੇ (request ਉਸੇ ਤਰ੍ਹਾਂ ਅੱਗੇ ਵਧੇ ਜਿਵੇਂ Proof of Actor ਨਾ ਹੋਵੇ) ਜਾਂ fail closed ਹੋਵੇ (ਤੁਹਾਡਾ ਮੌਜੂਦਾ stronger check ਲਾਗੂ ਹੋਵੇ)।

  • API ਸਮਾਂ ਸਮਾਪਤ

    ਜੇ ਕੋਈ ਨਤੀਜਾ ਸਮੇਂ 'ਤੇ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਤੁਹਾਡੀ integration ਉਸ route ਲਈ ਤੁਹਾਡੇ ਵੱਲੋਂ ਚੁਣਿਆ fallback ਵਰਤਦੀ ਹੈ। timeout ਕਦੇ ਵੀ Human ਨਤੀਜਾ ਨਹੀਂ ਬਣਦਾ।

  • Telemetry ਦੀ ਕਮੀ

    ਜੇ browser collector ਨਹੀਂ ਚੱਲਿਆ ਜਾਂ ਕੋਈ signal ਮੌਜੂਦ ਨਹੀਂ, ਤਾਂ ਨਤੀਜਾ ਇਹੀ ਦਰਸਾਉਂਦਾ ਹੈ। ਗੁੰਮ ਸਬੂਤ ਇਸ ਗੱਲ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ; ਇਸਨੂੰ ਸ਼ੱਕੀ ਨਹੀਂ ਮੰਨਿਆ ਜਾਂਦਾ।

  • ਅਣਜਾਣ ਵਰਗੀਕਰਨ

    Unknown ਇੱਕ ਆਮ ਨਤੀਜਾ ਹੈ। ਤੁਹਾਡੀ policy ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੀ ਹੈ ਕਿ ਹਰ route ਲਈ Unknown ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਉਦਾਹਰਨ ਲਈ: public pages ਨੂੰ allow ਕਰੋ, account changes 'ਤੇ ਮੌਜੂਦਾ checks ਕਾਇਮ ਰੱਖੋ।

  • ਪੁਰਾਣਾ evidence

    Evidence ਦਾ ਇੱਕ ਸਮਾਂ ਅਤੇ ਇੱਕ scope ਹੁੰਦਾ ਹੈ। session ਦੇ ਪਹਿਲਾਂ ਦੇ ਕਿਸੇ result ਨੂੰ ਬਾਅਦ ਦੀ, ਵਧੇਰੇ sensitive ਕਾਰਵਾਈ ਲਈ fresh check ਬਿਨਾਂ ਮੁੜ ਨਹੀਂ ਵਰਤਣਾ ਚਾਹੀਦਾ।

beta integration workflow

  1. 01ਲਾਗੂ ਕਰੋਸਾਨੂੰ app ਅਤੇ ਉਸ interaction ਬਾਰੇ ਦੱਸੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸਮਝਣਾ ਚਾਹੁੰਦੇ ਹੋ।
  2. 02ਸੀਮਾintegration, routes, usage limits ਅਤੇ data handling 'ਤੇ ਸਹਿਮਤ ਹੋਵੋ।
  3. 03ਨਿਰੀਖਣ ਮੋਡ ਵਿੱਚ ਇੰਟੀਗ੍ਰੇਟ ਕਰੋਤੁਹਾਡਾ app ਕਿਵੇਂ respond ਕਰਦਾ ਹੈ, ਇਸ ਵਿੱਚ ਕੋਈ ਤਬਦੀਲੀ ਨਹੀਂ।
  4. 04ਤਸਦੀਕ ਕਰੋਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਉਸ ground truth ਨਾਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ: coverage, unknown rate, false positives, latency।
  5. 05ਫੈਸਲਾ ਕਰੋਕੇਵਲ ਉੱਥੇ policy enable ਕਰੋ ਜਿੱਥੇ evidence ਇਸ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੋਵੇ।

ਅਸੀਂ founding teams ਨਾਲ ਕੀ ਮਾਪਦੇ ਹਾਂ

ਹਰ supported context ਵਿੱਚ coverage, unknown rate, known outcomes ਦੇ ਮੁਕਾਬਲੇ false positives, ਅਤੇ ਵਾਧੂ latency।

observation mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ।

founding developer program ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਲਈ apply ਕਰੋ।

Early Access ਲਈ ਅਰਜ਼ੀ ਦਿਓDetection ਅਤੇ Limits ਵੇਖੋ

ਪਹਿਲਾਂ ਗੱਲ ਕਰਨੀ ਪਸੰਦ ਕਰੋਗੇ? founders ਨਾਲ ਗੱਲ ਕਰੋ