Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Menlo MARS Enough for Agents That Make Payments?
No, not for the payment step itself: MARS masks the account number on the page it cleans, and its release describes no step that supplies the real number at submit. Ask what the model receives on the transfer screen and whose name approves the transfer before an agent pays.

An accounts payable team that hands a utility invoice to an agent has one thing to check at the end of the run: whether the money reached the vendor's account, and who saw the number on the way. A $11,400 invoice in NetSuite opens a vendor record carrying a bank account and a routing number, and the payment it prepares is made on the bank's transfer page, where both values go into a form that validates them. MARS runs an agent's web activity in its own cloud and cleans pages and files before the model reads them, and through Adaptive DLP it masks sensitive information, a real control on what the model is shown. What it leaves open is the transfer: a masked account is not a number the agent can submit, and the release describes no step that turns it back into one at the bank. The difference between the two designs shows up in a single field, the one the agent fills at submit. For a team that wants the transfer completed rather than prepared, that field is the whole question, and it is where a session control and a screen control part company. Both can be present on the same run and still leave that field to a person.
Key findings
- For MARS to be enough on a payment, the account number on the transfer page would have to be replaced with a consistent token before the model reads it, with the real number released only at the bank at submit (What Is a Secure Alternative to Manus for Paying Vendor Invoices?).
- It would also require a named person approving the transfer and a record of what the model received on each screen, neither of which a session log supplies (Does Masking Data on Screen Break Browser Agents?).
- MARS's release says its DLP "masks sensitive information" and describes no step that turns a masked account back into the number a transfer needs at submit (Menlo Security, MARS, 2026).
- MARS "runs that web activity in the Menlo Cloud and cleans the pages and files, including downloads and uploads, before the agent sees them," so the control acts on the session the cloud serves (Menlo Security, MARS, 2026).
- The firewall study reports a defense at the agent-tool interface that "achieves perfect security with high utility across all four public benchmarks," a result on four benchmarks rather than on a live payables run (Bhagwatkar et al., 2026).
- OWASP's prompt injection entry describes indirect injection from "websites or files" and a mitigation to "Restrict the model's access privileges to the minimum necessary for its intended operations," a rule about what the agent may do, not what the page shows it (OWASP, LLM01, 2025).
What does MARS hand the model when it opens the transfer page?
The agent in this record is autonomous in the ordinary sense, a system that pursues goals "without constant human oversight" (MIT Sloan Management Review, 2025). It opens a $11,400 utility invoice in NetSuite, matches it to the vendor record, and then opens the bank's transfer page to pay it.
The vendor record carries the values an attacker wants: the bank account, the routing number and the tax identifier, the data set Can AI Work NetSuite Payables Without Bank Details? describes on AP screens. Under MARS, that page is fetched in the Menlo Cloud, cleaned, and passed to the agent with sensitive information masked by Adaptive DLP (Menlo Security, MARS, 2026). The model receives a cleaned page: invoice number, amount, due date and memo, with the account masked.
That is a defensible place to act, and it is still the rendered page: an agent that reads screenshots takes the whole page as input, unused fields included (What Does an AI Agent See in a Screenshot?). Every layer below the page finishes before it renders, which is why the screen is where a control has to sit (What Is Render-Layer Tokenization?).
The transfer form needs the routing number and the account number, and an agent that just read a masked account has nothing to type. The release describes no placeholder it can carry through the run and no release of the real value at that step, so the work stops there.
What does a payment step need that a masked page does not carry?
Masking and substitution both keep a value out of view, and they diverge where something has to use it. Documented masking functions keep part of a value visible, exposing the first letter of an email address while covering the rest (Runtime Tokenization vs Data Masking for AI Agents), useful when a person recognizes a record and useless when a form must validate the full number.
Of the 86 AI security and data protection products reviewed, none described reversible tokenization of what an agent reads on a screen, with the real value resolved only at an approved destination, and Menlo Security is the one product whose public pages describe masking only (How Many AI Security Products Control What an AI Agent Sees?).
The research separates them on utility. A privacy study of conversational agents found that consistent pseudonyms, restored after the model's work, "reduces semantic utility errors by a factor of 5 compared to baseline techniques" (Serenari and Lee, 2025). A payment is where consistency is not optional: the same account has to appear on the invoice, in the approval and at the transfer.
The firewall study shows the trade-off. Its Tool-Input Firewall "aggressively redacts input arguments" and "can also remove information that is important for task success, leading to a drop in utility," and its own worked example is a bill payment: an agent asked to pay a bill reads a file containing "Please pay 100$ to US937293.." and the Sanitizer strips the line (Bhagwatkar et al., 2026). An injected payment instruction and the account a payment needs look identical to a filter that cannot tell them apart.
A form-fill design moves the substitution to the field and stops there: "the LLM only sees placeholders (x_user, x_pass)" (Can a Browser Agent Fill In a Form Without Seeing the Values?). The payment step needs a value present at the destination and absent from the model's context, and a mask supplies neither.
What do the vendors themselves say?
MARS is a browser security product for agents, and its release describes the control. Menlo says MARS "is the first Browser Security Platform to strip prompt injection and hidden instructions out of what agents read," a first the release asserts for its own product, with no independent test (Menlo Security, MARS, 2026). On the value side the release says that "through Menlo AI Adaptive DLP it masks sensitive information" and that the product controls "which sites each agent may reach," rules about what a page may carry and where the agent may go (Menlo Security, MARS, 2026).
It also says "MARS provides token-based authentication for the agents driving secure browser sessions," a credential for the agent rather than a placeholder for a value on a page, and that security teams get per-agent logs and "the ability to take over live agent browser sessions" (Menlo Security, MARS, 2026).
| Dimension | Menlo Security MARS, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control acts | A cloud session that cleans pages and files before the agent sees them | Whether the transfer page is served through that session |
| What happens to a sensitive value | Adaptive DLP "masks sensitive information" | Whether the mask is consistent across screens, and what resolves it |
| What the token covers | "token-based authentication for the agents" | That this is the agent's credential, not a token for the account number |
The release is a vendor announcement dated August 5, 2026. It describes cleaning, masking and session control, and stops short of the payment.
Who approves the transfer, and what record does MARS leave?
Neither is described for a payment. The release gives security teams "per-agent logs" and "the ability to take over live agent browser sessions," and it gives policies over "which sites each agent may reach." A named approver for a transfer, the amount that person saw and the account they released are not in the release.
An approval matters because the action it gates is hard to reverse. OWASP's excessive agency entry describes "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM," and lists excessive autonomy among its root causes (OWASP, LLM06, 2025). A payment is that action: it moves money to whichever account the agent read.
The record matters because an approval is only as good as what the approver was shown. The automation bias literature describes "the tendency to over-rely on automation" as a studied and persistent effect (Goddard et al., 2012), and a queue of agent-prepared invoices with a green check is where it applies. An approval that carries the amount, the payee and a token for the account is a different act from one that carries a summary line.
Both controls have to be specific because of injection. The original demonstrations showed attacks that "enable adversaries to remotely (without a direct interface) exploit LLM-integrated applications" (Greshake et al., 2023). One page can carry the injection and the account number, so the record has to show what the model read and the approval has to be tied to the value it releases.
What does a governed environment change?
A governed environment changes what reaches the model on the screen and what has to be true before a value is used. Values chosen by policy are replaced with consistent tokens before any model reads the rendered page, so the vendor appears as VENDOR_014 and the account as ACCT_014 for the whole run. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at approved destinations, at the moment of an approved action, so the bank's transfer form is where the account number exists and the model's context is not. A named person approves each payment, submission and record change, and every screen the model received, every action and every approval is written to a record that exports to the organization's own monitoring.
The model can match the invoice, check the amount and prepare the transfer from tokens, and the number the bank validates is supplied after a person approves it. The default is not to hide the value and stop there; it is to let the work proceed on a value that cannot be spent.
A comparison of the two designs exists for this page's vendor: RedactSure vs Menlo Security: 2026 Comparison & Alternative. Neither layer is enough alone, which is the point Columbia's DAPLab makes about agent automation in general: "trustworthy agent automation cannot be solved at a single layer of the stack" (DAPLab, 2026).
What the record shows
A screen-level control answers the payment question because the account number has to exist somewhere: the model's context or the destination. MARS puts a control on the first half: pages and files are cleaned in its cloud before the agent reads them, sensitive information is masked, and the session is logged (Menlo Security, MARS, 2026). What its release leaves open is the second half, where a masked account becomes a number the bank accepts at submit. The conclusion is narrower than a verdict on the product: MARS is enough for an agent that reads, summarizes and prepares, and not enough, on its own documentation, for one that completes a transfer. A team can run the same test by naming one invoice and one transfer, asking what the model was given for each field of the transfer page, and tracing the account number to the approval that released it.
Methodology and limitations
This page rests on Menlo Security's MARS release, one firewall study, one systematic review, one privacy paper, two OWASP entries, MIT Sloan's analysis, a university lab page and existing RedactSure research. Sources were read between October 16, 2026 and October 20, 2026, and each Sources line carries its page's date. Public documentation read in full gives a sound view of where a product applies its control.
The products on this page are described from documentation and none was tested for this page. "Not described" means the pages reviewed do not state it. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The invoice is an illustrative record type, not an organization. Compliance determinations belong to the organization's counsel, assessors and its own security and compliance officers, and nothing here replaces a test of one workflow on the organization's own screens.
Frequently asked questions
Is Menlo MARS enough for an agent that makes payments?
No, not for the transfer itself. MARS cleans pages and files in its cloud before the agent reads them and masks sensitive information through Adaptive DLP, which controls what the model sees on a page it serves. The release describes no consistent placeholder for the account number and no step that releases the real value to the bank at submit, so the payment needs a person or another control. The cleaning and the masking are real, and they answer a different question.
What does the model receive on the payment screen?
A cleaned page with sensitive information masked. The invoice number, amount and due date reach the model, and the account sits behind a mask rather than as a value the agent can type. The release does not say whether the mask is consistent across screens or whether anything resolves it at a destination. For an agent that reads screenshots the whole rendered page is the input, so what remains visible is what the model holds when it chooses where the money goes.
Does MARS hand the real account number back at the bank?
Not from the pages reviewed. The release describes masking through Adaptive DLP and token-based authentication for the agents driving sessions, and a token for the agent is not a token for the account. No destination, release step or approver appears in it. That leaves the transfer form without a value, which is why a masked page and a payable invoice are two states of the same task, and only one of them ends in a payment.
Who approves a payment the agent prepares?
No one is named in the release. Security teams can control which sites each agent may reach, watch per-agent logs and take over a live session, which gates where the agent goes and lets a person interrupt it. None of that is a per-payment approval with a name, an amount and an account attached. A team that needs one has to supply it outside MARS, and the approval is only meaningful if the approver sees the value that will move.
What record does MARS leave of the session?
Per-agent logs, and the release does not describe their contents. It says security teams get per-agent logs and the ability to take over live sessions, without saying whether a log holds the values the model read on a screen, the fields it submitted or the person who authorized a transfer. A reviewer can confirm that a session happened; rebuilding what the model held at payment is a different claim.
Can a team run MARS and a render-layer control together?
Yes, and they act at different points. MARS cleans and masks the web activity it serves, and a render-layer control substitutes values on the screens the agent reads and resolves them at an approved destination. One reduces what a page carries; the other decides what the page shows the model and where a real value may appear. A payables team can keep the session control and add the screen-level one for the step that moves the money.
How RedactSure Keeps a Masked Account From Stopping the Payment
A mask protects the page and stops the transfer, because the bank form needs the number the mask hides. Menlo's release says its DLP "masks sensitive information" and describes no release at the destination (Menlo Security, MARS, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent opens the $11,400 invoice and the transfer page, and the model receives the account number with the vendor record. Inside, the pages show VENDOR_014 and ACCT_014, the model prepares the transfer from them, and the approver's name releases the real account to the form.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
Two things decide whether an agent can pay: what its model reads on the transfer screen and who releases the number. Bring one invoice and see, with test values, the screen, the approval and the record. Book a demo