Skip to main content

Open security points

What is open today in both SDKs (the Python package personal_agent_protocol and the npm package @datalayer/personal-agent-protocol), both roles: residual risks, what a deployment must provide, and the questions the PAP draft leaves open. Anything fixed is gone from this page; the changelog says what each release changed. Report a new problem as the support page says.

Residual risks in the SDKs​

  • Known-client records grow with every agent that authenticates. A company keeps one KnownClient record per client_id (the extensions the agent declared), written at its first successful client authentication and never expired. Only an agent with valid metadata and keys adds one, but the set is unbounded. Bound it with the company's client policy (pap.company.clientPolicy) or a store that ages records out.
  • The account directory throttles its own checks. The company limits Mediated Sign-In attempts (per account identifier, per agent and user, per Session, and wrong codes per account), then answers 429 rate_limited. AccountDirectory.authenticate receives a SignInContext and must still throttle its own credential checks, which other paths may reach.

What a deployment must provide​

The SDKs ship portable defaults that are correct in one process. A deployment replaces them where it runs more than one:

  • Company store. Only an in-memory store ships (MemoryCompanyStore). Replicas, restarts, and rollbacks need a durable, shared CompanyStore with atomic create, take, and replace (check_store / checkStore hold a backend to the contract). The default replay cache and the sign-in attempt budgets live in that store, so they are only as shared as the store is. A contributed pap.company.replayCache must be shared across replicas the same way.
  • Key custody. The signer, the agent's private keys, and the company's keys are the host's. Production keys belong in a KMS or HSM behind a contributed pap.signer (or an equivalent remote signing service).
  • Agent-side state. The core plugin contributes no token store, pairwise user ID store, authorization-state store, browser handoff, protected input, or approval surface; the host contributes them (the pap CLI host keeps local files, under a lock, for one user). Account Tokens must be encrypted at rest. The Account Token lock and the rate-limit budget default to in-process: an agent running several processes contributes shared ones.
  • Network policy for Node. The portable TypeScript bundle can only check URLs textually; DNS resolution and address pinning are in the ./server entry (createResolvingFetch). A Node host that builds its own company or identity client, rather than buildCompany, must pass it as fetch.

Open questions in the PAP draft​

The SDKs take a position on each; another implementation may take another, and the conformance runner reports the difference.

  • DPoP refusal at a resource: 400 or 401. The conformance runner expects each refusal's exact status, so a company answering 400 with a DPoP challenge where a fixture expects 401 is reported as a failure.
  • State events around every reply. The SDKs frame each agent reply with working and idle state events; the draft's wording ("every change to either one adds a state event") does not say it explicitly.
  • A renewed-away Session Token. Whether it must stop at once is not a company MUST; the conformance suite does not require it.

Interoperability not yet exercised​

  • The adonis company implementation has not been run against these SDKs: it has no runnable example.
  • Problems found in pi-poppy (operations deduplicated across users, a browser assertion accepted at /oauth/token, no WWW-Authenticate on a replayed jti, no resource_metadata in the MCP 401 challenge) were reported to that project; they are its to fix.