Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Noma Enough to Let AI Agents Work on Customer Records?
No, because Noma's documented control sits at the gateway, hook, SDK or API an agent's traffic crosses, so the model has already read the CRM record by the time a policy is evaluated there. Ask what the model receives from the rendered screen, who approves each record change, and what record of the run exists.
For a support organization, the question gets decided on a live customer record in the queue. An agent that opens a customer record to change an address reads the same page a person would: the name, the email address, the account number, the open ticket and the order history the CRM renders for that account. Everything the model needs to choose the record and compose the change is on that page, so the values are in its context before any tool call exists. Noma's pages put their control on the tool call and the response, enforced where the agent's traffic crosses one of its integrations, with sensitive data masked inline there. That governs what the agent does with the record and leaves the read itself unexamined, which is the difference between a control that follows the data and one that precedes it. A record that holds a bank account, a contact history and an open complaint is what a misdirected agent would copy first, and it is what the review has to protect first. A security review that stops at the action has not answered the question a customer record asks.
Key findings
- For Noma to be enough on those records, the values on the page would have to be replaced with consistent tokens before any model reads it, so the agent works CUST_014 and ACCT_001 and never holds the bank account (What Is Render-Layer Tokenization?).
- It would also require a named person approving each record change and a record of what the model received on each screen (How Can AI Agents Work With Customer Records Without Seeing the Actual Data?).
- Noma's runtime page does not describe replacing a value on a screen an application renders; it enforces policy through "AI gateways, MCP gateways, agent hooks, agent SDKs, and direct APIs" (Noma Security, Runtime, 2026).
- AgentDAM found that autonomous web agents "are prone to inadvertent use of unnecessary sensitive information," reading past the field the task needed (Zharmagambetov et al., 2025).
- The adaptive-attack study bypassed twelve published defenses with an "attack success rate above 90% for most," so a filter on the agent's traffic narrows the risk without bounding it (Nasr et al., 2025).
- Noma's AI-DR page lists five responses to a risky action, including "get a human in the loop," and does not name the person or where the approval is written (Noma Security, Detection, 2026).
What does Noma evaluate, and where does it sit?
Noma's runtime page describes what it evaluates: "tool calls, responses, and session context to detect risky behavior and enforce policy" (Noma Security, Runtime, 2026). It enforces policy at the paths an agent's traffic can cross, "AI gateways, MCP gateways, agent hooks, agent SDKs, and direct APIs," so the control sits on the traffic rather than inside the CRM that renders the record. The page does not say which path a deployment uses, and it does not describe replacing a value on a screen an application renders.
A customer account under a support queue shows the scope. The agent opens the record, reads the fields a support person would use, and decides to change the address. The tool call it composes carries the record identifier and the new address. Noma evaluates that call, the response and the session context, and can block, steer or alert a human while masking sensitive data inline, a control on the call and not on the page that produced it. The account number and the notes on the open ticket were in the model's context when it chose the call, and the page describes no step that kept them out.
Agent Access Control adds a finer scope on the same action: "Access to a tool should not mean access to every operation it supports," which limits what an agent may do with a tool and not what a permitted action carries to the model (Noma Security, Access Control, 2026).
What does the model read before Noma sees the action?
The CRM serves the account page as markup a person's browser would receive: name, email address, phone number, account number, balances, and ticket text. The model reads that page to learn which record it has and what to change, and the values are in its context from the first token of the task. The tool call Noma evaluates is composed after that read, so inspection of the request sees the consequence of the exposure and not the exposure itself.
A wider review of 86 AI security and data protection products found 28 describing model-input controls or masking, none describing tokens an agent can use on a screen (How Many AI Security Products Control What an AI Agent Sees?).
The OpenShell integration post describes the same order in a forwarded request. "Noma inspects the full request, including the prompt, any tool calls and their parameters, MCP traffic, and payload data" (Noma Security, OpenShell, 2026).
AgentDAM's evaluation is the research version of the point: the agents tested "are prone to inadvertent use of unnecessary sensitive information," collecting values the task did not need (Zharmagambetov et al., 2025). Siddiqui and colleagues show what follows from a read that carries such data: "poisoned data retrieved from one component can change the model's behavior and compromise the entire system," including coercing the model to spread confidential data to untrusted components (Siddiqui et al., 2025). A record in context can be used by the next action, and the next action may not be the one the policy was written for.
What do the vendors themselves say?
The runtime page says "Noma evaluates tool calls, responses, and session context to detect risky behavior and enforce policy," and that "Risky actions can be blocked, steered, or alert a human, while sensitive data is masked inline" (Noma Security, Runtime, 2026). The AI-DR page lists five possible answers, "block an action, mask sensitive data, steer the agent towards a different path, get a human in the loop, or trigger a killswitch," and says neither which applies to a deployment nor who the human is (Noma Security, Detection, 2026). Glean makes the same claim about actions: "Glean enforces permissions for every action an agent takes," which covers the action and not what the page showed the model (Glean, 2026).
| Dimension | Noma, per its documentation | What a buyer should verify |
|---|---|---|
| Where the control sits | "enforce policy through AI gateways, MCP gateways, agent hooks, agent SDKs, and direct APIs" (Noma Security, Runtime, 2026) | Which path the deployment uses, and whether a rendered record crosses it |
| What it evaluates | "tool calls, responses, and session context" | Whether the evaluation runs before or after the model has read the record |
| What the model receives | The rendered page as the CRM serves it; masking inline, not substitution on the screen | One page shown exactly as the model read it |
| Who approves a change | "get a human in the loop," one of five possible responses | A person's name and where the action is recorded |
| The record | "complete observability into every prompt, tool call, response, and interaction" | Whether the record holds the values the model read |
What should a buyer ask for in writing?
Does the model receive the page as rendered, with values replaced before it reads? A yes describes substitution at the screen; a gateway, hook or API describes a control on the path, and a browser session that renders a record does not cross that path unless the deployment routes it there. The distinction is set out in Enterprise Browser or Render-Layer Tokenization?, and What Is the PII Wall? describes why agent projects stop at the records that matter.
Who approves each record change, by name, and where is the approval held? Noma's AI-DR page offers "get a human in the loop" among five responses and does not state who that person is, what they approve or where the approval is recorded (Noma Security, Detection, 2026).
What does the record of the run contain? A record of prompts and responses holds the values the model read unless the screen was tokenized first, and that record becomes a second copy of the customer's data for anyone who can open it. The same test applies to another agent on the same record type, as How Do You Protect Customer Data When Dynamics 365 Copilot Agents Work CRM Records? asks.
FINRA's 2026 oversight report itself warns that "AI agents acting autonomously without human validation and approval" and that "Agents may act beyond the user's actual or intended scope and authority" (FINRA, 2025).
What does the record show after the run?
The AI-DR page promises "complete observability into every prompt, tool call, response, and interaction," a record of what the model received as well as what it did (Noma Security, Detection, 2026). That breadth is useful in an investigation: an analyst can see the prompt that carried the record, the tool call it produced and the response that came back. It also means the record is where the customer's values live when the screen was served in full, so the audit trail inherits the exposure it documents.
The approval side is thinner. The same page lists "get a human in the loop" as one of five possible responses and does not say who that person is, what they approve or where the approval is kept. A reviewer asking why an address changed needs a name against that change. That separation is now the difference between an audit trail and a second copy of the record.
A record that keeps the two apart is what (How to see exactly why a security policy blocked an action?) describes: a decision with identifiable inputs, recorded so the reasoning can be shown. For a customer record, the inputs include the screen the model read, which is why such a record has to hold the page as tokens rather than the page as served.
What does a governed environment change?
A governed environment moves the control to the render. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the agent works CUST_014 and ACCT_001 for the whole run, and the real account number resolves only at an approved destination at the moment of an approved action. A named person approves each record change, and every screen the model read, every action and every approval land in an exported record.
The difference from a control on the traffic is where the decision falls. A gateway, hook or API can judge the call an agent has already composed, which is why inline masking there protects the payload and not the read. A governed environment decides what the model may see before the page reaches it, so the values are never in the context that an injection, a confused agent or a later action could draw on. For a customer record, the name, the account number and the ticket notes arrive at the model as tokens, and the change is approved against a record that never held them.
The difference between a control on the action and a control on the screen is set out in (RedactSure vs Noma Security: 2026 Comparison & Alternative), which quotes the same vendor pages this page does.
What the record shows
A control on the action and a control on the screen answer different questions. Noma evaluates the tool call, the response and the session context, with masking inline at the integration the traffic crosses, and its pages describe policy on what the agent does rather than on what the rendered record put in front of the model. On a CRM customer account that means the name, the email address and the account number reach the model in full, and the proposed change is judged afterwards. A reader can check this by running one agent against one test record, exporting the prompt and the tool call it produced, and comparing the values in that prompt with the values on the page the CRM served. The values that appear in both are the ones the control did not cover.
Methodology and limitations
The page rests on Noma Security's runtime, access-control and AI-DR pages, its OpenShell post, Glean's agent-governance page, FINRA's 2026 oversight report, and three research papers, read between October 16, 2026 and October 23, 2026. Public documentation read in full gives a sound view of where each product applies its control. The record scenario is a CRM customer account, a record type rather than any organization's system.
None of the products on this page was tested for this page, and "not described in the pages reviewed" means the recorded pages do not cover the point. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. Compliance determinations belong to the organization's counsel, its assessors and its security officers, and nothing here replaces a pilot on the organization's own screens.
Frequently asked questions
Is Noma enough to let AI agents work on customer records?
No. Noma's pages describe evaluation of tool calls, responses and session context, with risky actions blocked, steered or alerted and sensitive data masked inline at the integration, a scope on the call and not on the page the model read (Noma Security, Runtime, 2026). None of that changes what the CRM page put in front of the model before it composed the call. The answer would change if a page documented substitution on the rendered record before the model reads it, which the runtime page does not describe.
Does Noma see the CRM page the agent reads?
Only what reaches its inspection point. Where traffic crosses a gateway, a hook, an SDK or a direct API, Noma can inspect the prompt, the tool calls and the response, and the OpenShell post describes inspection of the full request (Noma Security, OpenShell, 2026). A page rendered in a browser session the agent drives does not necessarily cross one of those paths. What the model read before the request existed is outside that view.
What does Noma receive from the screen the agent works in?
Nothing directly from the screen. Noma's control runs on the traffic, and its pages describe evaluating tool calls and session context rather than the rendered page an agent reads (Noma Security, Runtime, 2026). Where an organization routes the model's calls through an integration, the prompt shows what the page contributed, but that is a copy of the read and not a control over it. The page a browser renders stays outside the inspection point.
Who approves a customer record change under Noma?
No named person is described. The AI-DR page lists "get a human in the loop" among five possible responses to a risky action, and it does not state who that person is, what exactly they approve or where the approval is recorded (Noma Security, Detection, 2026). A deployment may attach its own workflow to that option, and the vendor's pages neither describe one nor rule one out. A reviewer needs the name and the record.
What does Noma's audit record contain?
The AI-DR page promises "complete observability into every prompt, tool call, response, and interaction" (Noma Security, Detection, 2026). That covers what the model received and what it did. It also means the record holds the customer's values when the screen was served in full, so the audit trail carries the sensitivity of the record it documents. Whether the values were tokenized before the read decides what the log can safely hold.
What would make Noma enough for this work?
Two things, both about the read. The values on the rendered record would have to be replaced with consistent tokens before any model reads it, and a named person would have to approve each change with the approval recorded against the action. Noma's documented strengths, policy on the tool call, inline masking and observability, would then apply to an agent that never held them, with the read itself outside its control. Until a page describes that substitution, the control follows the data.
How RedactSure Keeps a Customer Record Out of the Model's Context
A customer record is read in full before Noma evaluates the tool call that follows, so masking at the gateway changes what leaves, not what the model learned. Its runtime page puts the control on the call and the response.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before the run, the model receives the customer's name, email address, account number and open ticket from the rendered record. Inside, the same record arrives as CUST_014 and ACCT_001, and the real account number resolves only at the CRM's approved destination when a named person approves it.
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 review that asks what the model read, as well as what it did, is the one that holds up later. Bring one customer record and see, with test values, what the model reads and where the real account number lands. Book a demo