Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Cursor Approved for Use at Banks and Insurers?
No, not on Cursor's own documentation: each bank or insurer grants the approval, and their boards ask the same three questions. Cursor publishes its approvals, tool limits and ignore file, so check what its pages say about what the model reads, what the agent can run and what record survives the run.
A claims platform team asks its insurer's AI review board for Cursor and describes one workflow: an agent opens a claim, reads the reserve history and drafts a summary note for the adjuster. The board's answer turns on three things the request does not mention: what reaches the model when the claim screen renders, what the agent can run without a person in front of it, and what record exists afterward for an examiner who reads the file a year later. A bank's model risk function asks the same three questions in the same order.
Cursor's documentation answers part of that. It states that terminal commands need a person's approval by default and that every MCP connection needs one before it opens, and it describes an ignore file that keeps listed code away from the agent (Cursor, Security, 2026; Cursor, Ignore files, 2026). Those are controls on what the agent does and on which files it can reach. None of them changes what a browser page shows the model when the agent opens a claims screen, which is the board's first question and the one the tool leaves to the firm.
Key findings
- For Cursor to clear a claims screen review, the values on that screen would have to be replaced with consistent tokens before any model reads it, so the agent works with CLM_004821 and the real claim numbers resolve only at an approved destination (What Is an AI Control Record?).
- It would also require a named person approving each action the agent takes on that screen, and a record of what the model received that the firm can export and query (What Is Supervised Delegation?).
- Cursor's documentation covers the agent's actions and its repository access and stops at the screen: the pages reviewed describe no audit record of what the model read and no isolation of a credential from the model's context (Cursor, Security, 2026).
- Cursor's agent security page states that "By default, terminal commands need your approval" and that "All MCP connections need your approval," so the decision sits on a command rather than on a value the model has read (Cursor, Security, 2026).
- The ignore-files page states that the terminal and MCP server tools "cannot block access to code governed by .cursorignore," and that complete protection "isn't guaranteed due to LLM unpredictability" (Cursor, Ignore files, 2026).
- A measured study of web agents found that they "are prone to inadvertent use of unnecessary sensitive information," which on a claims screen means the name, policy number and reserve are read with the task (Zharmagambetov et al., 2025).
What does an insurer's review board ask before it approves Cursor?
The request that reaches the AI review board is usually narrow. A claims platform team wants Cursor for one job, opening a claim, pulling the reserve history and drafting a summary note, and it asks for the tool rather than for the workflow. The board turns that into three questions, the same three at a bank: what reaches the model when the agent opens the screen, what the agent can run without a person, and what evidence exists afterward.
The first question is the one a vendor's pages answer least. A claims screen renders the claimant's name, date of birth, policy number, the reserve and the notes an adjuster typed, and an agent asked for a summary reads the page it was given. Cursor's documentation describes approvals, tool limits and an ignore file, and no control over the values the page puts in front of the model.
The companies that sit on those boards disclose little about agents themselves: of the 42 largest US insurers whose latest annual reports were read, none describes using AI agents and one names AI agents among its risk factors, so the filings are no guide to what an institution has already approved (How Many Large Companies Are Warning Their Investors About the Risks of AI?).
The regulatory frame sets the standard of proof rather than the answer. The NAIC publishes a model bulletin on the use of artificial intelligence systems by insurers, with an adoption map that shows where states have taken it up (NAIC, 2025), so a board that files an approval writes something an examiner may read years later. The same limit applies to any agent an insurer puts on a claim file (Can Insurers Use OpenAI Dots on Claim Files?).
What can a Cursor agent run, and what does the approval cover?
The approval model is the part of Cursor's documentation a review board can read quickly, and it is specific. The agent security page states that "By default, terminal commands need your approval" and that "All MCP connections need your approval," which puts a person in front of a command and a connection, and it states that "AI can behave unexpectedly due to prompt injection, hallucinations, and other issues" (Cursor, Security, 2026).
What the approvals cover is the agent's actions. A command that runs after approval can still read a file, call an API and print the response into the session, and the value is in the model's context from that moment. The page does not say how credentials are stored or protected, and it describes no record of what the model read.
The repository has its own boundary and its own limit. The ignore-files page states that Cursor blocks files listed in .cursorignore from "Code accessible by Agent, Tab, and Inline Edit" and from "@ mention references," and that the terminal and MCP server tools "cannot block access to code governed by .cursorignore" (Cursor, Ignore files, 2026). A file exclusion is a boundary on code access, not on a browser page.
An approval on a command answers whether the agent may do a thing; a record of what the model read would answer what it saw before it asked (Does a Coding Agent Need Approval Before Using a Credential for the First Time?). The same distinction decides whether a credential can be used without being read (Can a Coding Agent Use a Credential It Cannot Read?).
What do the vendors themselves say?
Three vendor documents bear on the question, and none of them is a control on what a screen shows.
Cursor's agent security page carries the approval defaults (Cursor, Security, 2026), and its ignore-files page carries the repository boundary, with the sentence that complete protection "isn't guaranteed due to LLM unpredictability" (Cursor, Ignore files, 2026).
Infisical's design note for an agent credential proxy takes the opposite starting point: "the agent should not be trusted with direct access to any secrets," the premise a review board applies when it asks where a credential sits (Infisical, 2026).
A 2026 preprint complicates the filtering answer. It reports that a "simple, modular, and model-agnostic defense operating at the agent-tool interface" achieves "perfect security with high utility across all four public benchmarks," and the same abstract says existing benchmarks "are easily saturated" (Bhagwatkar et al., 2026).
| Dimension | Cursor, per its documentation | What a buyer should verify |
|---|---|---|
| Approval before an action | "By default, terminal commands need your approval"; "All MCP connections need your approval" (Cursor, Security, 2026) | Whether it covers a command that reads a claims screen |
| Repository access | Listed files blocked from "Code accessible by Agent, Tab, and Inline Edit" (Cursor, Ignore files, 2026) | Whether it reaches a rendered page |
| What the model receives | Not stated on the pages reviewed | Which values the model holds after the screen renders |
| Credential handling | No page reviewed says how a credential is stored | Where the credential lives and who can read it |
What record does a Cursor run leave, and what should a bank or insurer ask for in writing?
The examiner's question is not whether the agent behaved. It is whether the firm can show what the agent did, and who answered for it, months later. AWS's guidance for agentic systems states it plainly: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). An examiner reading an insurer's file under a model bulletin expects that link, and the file has to belong to the firm.
What a session leaves is a transcript and the repository's own history, which record the code rather than the reading, and the ignore-files page says nothing about a record of what the model read (Cursor, Ignore files, 2026).
So the written ask has two halves. Ask what the model receives from a rendered screen, and ask what the run writes: a record naming the screen, the values as the model saw them, the action and the approver, exportable to the firm's own monitoring. Cursor's pages address commands, connections and repository files, so the first half is open rather than answered (Cursor, Security, 2026).
Two answers are common and neither settles it. The first is a masking convention: the claims platform's guide states that "All SSNs initially display as XXX-XX-XXXX" until a user is assigned the rights to view them (Infinite Campus, 2026). A model that reads the page after an adjuster opens it sees what the adjuster sees.
The second is a refusal layer. MIT Technology Review reports that "the mechanisms of refusal are probabilistic" and "never likely to be all that reliable," because determined miscreants "have already broken through" (MIT Technology Review, 2026). A control that fails some of the time is still worth having; it is not what a board signs its name against.
A model risk function reads a file rather than a run, and the file needs fields: which screen, which values, which action, approved by whom, at what time (Which SOC 2 Controls Apply to Coding Agents That Hold Credentials?).
What does a governed environment change?
A governed environment is a control class that acts where a page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works with CLM_004821 where the claim number sits and a token where the claimant's name sits, while the screen keeps its shape so the agent can still find the reserve and the note. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the policy and approves each action that changes a claim, and every screen as tokens, every action and every approval is written to a record the organization exports to its own monitoring.
For this page's question it changes three things a review board can put in a file: the exposure question becomes answerable because the model received tokens, the approval question becomes specific because a person approves an action on a record rather than a command in a terminal, and the evidence question becomes an exported record.
Its scope is the rendered page, which is where a claims platform lives. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP, so a Cursor run that reads a repository file or calls an API is outside it, and the approvals and ignore file reviewed above remain the controls there.
The class is what the comparisons describe. RedactSure vs Cursor: 2026 Comparison & Alternative sets the two designs side by side.
What the record shows
Two readings decide the file: what the model received when the claims screen rendered, and what the firm can show afterward. Cursor's pages cover the actions around the reading, with a default approval on terminal commands and an approval on every MCP connection, and describe no record of what the model read (Cursor, Security, 2026). They do not answer the exposure question: an approval is granted before an action and after the page has been read, so the values are in the context before a person sees a prompt. That is why the review stalls at the same place at a bank and at an insurer. Name one claim, one screen and one agent, run the summary task as a test, and compare the screen it read with the transcript and with any record the firm holds. If the claimant's name is in the transcript, the reading was uncontrolled; if the transcript holds tokens, the exposure was bounded before the model saw it.
Methodology and limitations
This page rests on Cursor's agent security and ignore-files documentation, an Infisical vendor design note, two research preprints, the NAIC model bulletin adoption map, AWS guidance, an Infinite Campus knowledge base article and a press analysis, plus two RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 20, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested. Each is described from its documentation, "not described" means the pages reviewed, vendor features change and the page carries its date, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, a claims triage screen, and not an organization. Determinations about whether an approval satisfies a bank's model risk standard, an insurer's bulletin or a regulator's expectation belong to counsel and the organization's security and compliance officers.
Frequently asked questions
Is Cursor approved for use at banks and insurers?
No, not on the vendor's documentation, because approval is granted firm by firm. A bank's model risk function or an insurer's AI review board decides, and it needs three answers: what the model receives when the agent opens a screen, what the agent can run without a person, and what record survives the run. Cursor documents approvals on commands and connections and an ignore file for the repository, and it documents no record of what the model read.
What does Cursor's approval actually cover?
An action, not a value. The agent security page states that terminal commands need approval by default and that all MCP connections need approval, so a person sees a command or a connection before it runs. The page does not say how credentials are stored or protected, and it describes no step that limits which values a page puts in front of the model. An approved command that prints a response has already handed the model whatever that response contains.
Does .cursorignore keep a claims screen out of the agent's context?
No. The ignore file governs code access: Cursor blocks listed files from Agent, Tab and Inline Edit and from @ mention references, and its own page states that terminal and MCP server tools cannot block access to code governed by that file. A claims screen is rendered in a browser rather than stored as a file in the repository, so no entry in that file reaches it.
What record does a Cursor run leave?
A transcript, and whatever the repository records. Cursor's pages describe approvals, tool limits and file exclusions and no exported log that ties a screen, an action and an approver together. An examiner working from a bank's model risk file or an insurer's bulletin samples the record rather than the run, so the fields matter: which screen, which values, which action, who approved it, and when.
Can a bank rely on model refusal instead of a control on the screen?
Not as the primary control. MIT Technology Review reports that the mechanisms of refusal are probabilistic and never likely to be entirely reliable, and that determined miscreants have already broken through. A refusal layer narrows what an agent will do with a page; it does not change what the page put in front of the model. Treat it as one layer beside a written answer to what the model receives.
What should the review board require before it approves the tool?
The screen question answered per workflow: what values the model holds after a claims screen renders, and whether they can be replaced with tokens before it reads. The approval question: which actions need a named person, and how that person sees the record. The evidence question: an exported record of screens, actions and approvals that the firm can query without the vendor's help. A tool that answers all three is ready for a pilot on test data.
How RedactSure Keeps a Claims Screen Out of the Agent's Context
An approval on a command still leaves the board unable to say what the agent read on the claim screen.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent opens the claim and the claimant's name, date of birth and policy number enter the model's context for the rest of the run. Inside the governed environment the screen renders CLM_004821 and a name token, the agent drafts the note on them, and a named person approves it before it posts. The record carries the tokens, the approval and the approver's name.
RedactSure is deploying now with enterprise and government customers. Cursor puts the approval on a command and an MCP connection, not on what the model read.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
An approval that cannot say what the agent read is the finding a review board writes down first. Bring one claim screen from your workflow and see, with test values, the page as the model receives it, the approval and the record. Book a demo