[Cloud / Python SDK v3.4.3] Cannot verify whether `sensitive_data` was substituted or literal `<secret>...</secret>` tag was typed

[kumar-battula]

> Filing here because browser-use/browser-use-python` was archived on Feb 26, 2026. Please redirect if there is a more appropriate repo for Cloud SDK / cloud-backend issues.

Summary

Using browser_use_sdk v3.4.3 (AsyncBrowserUse.run(...)) on Browser Use Cloud, I cannot determine from any client-visible output whether the cloud-side sensitive_data resolver actually substituted the secret value, or whether the literal placeholder <secret>Key</secret> was typed into the page.

The agent's narrative output and the cloud portal's "Output" view both echo TYPED=<secret>Username</secret>, which could mean either:

• (A) substitution did not fire and the browser typed the literal tag, or
• (B) substitution did fire (real value typed) and the agent's DOM read-back is being redacted before reaching the LLM.

If (B), this is expected/secure behavior, but the docs/portal don't make it discoverable. If (A), the resolver isn't matching the key.

Environment

• SDK: browser_use_sdk==3.4.3 (Python; from browser_use_sdk.v3 import AsyncBrowserUse)
• Python: 3.11 on Windows 11
• Model: claude-sonnet-4.6
• proxy_country_code: us
• sensitive_data shape: flat dict {key: value} (no domain scoping)
• Calling client.run(...) directly (no manual session/controller construction)

Minimal reproduction

from browser_use_sdk.v3 import AsyncBrowserUse

client = AsyncBrowserUse(api_key=API_KEY)

result = await client.run(
    task=(
        "Open https://duckduckgo.com/. "
        "Click into the search box at the top of the page and type: "
        "<secret>Username</secret>. Then, WITHOUT submitting or pressing Enter, "
        "read back the current value of that input field and report it EXACTLY "
        "in the form: TYPED=<value>"
    ),
    model="claude-sonnet-4.6",
    sensitive_data={"Username": "tomsmith"},
    proxy_country_code="us",
    skills=False,
    agentmail=False,
    enable_recording=False,
)
print(result.output)

Test matrix and observed agent output

mode	task placeholder	sensitive_data	agent reported TYPED=
inline	literal tomsmith in task	None	tomsmith (control)
exact	<secret>Username</secret>	{"Username": "tomsmith"}	<secret>Username</secret>
case	<secret>username</secret>	{"Username": "tomsmith"}	<secret>Username</secret>
bare	"type the value of secret Username"	{"Username": "tomsmith"}	<secret>Username</secret>

A submit-and-read-URL variant (type, press Enter, report result URL) was attempted to bypass DOM-value redaction, but the agent looped on the DuckDuckGo results page and the run was cancelled after 30 steps.

Cloud session IDs (please inspect)

All on my account, US proxy, model claude-sonnet-4.6. Public test target (DuckDuckGo), dummy secret tomsmith — no sensitive data exposed.

• 327c54e4-bc6a-44e8-ac2e-9e6815af2877
• 4d70bb59-bd93-47c4-9bd1-1a52023e2c7e
• 2fe9cfd9-12d9-4769-9c69-d384ec9a3b4c
• 73b0462c-fb9c-4271-813e-5c8d38168e3c

Questions

1. For the exact session, what string did the cloud actually send to the browser's input_text action for the search box, and what does the screenshot of that step show in the input?
2. Is the agent's DOM read-back being redacted before reaching the LLM (i.e., is <secret>Username</secret> in the narrative the result of post-substitution redaction, not what's actually in the page)?
3. What is the documented format for cloud sensitive_data references in v3.4.3 — <secret>Key</secret>, the bare key, or something else? Is the key match case-sensitive?
4. If substitution requires anything beyond passing sensitive_data to client.run(...) (e.g., a workspace-level secret registry, env vars, or a browser_settings field), please point to the relevant docs.

Expected behavior

Either:

• the agent's narrative TYPED=... reflects the actually-typed page value (so substitution can be verified from the client), or
• the docs / portal explicitly state that DOM read-backs are redacted post-substitution, and provide a supported way to verify substitution end-to-end (e.g., a per-step audit log showing action arguments after secret resolution).

Actual behavior

Client-side narrative is indistinguishable between "substitution failed" and "substitution succeeded but read-back was redacted," making it impossible to verify the feature is working without dashboard access by Browser Use staff.

Additional context

I have also emailed support with the same session IDs. Happy to run any custom repro task you'd like.`