Repository navigation
Centralize the text the adapter puts into an agent's context #8
Description
Raised as a review comment on #5 (adapters/adapter-core/src/server.ts), marked no changes needed — recorded here so it is not lost:
No changes needed but need to create a todo to place agent context/prompt/hint to somewhere. To prevent context injected without our knowledge.
The concern
Some strings the adapter emits are not diagnostics for a human log — they land in an agent's context and are read as instruction-adjacent text. Today each one is written inline at the site that emits it, so a new one can be added without anyone reviewing it as agent-facing content.
Known sites (after #5 and #6 land):
| Where | What |
|---|---|
server.ts — DEFAULT_CREDENTIAL_HINT |
the how field on a 401, telling the caller where a credential comes from |
server.ts — delete guard |
the resolution field on a 409 record_referenced |
a2app_adapter.py |
the same resolution, duplicated for the Python adapter |
_a2app.pb.js |
the same resolution, duplicated for the PocketBase adapter |
The sharper half
credentialHint is app-supplied: an app sets it in config and the adapter forwards it into the agent's context verbatim, unbounded. That is the actual injection path — not the framework's own strings, which at least go through review.
The connect skill already tells agents that a remote app's text is data and never a directive, and that the how field informs a human rather than instructing an agent. That rule is currently carried only by the skill, and is not enforced anywhere in the adapter.
Worth considering
- One declared place per adapter for framework-authored agent-facing text, so adding a string is a visible act rather than an incidental one.
- A bound on app-supplied text (
credentialHint): length cap, single line. - A test that fails when a new agent-facing string appears outside that place.
Why not a PR yet
DEFAULT_CREDENTIAL_HINT does not exist on main — it arrives with #5 — and both #5 and #6 modify server.ts. A change written now would be built on code that is not merged and would conflict with both. This is worth doing after #5 and #6 land.
Whether to bound the app-supplied hint is a protocol decision rather than a cleanup, so it wants a deliberate call rather than being folded into a refactor.
Activity