MagicPay Memory fill
MagicPay Memory fill is the boundary where approved values are applied to a target — such as a browser checkout field for card, login, identity, CAPTCHA-adjacent, or confirmation — without ever entering the LLM context.
- MagicPay Memory plan/apply workflow for fields the agent must not see.
- LLM-first semantic matcher maps observed fields to Memory handles and request inputs.
- Masks Memory-managed fields and locks screenshots around sensitive execution.
- Returns completion state to the agent, not raw secrets in model-visible context.
Why It Exists
Browser agents are vulnerable to prompt injection and visual leakage. MagicPay Memory fill enforces the MagicPay rule that Memory values should not enter the agent prompt, page screenshot stream, or ordinary browser action log when the user chooses the MagicPay path.
MagicBrowse Bridge
When MagicBrowse observes fillable targets, MagicPay plans against Memory descriptors and then applies the approved plan through the trusted browser boundary.
import { planFill, applyFill } from '@mercuryo-ai/magicpay-sdk/fill-plan-apply'; // Value-free plan over observed targets, semantic matches, and the handle catalog.const plan = await planFill({ sessionId, targetSet, // fingerprint + observed fillable targets targetMatches, // LLM-first semantic field matches memoryCatalog, // handles only, no raw secrets}); // applyFill writes through your guarded targetWriter and never submits, pays,// or books. Values are materialized only at this trusted boundary.const result = await applyFill({ plan, currentTargetState: { fingerprint: targetSet.fingerprint, targets: targetSet.targets }, materializeValue, targetWriter,});Semantic Field Matching
Field matching uses an LLM-first semantic matcher. If matching is unavailable, invalid, or uncertain, Memory fill fails closed and stops instead of guessing.
Security Model
MagicPay Memory fill is designed around a narrow guarantee: Memory values do not enter the agent prompt, screenshots, action logs, or stored run records. The browser agent can identify that a Memory field exists, but the value is resolved by MagicPay and applied through a guarded fill path.
- Screenshots and page captures are banned during Memory value execution and immediately after fill unless the runtime can guarantee masking or redaction before model ingestion.
- Memory forms are masked from the agent: the model can see field purpose, target refs, labels, and status, but not passwords, card values, document numbers, OTPs, private keys, or other Memory values.
- After a Memory fill, later observations, prompts, debug text, and stored run records do not echo the submitted values.
- Debug and log output is redacted so it does not echo submitted values or other sensitive keys.
- Memory fills use short-lived artifacts. The match and fill results carry refs, field keys, filled status, and summaries rather than raw values.
- Ambiguous Memory forms, missing targets, unavailable artifacts, unsupported field groups, invalid date or expiry values, and low-confidence assistive fills block instead of guessing.
Form Masking
The Memory fill path treats the form as a boundary. MagicBrowse first observes fillable targets and submit targets, then MagicPay Memory fill builds a value-free plan from semantic field matches. After approval, values are applied directly to the target fields by the guarded writer. Follow-up observations and run records are redacted with the exact-value profile, so the agent can continue from completion state without reading back the submitted secrets.
| Surface | What the agent can see | What stays Memory-managed |
|---|---|---|
| Before approval | Field purpose, label, target ref, page URL, and requested action. | Stored secret values and request artifacts. |
| During fill | Request status and whether the Memory-managed operation is blocked, filled, or failed. | Raw artifact values and browser field contents. |
| After fill | Filled field refs, completion state, and next required non-secret actions. | Exact submitted values in observations, logs, screenshots, and prompts. |
Operational Rules
MagicPay Memory fill only works if the surrounding runtime respects the boundary. Browser agents should stop at login, identity, payment, and final confirmation fields, let MagicPay handle Memory data, then refresh visible page state and continue only with required non-secret fields. Final submit, purchase, booking, terms acceptance, or account changes still require the appropriate user approval.
- Do not ask the user to paste Memory values into chat.
- Do not route request artifacts through the LLM or ordinary tool logs.
- Do not fill optional newsletter, marketing, promo, survey, or analytics fields after Memory fill.
- Do not submit, book, buy, accept terms, or change account data unless that exact action was approved.
- Treat a compromised browser, host, or agent runtime as outside this SDK-level guarantee; MagicPay Memory fill narrows LLM exposure but cannot protect against code execution on the fill host.