Bound model-visible external-context adapter metadata #107

New issue

Closed

opened 2026-08-18 20:21:25 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-18 20:21:25 +00:00

(Migrated from github.com)

Problem

The trusted external-context adapter boundary added by #106 validates adapter metadata as a ground dict, but adapter metadata is model-visible through context_metadata/2 and the completion planner prompt. A trusted-but-buggy adapter could therefore return an unexpectedly large metadata object before any bounded peek/search/slice operation runs.

The built-in conversation adapter emits a small fixed metadata record and is not affected in practice, but the generic adapter contract should fail closed for future project-KB/database adapters.

Required hardening

Apply a dedicated metadata byte ceiling during context_register_adapter/4.
Prefer an explicit adapter-metadata budget option or reuse the validated context max_bytes ceiling with documented semantics.
Do not silently truncate arbitrary structured metadata into a malformed partial dict. Reject oversized metadata with a structured context_error unless a future safe metadata-compaction contract is introduced.
Measure the serialized model-visible metadata representation, not only host callback payload size.
Preserve small metadata behavior and existing memory text/terms context behavior.
Add an adversarial adapter test returning a large ground metadata dict and prove registration fails before a handle is exposed.
Add a boundary test proving model-authored source data still cannot install an adapter or executable callback.

Acceptance

A registered adapter may expose only bounded safe metadata to the planner. No adapter can bypass context-window management merely by placing source payload into metadata.

## Problem The trusted external-context adapter boundary added by #106 validates adapter metadata as a ground dict, but adapter metadata is model-visible through `context_metadata/2` and the completion planner prompt. A trusted-but-buggy adapter could therefore return an unexpectedly large metadata object before any bounded `peek/search/slice` operation runs. The built-in conversation adapter emits a small fixed metadata record and is not affected in practice, but the generic adapter contract should fail closed for future project-KB/database adapters. ## Required hardening - Apply a dedicated metadata byte ceiling during `context_register_adapter/4`. - Prefer an explicit adapter-metadata budget option or reuse the validated context `max_bytes` ceiling with documented semantics. - Do not silently truncate arbitrary structured metadata into a malformed partial dict. Reject oversized metadata with a structured `context_error` unless a future safe metadata-compaction contract is introduced. - Measure the serialized model-visible metadata representation, not only host callback payload size. - Preserve small metadata behavior and existing memory `text/terms` context behavior. - Add an adversarial adapter test returning a large ground metadata dict and prove registration fails before a handle is exposed. - Add a boundary test proving model-authored source data still cannot install an adapter or executable callback. ## Acceptance A registered adapter may expose only bounded safe metadata to the planner. No adapter can bypass context-window management merely by placing source payload into metadata.