Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Noma Security's Kill Switch Stop a Leak That Already Happened?
No, not the read that already happened: Noma's AI-DR page lists "trigger a killswitch" among five responses to a risky action, and its runtime control evaluates "tool calls, responses, and session context" after the page has been read. Ask what the model received from the screen before that evaluation, and who approved the action it allowed.
A payout change waits in a merchant dashboard: the bank account, the tax identifier and the account holder's name, drawn in full. An agent reads the page, decides the account on file is wrong, and submits a correction. A runtime control sees the submission, scores it as a risky action and kills the run. The kill is real, and the account number was in the model's context before it fired.
A kill switch is a response to an action, and an action is what an agent does after it has read the page. Noma Security's AI-DR page lists five responses to a risky action, including "trigger a killswitch" (Noma Security, Detection, 2026), and its runtime page says risky actions "can be blocked, steered, or alert a human" (Noma Security, Runtime, 2026). Both sentences are about the action, and what the model received from the screen is the question a kill leaves open.
A stopped payment is a contained action. A model that has read an account number and a tax identifier is exposed already, and the value can leave through a later allowed call, a summary or a transcript. What Is an AI Control Record? and What Is Supervised Delegation? describe the record and the approval that close that gap.
Key findings
- For a kill switch to stop a leak that already happened, the value would have to be kept from the model at the start: the bank account on the payout page replaced with a consistent token before any model reads it, and the real value released only at an approved destination (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
- It would also require a named person approving each payout change and a record of what the model received on every screen, because a switch thrown after the read cannot take the value back out of the context (What Is Supervised Delegation?).
- The pages reviewed describe responses to a risky action, not a control on the read: the runtime page places enforcement at gateways, hooks, SDKs and direct APIs, and it does not describe replacing a value on a screen an application renders (Noma Security, Runtime, 2026).
- Noma Security's AI-DR page lists five answers to a risky action, "block an action, mask sensitive data, steer the agent towards a different path, get a human in the loop, or trigger a killswitch," and it names no person in the loop (Noma Security, Detection, 2026).
- A measured study of web agents found they "are prone to inadvertent use of unnecessary sensitive information," an exposure created by the read rather than by the action (Zharmagambetov et al., 2025).
- Adaptive attacks against 12 published defenses reached an "attack success rate above 90% for most," so a switch that depends on detecting the risky action inherits the detector's miss rate (Nasr et al., 2025).
Where does Noma enforce policy, and does that path include the screen?
On the payout record, the agent opens a settings page, reads the bank account and the tax identifier, drafts a change and submits it. The order is fixed: the page renders, the model reads it, the model composes a request, and a control decides. Everything Noma's pages evaluate exists at the fourth step, so a kill leaves the first three untouched.
The runtime page is explicit about the unit: it "evaluates tool calls, responses, and session context to detect risky behavior and enforce policy," and its enforcement runs through the customer's gateways, hooks, SDKs or APIs (Noma Security, Runtime, 2026). A gateway sits between an agent and a model or tool, a hook runs in the agent's framework, and an SDK sits inside its code, so each sees a request after the agent built it, not the screen the application drew.
Agent Access Control narrows the operation rather than the read. "Access to a tool should not mean access to every operation it supports," and "A request to view data should not become permission to delete it" (Noma Security, Access Control, 2026). A view request that policy allows still travels from a model that has already read the page.
The strongest result in that line is a "simple, modular, and model-agnostic defense operating at the agent-tool interface" that reaches perfect security on four public benchmarks, which the same paper calls "easily saturated by a simple approach" (Bhagwatkar et al., 2026). The score measures the benchmark, not the screen the agent read.
Where a deployment routes model traffic through something Noma inspects, the request can carry the page's values and the product can mask or block it. Where it does not, the page is read with no control on the path. Either way the decision concerns a request that already contains what the model read (Noma Security, Runtime, 2026). That placement is the common one in the review: 58 of the 86 AI security and data protection products document control over where data can go, and one describes masking what an AI agent reads on the web pages it works in (How Many AI Security Products Control What an AI Agent Sees?).
What do the vendors themselves say?
The four Noma pages place the control on traffic and actions. The table sets their wording beside the check a buyer can run.
| Dimension | Noma Security, per its documentation | What a buyer should verify |
|---|---|---|
| What it evaluates | "Noma evaluates tool calls, responses, and session context to detect risky behavior and enforce policy." (Noma Security, Runtime, 2026) | Whether the page the agent read is part of that evaluation, and what the model held before it |
| What it can do | "block an action, mask sensitive data, steer the agent towards a different path, get a human in the loop, or trigger a killswitch" (Noma Security, Detection, 2026) | Which of the five is configured, and what each one leaves in context |
| Where it sits | "enforce policy through AI gateways, MCP gateways, agent hooks, agent SDKs, and direct APIs" (Noma Security, Runtime, 2026) | Whether that path exists for the agent's browser session |
| Human in the loop | "get a human in the loop," one of five responses (Noma Security, Detection, 2026) | Who the person is, what they see, and where the approval is recorded |
| The record | "Get complete observability into every prompt, tool call, response, and interaction your agents engage in" (Noma Security, Detection, 2026) | Whether the record shows the tokenized screen or only the prompt as sent |
WitnessAI's documentation shows the same placement from a second vendor. Its June post says "every blocked call writes an audit record naming the user, the agent, the tool, and the rule that denied it," a record of the blocked decision rather than of what the model read (WitnessAI, Control, 2026). A record written when a call is denied tells an auditor what the rule stopped. It does not tell them what the model saw on the payout page.
What can a killed run still send, and what does the record show?
A kill ends one request. It does not empty the context, and the next request can be allowed. Noma's integration post states the problem: "a request to an allowed destination can still carry a leaked secret or an injected instruction" (Noma Security, OpenShell, 2026). The destination is allowed, the request is well formed, and the value the model read earlier travels inside it, so a switch that fired on the previous action has nothing to decide.
Harvard's guidance points the same way, with the footnote that the riskiest setup "combines three things: access to private data, exposure to untrusted content, and the ability to send data outward," and that if you can remove one, you should (Harvard University Information Security and Data Privacy, 2026). Removing the data from the model is the move a switch cannot make, and it is the starting point How Do I Design an Agent Workflow That Assumes the Agent Gets Hijacked? takes.
What the record holds is a separate question from what it prevents. Noma's AI-DR page promises observability over every prompt and tool call, which retains the prompt that carried the value (Noma Security, Detection, 2026). That is useful after an incident, and it also means the account number sits in the log, one more place it can be read.
Who approves the action when Noma routes it to a human?
The AI-DR page lists "get a human in the loop" as one of five responses, and the four Noma pages reviewed here do not name the person, the action they see, or where the decision is recorded (Noma Security, Detection, 2026). So the approval story in those pages is an option to involve someone: no named role, no statement of what they review and no record of their answer.
A policy that can route an action to a person is not the same as a named person approving that action on the record. Harvard's guidance asks for human approval "for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard University Information Security and Data Privacy, 2026). The bar names the class of action and asks for a person. It does not say which product satisfies it.
WitnessAI's June post shows the adjacent design, an audit record written "naming the user, the agent, the tool, and the rule that denied it" when a call is blocked (WitnessAI, Control, 2026). A rule that denied a call is not a person who approved one, and a record of the denial is not a record of the read. An approval arrives at the action, which is the fourth step. The person approves a payout change; nobody approved the page the model read. Does Checking Credentials Stop an AI Agent From Taking Unauthorized Actions? makes the related point about authenticated agents, which carry permission that the page can steer.
What does a governed environment change?
The control class that answers this page's question works at the render layer: values chosen by policy are replaced with consistent tokens before the model reads the screen, and the real value resolves only at an approved destination. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers.A named person approves each payment, submission and record change, and every screen as tokens, every action and every approval lands in a record that exports to the organization's own monitoring.
For this page's question, it changes the order. A kill switch decides at the fourth step and leaves the first three as they were. Substitution changes the first step, so the model never receives the account number and the switch has less to stop. The value the model holds is a token such as PAYOUT_001, which is worthless at an allowed destination and in a later summary.
It also changes what the record can answer. A traffic log records the prompt that was sent; a governed environment records the tokenized screen the model read, the action, the approver and where the real value went. RedactSure vs Noma Security: 2026 Comparison & Alternative sets the traffic-control category beside this one, and Enterprise Browser or Render-Layer Tokenization? takes up the difference between governing a managed device and governing the values a model reads. The scope is the rendered page: a terminal, an IDE, a local file, a direct API call and MCP traffic are outside it.
What the record shows
What a model holds is decided where the page is rendered, and a kill switch decides only what happens after. The pages reviewed document five responses to a risky action, enforcement through gateways, hooks, SDKs and APIs, a human-in-the-loop option that names no person, and observability over prompts and tool calls. Each answers the action question, and none of them changes what the payout page rendered before the agent submitted. The research record adds the reason: adaptive attacks beat most published defenses, web agents tend to read more than the task needs, and the safest setup removes one of the three properties that make an agent dangerous. Run that test on one payout page: let the agent read it, stop the run before it submits, and read the model's context for the values it already holds.
Methodology and limitations
This page rests on four Noma Security pages, one WitnessAI post, three research papers and Harvard's guidance. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 16, 2026 and October 23, 2026, and each Sources line carries the date for its page.
The products on this page are described from their documentation, and none was tested for this page. "Not described in the pages reviewed" means the recorded facts for that page do not contain it. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a payout change on a merchant dashboard, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Does Noma Security's kill switch stop a leak that already happened?
No. The AI-DR page lists five responses to a risky action, a killswitch among them, and the runtime page evaluates tool calls, responses and session context. Those are the agent's actions and the traffic around them. The page the agent read was rendered before that evaluation, so the value is already in the model's context. A kill bounds the next action and cannot remove what the model received.
What does the kill switch stop, and what does the model keep?
The next request. A killswitch is one of five responses, and each one acts on an action the agent attempts: a payment, a deletion, a submission. The model keeps the context it built from the pages it read, and any later request it composes can include those values. Stopping the request protects the destination, while the transcript, the summary and the next allowed call still hold what the page showed.
Where does Noma inspect, and does it read the screen?
On the path a deployment routes through. Noma applies policy through supported gateways, hooks, and APIs, and the runtime page names AI gateways, MCP gateways, agent hooks, agent SDKs and direct APIs. Each sees a request the agent composed after reading the page. None of the four Noma pages describes replacing a value on the screen before the model reads it, so the inspection covers the request and not the read that produced it.
Does masking sensitive data inline protect the page the model read?
No. Masking is applied to the traffic that crosses the integration, which is the request or the response around the model call. The page was drawn in full and read before that request existed. Masking can stop a value leaving through the inspected path, and it leaves the value in the context the model built. The two controls answer different steps, one the transfer and one the read.
Who approves the action when Noma routes it to a human, and what record names them?
The pages reviewed do not say. "Get a human in the loop" is one of five responses, and the AI-DR page does not name the person, the action they review or where the decision is written. Agent Access Control describes policy applied through gateways, hooks and APIs. An approval that is not tied to a named person and a record is a routing option, and a buyer should ask for both in writing.
What would change the answer?
Values replaced on the rendered screen before any model reads it, with consistent tokens for the run and real values released only at an approved destination. A named person approving each payout change, and a record that shows the tokenized screen next to the action and the approver. That is the control class the title's question needs, and it is the one thing a kill switch cannot supply after the read.
How RedactSure Keeps the Bank Account Off the Payout Page
The agent reads the payout page before any control sees its request, and a kill at the request cannot remove the account number from context. Noma's AI-DR page lists a killswitch as one of five responses, a control on what happens next (Noma Security, Detection, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent reads the payout page with the account number in full and holds it when the request is killed. Inside, the page is drawn with PAYOUT_001 in that field, and the real number reaches the payment file when a named person approves the change.
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
A kill switch bounds what an agent does next; it cannot undo the page the model already read. Bring one payout task and see, with test values, what the model reads and where the real value lands. Book a demo