Description

installContextEngineLoopHook() now allows the caller to compute a runtimeContext (via getRuntimeContext({ messages, prePromptMessageCount })) and forwards it into contextEngine.afterTurn() on every tool-loop iteration.

If a ContextEngine implementation is pluggable/third-party (or configurable by a less-trusted actor), this increases the sensitive data surface exposed to that plugin:

• afterTurn() already receives the full messages array (which commonly contains tool results and may include secrets).
• The newly forwarded runtimeContext can additionally include host/runtime-only metadata and PII that may not be present in messages (e.g., workspace paths, agent paths, auth profile IDs, owner phone numbers, sender IDs) as built by the runtime.
• Because the loop hook can run even in long tool loops (and potentially even when the overall attempt later aborts), this provides additional opportunities for a plugin to exfiltrate or log this runtime metadata.

Vulnerable code:

await contextEngine.afterTurn({
  ​// ...
  messages: sourceMessages,
  prePromptMessageCount,
  tokenBudget,
  runtimeContext: params.getRuntimeContext?.({
    messages: sourceMessages,
    prePromptMessageCount,
  }),
});

Recommendation

Treat ContextEngine implementations as an explicit trust boundary.

• Minimize what is exposed in runtimeContext for loop-hook calls. Prefer a small, purpose-built object (e.g., prompt-cache telemetry only) rather than full runtime metadata.
• Redact/omit high-sensitivity fields (e.g., ownerNumbers, authProfileId, filesystem paths) unless the engine is explicitly trusted.
• Consider adding an allowlist / capability flag on the engine (e.g., engine.info.capabilities.runtimeContext = ['promptCache']) to gate what is shared.

Example (only expose prompt cache info):

getRuntimeContext: ({ messages, prePromptMessageCount }) => ({
  promptCache: buildLoopPromptCacheInfo({
    messagesSnapshot: messages,
    prePromptMessageCount,
    retention: effectivePromptCacheRetention,
    fallbackLastCacheTouchAt,
  }),
})

Additionally, document that afterTurn() receives full transcripts (including tool outputs) so operators avoid installing untrusted engines in sensitive environments.

Description

buildLoopPromptCacheInfo() derives lastCallUsage from the latest assistant message via normalizeUsage(currentAttemptAssistant?.usage) and then uses the mere presence of cacheRead/cacheWrite (any number, including negative values) to decide whether to trust and parse assistantTimestamp as the prompt-cache touch time.

If an attacker can inject/spoof assistant messages (or their usage fields) into the message history (e.g., via compromised tool/plugin output, persisted session tampering, or other transcript injection), they can:

• Set usage.cacheRead/cacheWrite to any finite number (including negative) to force the hasCacheUsage branch.
• Supply a crafted timestamp value (string/number) that will be parsed and used as lastCacheTouchAt.

Downstream, lastCacheTouchAt is used by cache-TTL based context pruning to decide whether pruning should be skipped (when Date.now() - lastTouch < ttlMs). A spoofed recent/future touch timestamp can therefore bypass pruning and potentially lead to runaway context growth/cost or context-window overflow (DoS/resource exhaustion).

Vulnerable logic:

const hasCacheUsage =
  typeof params.lastCallUsage?.cacheRead === "number" ||
  typeof params.lastCallUsage?.cacheWrite === "number";
if (!hasCacheUsage) {
  return params.fallbackLastCacheTouchAt ?? null;
}
return (
  parsePromptCacheTouchTimestamp(params.assistantTimestamp) ??
  params.fallbackLastCacheTouchAt ??
  null
);

Recommendation

Treat usage and timestamp from transcript messages as untrusted for cache-TTL decisions.

Suggested hardening (pick one or combine):

1. Validate cache metrics and require a positive value before considering them evidence of prompt-cache activity:

const cacheRead = params.lastCallUsage?.cacheRead;
const cacheWrite = params.lastCallUsage?.cacheWrite;
const hasCacheUsage =
  (typeof cacheRead === "number" && Number.isFinite(cacheRead) && cacheRead > 0) ||
  (typeof cacheWrite === "number" && Number.isFinite(cacheWrite) && cacheWrite > 0);

2. Clamp negative cache values to 0 in normalizeUsage() to prevent negative values from triggering logic.

3. Constrain accepted timestamps (e.g., reject future timestamps or those too far from Date.now()), and/or only accept timestamps sourced from the provider response rather than from message history.

4. If possible, store cache touch events in sessionManager entries (trusted local state) rather than deriving from message fields, and use those for TTL computations.