Stop printing API keys back out, and bound the hosted listing walk

Four things the review found, all in the hosted-engine path this PR added.

`RequestBuilder::bearer_auth` marks its value sensitive; `header` handed a
plain string does not. So the two schemes with no such helper -- Cognee's
`X-API-Key` and Mem0's `Authorization: Token` -- carried a live credential
through every `Debug` rendering of the request. The test that pins this
prints the leak when reverted: `no sensitive header on {"x-api-key":
"cg-secret"}`. Both now go through one helper that sets the flag, and that
parses the value up front so a credential holding a newline fails at the
call site by name rather than inside `send` where it reads as a transport
fault. The parse error carries no value, so the refusal cannot echo the key
either.

Mem0's hosted listing stopped on an empty page or a null `next` -- both
server-controlled. A server that keeps answering a full page and a cursor
spun the loop and grew the buffer until the process died. It is now bounded
at 500 pages of 200 and fails saying so, which is what the self-hosted arm
already did at its own ceiling. The page size became a constant so the
message cannot drift from the request.

The `X-API-Key` doc line had ended up above `token` instead of `api_key`,
leaving one constructor with two contradictory doc lines and the other with
none. The README still said "plus self-hosted Mem0" one paragraph after the
table started advertising the hosted platform, and showed `CogneeMemory::api`
twice with the same shape; the second is now the `Mem0Memory::cloud`
constructor that section exists to document, and the auth paragraph names
Mem0's two schemes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: YellowSnnowmann

README.md

@@ -177,10 +177,10 @@ that skips enforcement is the entire reason the policy layer exists.
 ## Remote engines
 
 The `tinymemory-remote` crate supports the managed and self-hosted native APIs
-of Supermemory and Cognee, plus self-hosted Mem0. Each adapter stores
-TinyMemory's key, category, session, and provenance in backend metadata (or a
-Cognee raw-data envelope), so exact CRUD and portability survive the seam while
-recall remains engine-native. Provider-facing dataset names, container tags,
+of Supermemory, Cognee, and Mem0. Each adapter stores TinyMemory's key,
+category, session, and provenance in backend metadata (or a Cognee raw-data
+envelope), so exact CRUD and portability survive the seam while recall remains
+engine-native. Provider-facing dataset names, container tags,
 and filenames are bounded stable hashes, so every namespace and key accepted by
 the TinyMemory contract remains valid on the remote API.
 
@@ -196,21 +196,23 @@ Managed APIs have explicit constructors so their authentication cannot be
 confused with a self-hosted token:
 
 ```rust
-use tinymemory_remote::{CogneeMemory, SupermemoryMemory};
+use tinymemory_remote::{CogneeMemory, Mem0Memory, SupermemoryMemory};
 
 // Cognee Cloud issues a per-tenant base URL (the API-key dashboard shows it);
-// there is no shared endpoint.
+// there is no shared endpoint, so its constructor takes one.
 let cognee = CogneeMemory::api("https://tenant-<uuid>.aws.cognee.ai", "cognee-api-key")?;
-let supermemory = SupermemoryMemory::cloud("sm_...")?;
 
-// Cognee also issues tenant-specific API origins.
-let tenant = CogneeMemory::api("https://tenant.example.cognee.ai", "api-key")?;
-# Ok::<_, anyhow::Error>((cognee, supermemory, tenant))
+// Supermemory and Mem0 both serve one hosted origin, so theirs take only a key.
+let supermemory = SupermemoryMemory::cloud("sm_...")?;
+let mem0 = Mem0Memory::cloud("m0-...")?;
+# Ok::<_, anyhow::Error>((cognee, supermemory, mem0))
 ```
 
 Cognee Cloud uses `X-Api-Key`; authenticated self-hosted Cognee uses a bearer
-access token. Supermemory uses bearer API keys for both deployment modes. All
-constructors redact credentials from `Debug` output and transport errors.
+access token. Supermemory uses bearer API keys for both deployment modes. Mem0's
+hosted platform uses `Authorization: Token`, and self-hosted Mem0 uses
+`X-API-Key`. All constructors redact credentials from `Debug` output, from
+transport errors, and from the request's own header rendering.
 
 All three advertise the mandatory Core, Recall, and Portability families. The
 live Docker harness and conformance command are documented in

adapters/remote/src/common.rs

@@ -4,6 +4,7 @@ use std::collections::BTreeMap;
 
 use anyhow::{bail, Context};
 use async_trait::async_trait;
+use reqwest::header::{HeaderValue, AUTHORIZATION};
 use reqwest::{Method, RequestBuilder, StatusCode, Url};
 use serde::{de::DeserializeOwned, Deserialize, Serialize};
 use sha2::{Digest, Sha256};
@@ -97,6 +98,27 @@ async fn read_capped(response: reqwest::Response, path: &str) -> anyhow::Result<
     Ok(body)
 }
 
+/// Wraps a credential in a header value that will not be printed back out.
+///
+/// `RequestBuilder::bearer_auth` marks its `Authorization` value sensitive on
+/// the caller's behalf; `RequestBuilder::header` handed a plain string does
+/// not. So the two schemes that have no such helper -- `X-API-Key` and
+/// `Authorization: Token` -- would otherwise carry a live API key through
+/// every `Debug` rendering of the request and through any middleware that
+/// formats headers. The flag is set here instead.
+///
+/// Parsing up front is the second half of the same fix: a credential holding a
+/// newline or another byte no header may carry becomes an error at the call
+/// site, naming the credential, rather than a deferred failure inside `send`
+/// that reads as a transport fault. The parse error carries no value, so the
+/// credential does not reach the message either.
+fn credential_header(value: &str) -> anyhow::Result<HeaderValue> {
+    let mut header =
+        HeaderValue::from_str(value).context("credential is not a valid HTTP header value")?;
+    header.set_sensitive(true);
+    Ok(header)
+}
+
 impl HttpClient {
     /// Builds a client that optionally authenticates with a bearer token.
     pub(crate) fn bearer(endpoint: &str, credential: Option<&str>) -> anyhow::Result<Self> {
@@ -106,7 +128,6 @@ impl HttpClient {
         )
     }
 
-    /// Builds a client that optionally authenticates with `X-API-Key`.
     /// A client authenticating with `Authorization: Token <key>`.
     pub(crate) fn token(endpoint: &str, credential: Option<&str>) -> anyhow::Result<Self> {
         Self::new(
@@ -115,6 +136,7 @@ impl HttpClient {
         )
     }
 
+    /// Builds a client that optionally authenticates with `X-API-Key`.
     pub(crate) fn api_key(endpoint: &str, credential: Option<&str>) -> anyhow::Result<Self> {
         Self::new(
             endpoint,
@@ -151,8 +173,10 @@ impl HttpClient {
         Ok(match &self.auth {
             Auth::None => request,
             Auth::Bearer(token) => request.bearer_auth(token),
-            Auth::ApiKey(key) => request.header("X-API-Key", key),
-            Auth::Token(key) => request.header("Authorization", format!("Token {key}")),
+            Auth::ApiKey(key) => request.header("X-API-Key", credential_header(key)?),
+            Auth::Token(key) => {
+                request.header(AUTHORIZATION, credential_header(&format!("Token {key}"))?)
+            }
         })
     }
 
@@ -622,6 +646,72 @@ fn classify_transport(is_timeout: bool, is_connect: bool, chain: &str) -> &'stat
     }
 }
 
+#[cfg(test)]
+mod credential_header_tests {
+    #![allow(clippy::expect_used, clippy::panic)]
+
+    use super::{credential_header, Auth, HttpClient};
+
+    /// The point of the helper. `reqwest` only redacts a header value whose
+    /// sensitive flag is set, and `RequestBuilder::header` handed a plain
+    /// string leaves it clear -- which is how an API key ends up rendered in
+    /// full by anything that formats the request.
+    #[test]
+    fn a_credential_header_is_marked_sensitive() {
+        let header = credential_header("Token m0-secret").expect("a plain key is a valid header");
+        assert!(header.is_sensitive());
+    }
+
+    /// The value still has to be the credential; marking it sensitive must not
+    /// change what goes on the wire.
+    #[test]
+    fn marking_it_sensitive_does_not_change_the_value() {
+        let header = credential_header("Token m0-secret").expect("valid");
+        assert_eq!(header.as_bytes(), b"Token m0-secret");
+    }
+
+    /// A credential carrying a newline cannot be a header. Rejecting it here
+    /// names the credential; letting it through defers the failure into `send`,
+    /// where it reads as a transport fault.
+    #[test]
+    fn a_credential_that_cannot_be_a_header_is_refused_by_name() {
+        let error = credential_header("key\r\nX-Injected: 1").expect_err("must not be accepted");
+        assert!(format!("{error}").contains("credential"), "got: {error}");
+    }
+
+    /// And the refusal must not print the credential it refused.
+    #[test]
+    fn the_refusal_does_not_echo_the_credential() {
+        let error =
+            credential_header("supersecret\nX-Injected: 1").expect_err("must not be accepted");
+        let rendered = format!("{error:?}");
+        assert!(!rendered.contains("supersecret"), "leaked: {rendered}");
+    }
+
+    /// Both credential-bearing schemes go through the helper, so both reach
+    /// the wire redacted. `Auth::Bearer` is covered by `reqwest`'s own
+    /// `bearer_auth`, which sets the flag itself.
+    #[test]
+    fn both_manual_schemes_send_a_sensitive_authorization_value() {
+        for auth in [
+            Auth::ApiKey("cg-secret".into()),
+            Auth::Token("m0-secret".into()),
+        ] {
+            let client = HttpClient::new("https://example.test", auth).expect("valid endpoint");
+            let request = client
+                .request(reqwest::Method::GET, "v1/thing")
+                .expect("a plain key builds")
+                .build()
+                .expect("request builds");
+            let sensitive = request
+                .headers()
+                .values()
+                .any(reqwest::header::HeaderValue::is_sensitive);
+            assert!(sensitive, "no sensitive header on {:?}", request.headers());
+        }
+    }
+}
+
 #[cfg(test)]
 mod transport_tests {
     use super::classify_transport;

adapters/remote/src/failure_test.rs

@@ -180,6 +180,41 @@ async fn an_unreachable_backend_is_reported_rather_than_hanging() {
     }
 }
 
+#[tokio::test]
+async fn a_cursor_that_never_clears_is_refused_rather_than_walked_for_ever() {
+    // Mem0's hosted arm pages until the server says stop: an empty page or a
+    // null `next`. Both are things the *server* controls, so a server that
+    // keeps answering a page and a cursor -- a bug, a proxy replaying one
+    // response, a filter that never narrows -- would spin the request loop and
+    // grow the buffer until the process died. The self-hosted arm already
+    // refuses past its ceiling; this pins the hosted one doing the same.
+    let app = Router::new().fallback(any(|| async {
+        axum::Json(serde_json::json!({
+            "count": 1,
+            "next": "https://api.mem0.ai/v3/memories/?page=2",
+            "previous": null,
+            "results": [{"id": "m-1", "memory": "x", "metadata": {}}]
+        }))
+    }));
+    let endpoint = serve(app).await;
+    let memory = Mem0Memory::api(&endpoint, "m0-test-key").expect("client");
+
+    // Bounded so a genuinely unbounded loop fails the test rather than hanging
+    // the suite: the ceiling is 500 requests against a local socket, which
+    // finishes far inside this.
+    let outcome =
+        tokio::time::timeout(std::time::Duration::from_secs(60), memory.get("ns", "k")).await;
+
+    let Ok(result) = outcome else {
+        panic!("the hosted listing never terminated against a cursor that never clears");
+    };
+    let error = result.expect_err("a cursor that never clears cannot be answered correctly");
+    assert!(
+        format!("{error:#}").contains("pages"),
+        "the refusal must name the page ceiling it hit, got: {error:#}"
+    );
+}
+
 #[tokio::test]
 async fn a_paginated_export_terminates_instead_of_looping() {
     // The partial-page leg of §E6. A backend that keeps answering with a page

adapters/remote/src/mem0.rs

@@ -47,6 +47,19 @@ enum Flavour {
 /// from anything else in the same Mem0 project.
 const CLOUD_AGENT_ID: &str = "tinymemory";
 
+/// Records requested per hosted-platform listing page.
+const CLOUD_PAGE_SIZE: u32 = 200;
+
+/// The most pages one hosted-platform listing will walk.
+///
+/// The walk already stops on an empty page and on a null `next`, which covers
+/// a well-behaved server. It does not cover a server that keeps answering a
+/// full page and a non-null cursor: that spins the loop and grows the buffer
+/// until the process dies. 500 pages is 100_000 records -- far past any real
+/// account this adapter writes, and small enough that the failure arrives as a
+/// message rather than an OOM.
+const CLOUD_MAX_PAGES: u32 = 500;
+
 /// A Mem0 service — self-hosted or hosted — exposed through TinyMemory's
 /// storage contract.
 #[derive(Debug)]
@@ -253,9 +266,12 @@ impl Mem0Dialect {
             // `{count, next, previous, results}`. That is the paging this
             // adapter's self-hosted arm documents as unverified — here it is
             // verified against Mem0's API reference, so this arm has no
-            // ceiling to refuse at. Paging stops on an empty page as well as
-            // a null `next`, so a server that omits the cursor cannot spin
-            // the loop.
+            // ceiling to refuse at for a *correct* server. Paging stops on an
+            // empty page as well as a null `next`, so a server that omits the
+            // cursor cannot spin the loop -- but one that keeps answering a
+            // full page and a non-null `next` still can, so the walk is
+            // bounded below and fails loudly at the bound rather than
+            // collecting for ever.
             Flavour::Cloud => {
                 let mut all = Vec::new();
                 let mut page = 1_u32;
@@ -264,7 +280,7 @@ impl Mem0Dialect {
                         .client
                         .json(
                             Method::POST,
-                            &format!("v3/memories/?page={page}&page_size=200"),
+                            &format!("v3/memories/?page={page}&page_size={CLOUD_PAGE_SIZE}"),
                             Some(&json!({"filters": {"agent_id": CLOUD_AGENT_ID}})),
                         )
                         .await?;
@@ -279,6 +295,13 @@ impl Mem0Dialect {
                     if exhausted {
                         break;
                     }
+                    anyhow::ensure!(
+                        page < CLOUD_MAX_PAGES,
+                        "mem0's hosted platform still reported more memories after \
+                         {CLOUD_MAX_PAGES} pages of {CLOUD_PAGE_SIZE}. A cursor that never \
+                         clears is a server fault, not a large account, and continuing \
+                         would neither terminate nor answer correctly."
+                    );
                     page = page.saturating_add(1);
                 }
                 Ok(all)