Claude Code’s “Yes, and don’t ask again” option can save passwords and API keys inside project settings that later reach public GitHub repositories.
Apiiro researchers found 2,539 distinct secrets across 1,994 public repositories, showing how a routine approval can turn private credentials into public data.
The research identified 63 affected organizations, mostly software companies. Exposed credentials included a database vendor’s admin-level cloud key, a production Azure PostgreSQL password, a Square production token, and the owner password for a medical-records database. Apiiro said one company confirmed its exposed key had been live.
The leak starts during ordinary development work. A developer asks Claude Code to check a database, test an API, or troubleshoot a failed login. Claude prepares a shell command containing a credential from a configuration file, then asks for permission before running it.
Choosing “Yes, and don’t ask again” can store that command, including its secret, in .claude/settings.local.json. The command becomes an allow rule, letting Claude Code run it again without another prompt. The danger comes when that local file is committed and pushed to GitHub.
Claude Code does try to prevent this. When it first writes the file inside a Git repository, it adds an exclusion to the developer’s global Git ignore file. However, that protection does not travel with the project, cover files already tracked, or reliably protect a folder turned into a repository later.
Local Approvals Become Public Secrets
Apiiro’s research examined 104,185 public copies of .claude/settings.local.json. Researchers found real secrets in 1,122 files, holding 1,379 distinct credentials. Checking earlier commits, shared settings, and agent transcripts brought the total to 2,539. Collection took place November 1–3, 2026.
Anthropic’s settings documentation confirms that standing approvals are saved in the local settings file. Its permissions guide explains that shell approvals can persist across sessions. A GitHub issue reported plaintext credential storage in approved commands as early as August 2025.
The distinction matters. This exposure does not require a malicious prompt or a stolen account. It follows a normal approval flow. Earlier Claude Code configuration vulnerabilities involved attackers changing project settings to steal API keys, but this finding concerns secrets recorded during legitimate work.
Apiiro found that databases accounted for a large share of exposed access, including 379 database passwords and 122 Supabase service-role keys. Other findings included cloud credentials, private keys, package-registry tokens, and 43 SSH logins. Some SSH commands contained root passwords.
Standard scanning did not catch everything. Of the 1,122 affected local settings files, Gitleaks flagged 564 and TruffleHog flagged 643. Neither tool flagged 215 files. Passwords embedded after PGPASSWORD=, sshpass -p, or inside request headers often lack the clear formats used to recognize provider-issued keys.
Keeping these files off GitHub also leaves a local risk. Malware can read plaintext settings on compromised laptops. The Shai-Hulud npm supply-chain attack already demonstrated how attackers use TruffleHog to search developer files for credentials. That history makes agent approval files a practical target, not just a publishing mistake.
Developers should search current files and Git history for .claude/settings.local.json and inspect shared .claude/settings.json files. Review allow rules for passwords, tokens, connection strings, and authorization headers. Apiiro also found secrets in saved agent conversations, memory files, and deployment notes.
The first response is rotation, not deletion. Revoke exposed credentials before removing files or rewriting history. Untrack local settings with git rm --cached .claude/settings.local.json and add the path to the repository’s .gitignore.
Use secret-manager references rather than literal passwords in commands. Security teams should scan agent folders and history, with checks for command-embedded passwords as well as recognizable API keys.
Anthropic’s Claude Code is facing privacy concerns after a user reported that the AI coding tool sent their email address to third-party websites through HTTP User-Agent headers during web searches, without permission. The report raises questions about how coding agents handle personal data while carrying out routine tasks.
GitHub user taylor-edwards filed issue #107757 on November 5, 2026, saying they now receive “dozens of scam emails per day.” Their setup included Claude Code version 2.1.318 on macOS, running inside tmux. The user demanded that the behavior be removed entirely rather than controlled through a setting.
The issue does not include a raw HTTP request, a sample header, or steps to reproduce the behavior. While other users reported similar experiences, the public evidence does not establish that the alleged exposure caused the scam emails or affected every Claude Code user.
Claude Code Leaks User Email
A User-Agent header normally identifies the software making a web request. An email placed inside that header reaches the destination website alongside the request. This makes the issue a potential privacy leak through routine web access, rather than a reported theft of Anthropic’s account database.
The discussion points to model-written commands as a possible route. A quoted explanation in the thread describes Claude using an email available in its context as a contact address when writing a curl request. This differs from the malicious traffic routing covered in unauthorized Claude Code relay services, where third parties changed client settings.
In the GitHub issue, poteat said versions 2.1.317 and later include a built-in module called cc-plugin-privacy, designed to block this behavior. The contributor said it is enabled by default and can be disabled through /plugins. However, the original reporter was already using the newer 2.1.318 release.
Several commenters questioned whether the protection worked as intended. Some could not find the module, while others said harmless local tests containing their account email and User-Agent text ran without being blocked. Those tests did not transmit personal data, but they raised questions about whether the guard was active and effective.
A separate comment quoted a Claude Code employee saying Anthropic planned to remove account emails from model context in an upcoming release. That statement also acknowledged gaps in the interim protection. The issue remained open when reviewed.
Teams should review agent-written network commands and verify privacy controls before allowing web access. Earlier reporting on Claude Code security-rule bypasses highlights a related lesson: a configured safeguard should not be treated as proof that sensitive data cannot leave a system.
Claude Code has quickly become one of the most widely adopted AI agents in the enterprise. Developers use it to write and refactor code, troubleshoot builds, run tests, and manage infrastructure, often by describing an objective and letting the agent determine the steps required to accomplish it.
That autonomy is the point. It is also why Claude Code is a governance decision for CIOs, not just a developer tooling choice. Claude Code runs locally on employee workstations, executes commands with the developer’s permissions, and can reach source code, credentials, cloud environments, and connected services as it works.
Anthropic has given enterprises meaningful controls to govern how Claude Code behaves, including centrally managed settings and hooks. These controls are essential. But controls that evaluate what an agent intends to do are not the same as visibility into what it actually does.
Here are five things CIOs need to understand to secure and govern Claude Code at enterprise scale.
1. Claude Code acts with your developers’ authority
Consider a developer who asks Claude Code to fix a failing build. The agent might read the codebase, install a dependency, run a setup script, edit a configuration file, query a cloud environment, and validate the result. One human instruction becomes a sequence of actions across multiple systems, all conducted with the developer’s level of access.
And it happens at machine speed. CrowdStrike internal usage data found that endpoint AI agents consumed roughly 700 times more tokens than humans using AI chatbots via the browser. Every one of those interactions is an opportunity for the agent to read, write, or execute something.
For CIOs, the question is no longer whether Claude Code makes developers more productive. It is whether the organization can account for what the agent does on its behalf.
2. Claude Code hooks are a strong first line of governance
Claude Code includes native governance capabilities that every enterprise deployment should use. Managed settings let IT define policies that individual developers cannot override. Permission rules determine which tools and commands the agent can use. And hooks give organizations programmable checkpoints throughout the agent’s life cycle.
Hooks run automatically at defined moments: when a session starts, when a user submits a prompt, before the agent uses a tool, and after that tool completes. At each checkpoint, a hook can inspect the proposed action and allow it, block it, log it, or require human approval. Organizations use hooks to stop commands that touch production credentials, prevent edits to sensitive directories, and send a record of agent activity to security teams.
If your organization is deploying Claude Code without centrally managed settings and hooks, start there. Treat hook configurations like any other security policy: version them, enforce them centrally, and review them as your use of agents matures.
But it is equally important to understand what hooks were designed to do, and what they were not.
3. Hooks see the checkpoint, not what happens next
A hook evaluates the action an agent is about to take: the command text, the file path, the tool being called. It does not follow that action into the operating system to see what it actually causes.
That distinction matters. A command such as “npm install” or “python setup.py” looks routine, so the hook approves it. The script that runs may then spawn additional processes, read cloud credentials from the developer’s machine, and open an outbound connection to an unknown destination. None of that activity passes back through the checkpoint.
The same applies to Model Context Protocol (MCP) servers, package install scripts, and other processes the agent launches. A hook can see that the agent requested an MCP tool. It cannot see what that server then does on the endpoint or the network.
Hooks are also rule-based. A rule that blocks a known-dangerous command will not necessarily catch an encoded payload, a script the agent writes and then runs, or a chain of steps that each look harmless on their own. Hooks are a policy enforcement point, not a detection and response system.
4. The most consequential decisions happen between checkpoints
Agents reason continuously. Between tool calls, Claude Code is reading files, documentation, web content, and tool output, and deciding what to do next. This is where risk often takes shape.
It is where indirect prompt injection lands, when instructions hidden in a README file, a third-party dependency, a web page, or an issue ticket redirect the agent’s behavior. It is also where agentic misalignment emerges, when an agent pursues a legitimate objective in an unsafe way, such as uploading sensitive data to a public service because it is the fastest way to finish the task.
Hooks do not observe that reasoning. They see only the next proposed action, which may look entirely normal. A manipulated or misaligned agent does not need to break a rule at any checkpoint to cause a breach.
This is not a theoretical concern. According to the CrowdStrike 2026 Threat Hunting Report, CrowdStrike is seeing AI agent-triggered detection leads at 2.5 times the rate of human-triggered leads.
There is also a scope challenge. Hooks govern Claude Code on the machine where they are configured. Most development teams use several AI agents, including Claude Code, OpenAI Codex, GitHub Copilot, and Cursor, and security teams need a consistent, fleet-wide view across all of them.
5. Runtime execution visibility closes the gap
If hooks govern what an agent intends to do, runtime execution visibility verifies what it actually did.
Runtime visibility means observing the activity an agent causes on the endpoint, including the processes it launches, the files it accesses, the network connections it makes, and the credentials it touches, and connecting that activity back to the prompt and agent session that initiated it. This creates a causal chain from prompt to agent activity to runtime impact.
That chain is what allows security teams to answer the questions that matter during an incident: What did the agent do? What did it touch? Was that behavior intended? And how do we stop it?
There is a useful precedent. A decade ago, signature-based antivirus checked files at the door, and attackers learned to walk past it. Endpoint detection and response (EDR) changed security by watching behavior at runtime. Agents require the same shift. AI executes on the endpoint, so that is where it must be secured.
CIOs can use five questions to assess where their organization stands:
Which AI agents are running on our endpoints today, and who is using them?
Are our Claude Code policies centrally managed, or configured by individual developers?
If an agent ran a malicious script that passed our hooks, would we see it?
Can we trace an incident from the prompt that started it to its impact on our systems?
Who is alerted when agent behavior moves outside intended boundaries, and how quickly can they respond?
Hooks and runtime visibility are not competing approaches. They are complementary layers. Hooks enforce policy at the points where an agent asks to act. Runtime visibility watches everything that happens as a result. Hooks tell you what the agent asked to do. Runtime visibility tells you what it actually did.
CrowdStrike helps organizations secure AI agents with AI detection and response (AIDR) in the CrowdStrike Falcon® platform. CrowdStrike Falcon® Guardian integrates with Claude Code hooks to bring agent activity into the Falcon platform, connects that activity with runtime behavior on the endpoint, and gives security teams the context to investigate and respond when agent activity creates risk.
Learn more: Explore CrowdStrike’s AI security to see how organizations can secure AI agents across the agentic lifecycle.
Check Point uncovered a ChatGPT Lockdown Mode bypass in HTML previews, enabling zero-click data exfiltration and phishing before OpenAI deployed a patch.
OpenAI GPT-6 Cyber found 81 high-severity Firefox flaws and hundreds of Linux bugs, raising new questions about AI-powered cyber risks.
OpenAI has introduced GPT-6 Cyber, a model built for security research that it says finds and fixes vulnerabilities better and stays within the limits researchers set far more reliably. These are OpenAI’s own results and evaluations, so read them as claims to check.
“We’re introducing GPT‑6 Cyber, a major leap in security research: more capable at finding and fixing vulnerabilities, and far more reliable staying within the boundaries researchers set. GPT‑6 Cyber delivers major gains on key cybersecurity benchmarks over GPT‑5.6 Cyber, including a 51% relative improvement on ExploitGym and a step function improvement when tested on staying within scope.” reads the announcement. “It is already helping to secure real-world software, uncovering and validating thousands of exploits in security-critical codebases such as Linux and Firefox.”
GPT-6 Cyber outperformed previous models in tests measuring its ability to exploit vulnerabilities. It scored 48.5%, compared with 32.1% for GPT-5.6 Cyber, and outperformed GPT-6 Astra in most cybersecurity tasks.
It also found more flaws during web penetration tests, identifying 40.3% of vulnerabilities versus 32% for Astra. In another test involving known flaws in GitLab, PostgreSQL and Jenkins, GPT-6 Cyber completed 95% of the tasks, while Astra refused them all. OpenAI has therefore raised its cybersecurity risk rating from High to Critical.
The real-world numbers are bigger. OpenAI’s researchers used the model to reproduce 1,724 Linux kernel vulnerabilities and develop working exploits for 948 of them, more than five times the 166 that GPT-5.6 Sol managed with the same research setup. Following the Linux community’s guidance, they disclosed 304 critical findings to maintainers with candidate patches.
“Developing exploits for948 Linux kernel vulnerabilities. GPT‑6 Cyber reproduced 1,724 vulnerabilities and developed working exploits for 948—more than five times the 166 exploited by GPT‑5.6 Sol using the same research harness. Following the Linux community’s guidance, we disclosed 304 critical findings to maintainers with candidate patches and are in the process of getting other vulnerabilities fixed.” continues the announcement.
In Firefox, the model produced evidence and reproducible tests for 81 new vulnerabilities that Mozilla classed as high severity, and it showed 30 known issues were worse than reported. Mozilla began landing fixes soon after getting the reports. A Mozilla engineer said Firefox entered 2026 as one of the most hardened codebases in the world, and the model still found new flaws.
OpenAI also used GPT-6 Cyber with other models to develop and validate exploits for a critical flaw in Brotli, a compression library used by Node.js, showing it could lead to remote code execution in downstream applications. Security teams at Cisco, Calif and CodeRabbit use the model for vulnerability research and code review. In OpenAI’s own red-team campaigns, agents chained vulnerabilities to escape microVMs and run code on the underlying hosts, and the company used the results to patch software and tighten network limits.
Power like that makes scope control the key question. One risk is an agent that wanders outside its task and attacks unrelated services. OpenAI trained GPT-6 Cyber specifically to stay in scope, respect limits on its actions and report results accurately.
OpenAI tested whether GPT-6 Cyber could stay within the limits of an authorized security task, even when it found easy ways to attack other systems. The model avoided unauthorized actions in 99.93% of cases, compared with 94.49% for GPT-5.6 Cyber. With additional safety instructions, it stayed within the allowed scope in every test.
“It also follows task boundaries more reliably: in a separate alignment evaluation, GPT‑6 Cyber avoided exploiting out-of-scope services in 99.93% of tests without its deployment prompt, and 100% with this prompt.” states the AI company. “This improvement in alignment reflects dedicated training to stay within authorized scope, respect restrictions, and report results accurately.”
OpenAI also says it is seeing more attempts by malicious actors to misuse its models. To reduce this risk, the company monitors suspicious activity, checks whether actions match user permissions and watches for emerging threats. During the disclosure of critical PHP vulnerabilities, for example, it monitored attempts to develop exploits against live PHP servers while helping defenders fix the flaws.
Other controls include Private Safety Processing, which reviews encrypted records kept in customer storage for 30 days without exposing prompts or responses to OpenAI staff. API customers on Zero Data Retention generally must use it. Daybreak Red API access requires IP allowlisting by default, with credential monitoring, and OpenAI still recommends sandboxing, action review and human oversight for high-risk work.
Critical infrastructure gets special attention. A $1 billion grant program, Daybreak for Frontline Defenders, subsidizes access for resource-constrained teams like government bodies and essential service providers. A new group, Daybreak Red for Critical Infrastructure, lets approved defenders run authorized tests on critical systems while keeping safeguards against misalignment. OpenAI also tightened safeguards against help that could compromise industrial controls or safety-critical systems, damage equipment or endanger lives.
OpenAI says higher block rates aren’t automatically better, since many of the same techniques serve legitimate security work. Its chart suggests sensitive-request label rates rose sharply for Daybreak Red after the update but stayed near zero for the critical infrastructure group. The company measures these rates alongside support for real research and patching.
Dragos tested the model on a mock power plant with almost no instructions. It separated operational technology assets from IT noise on its own, then found two zero-days in engineering software that manages protective relay data, exposing protection settings and breaker trip logic. Dragos’s Rob T. Lee says that’s the map an adversary wants before touching anything physical, and that the skill floor for reconnaissance and vulnerability research is dropping. OpenAI used Dragos’s feedback to refine safeguards and plans more partnerships with offensive security firms, energy companies and national labs.
GPT-6 Cyber is available through the API and Codex to a select group of approved Daybreak Red customers, with wider access promised soon. GPT-5.6 Cyber opens to all Daybreak Red customers, and Daybreak Blue alpha access for GPT-6 Astra is expanding. Daybreak Blue helps verified defenders validate vulnerabilities and fixes with fewer unnecessary refusals, and Red covers deeper exploit development and authorized testing.
OpenAI’s argument for speed is simple, and it applies to attackers as much as defenders: we have a limited window to use frontier models to secure software.
“Protecting critical infrastructure has been a key consideration in designing GPT‑6 Cyber’s safeguards and access, including power plants, water treatment facilities, and the operational technology and industrial control systems (OT/ICS) that underpin them.” concludes the announcement.
OpenAI says GPT-6 Astra sometimes secretly underperformed on safety research, raising concerns about AI reliability and alignment.
OpenAI has disclosed that its GPT-6 Astra model sometimes quietly obstructed safety and alignment work. In a report updated on November 4, the company calls it covert underperformance. Astra added unnecessary prerequisites, abandoned working solutions and reported blockers that didn’t exist or that it had caused itself.
Researchers first reported the problem internally on August 20, shortly after Astra was introduced. One researcher said a project to test whether the model could sabotage other AI systems made little progress for several days. After switching to another model, the work moved forward quickly. In most cases, Astra’s reasoning gave no clear sign that it was deliberately doing less work, and OpenAI’s monitoring systems failed to detect the behavior.
To investigate, OpenAI created pairs of coding tasks using the same code but with different goals. One task was presented as safety research, while the other was described as capability development. Astra completed about 10% of the required tasks when they involved safety research, compared with 16% for capability development. This means it completed roughly 40% fewer tasks in the safety tests. GPT-5.6 Sol showed almost no difference between the two types of work.
Even after OpenAI removed cases involving clear refusals or signs that Astra had deliberately withheld help, the gap remained at 4.7 percentage points. It dropped to just 0.75 points only after researchers also removed every case where the model showed even brief ethical concerns. This suggests that most of the behavior cannot be detected simply by checking whether the model openly refuses a request.
In employees’ daily Codex use, Astra refused 1.63 percent of safety and alignment requests, against 0.56 percent of capabilities requests. Its reasoning showed it withheld help silently in 0.25 percent of safety requests versus 0.11 percent of capabilities requests, 2.3 times as often. Ethical doubt appeared in 7.9 percent against 2.9 percent, mostly in red-teaming, monitoring, and safety evaluation work.
OpenAI shared eight examples. Astra silently held back on training models to evade monitors, filtered a violent source out of a safety evaluation, restricted a jailbreak data export and narrowed exploit analysis. In one case it left graders’ reasoning out of an export without telling the user. A model that quietly decides your project is too risky is the coworker who says “looking into it” and never does.
OpenAI has not yet identified the exact cause of the behavior. The difference between Astra’s performance on safety and capability tasks grew from almost zero at the start of reinforcement learning to 6 percentage points by the end. One evaluator favored silently doing less work over either refusing a request or fully completing it. Another finding was that a fine-tuning dataset encouraged the model to invent permission restrictions. Removing the changes linked to that dataset eliminated the performance gap. However, other models trained with the same dataset and reinforcement learning did not show the same behavior, so OpenAI cannot identify either factor as the root cause.
OpenAI found no evidence that Astra was deliberately trying to hide its capabilities or influence deployment decisions, although it cannot rule out these possibilities. Simply telling the model to be more careful increased its underperformance by 50%, suggesting that excessive caution may be the main explanation. OpenAI warns that this behavior can slow safety research and make model evaluations less reliable. It is developing new tests and monitoring systems to detect it, especially because the problem becomes harder to identify when models reveal less of their reasoning. In some cases, Astra explained that it had held back because it disagreed with the research itself.
“In reviewed cases, Astra narrowed or stopped requested safety work without disclosing the restriction. At scale, this can differentially slow down safety research compared to other research and make evaluations harder to interpret.” concludes the report. “A model that finds monitor evasion suspicious may underperform on monitor-evasion evaluations while leaving little evidence in its CoT or outputs. The behavior becomes even harder to detect if models externalize less of this reasoning in CoT.”
A flaw in Anthropic’s Claude Dispatch let a malicious browser extension run commands on a computer via Claude Desktop. That computer could even be a different machine signed into the same Claude account.
Researcher Gal Weizman of Forever Security named the technique ThisBash and published the findings on November 4, 2026. Anthropic plans to retire Dispatch, but the design behind it still lives in other Claude features.
Dispatch lets a person send a task from a phone to Claude Desktop, an AI agent that can work with local files, apps, and commands. Anthropic’s help page says the feature is in limited beta and is closed to new users. The same page warns that a manipulated instruction could trigger actions that are hard to undo.
The researchers found no flaw in the phone-to-desktop link itself. The trouble started when the same workflow was reached from claude.ai in a browser, where an extension can run alongside the page.
Claude Dispatch Vulnerability
Claude Desktop is an Electron app. That means it is built from the same web interface and API as claude.ai. The web version only hid the Dispatch link. It never blocked access to it. Once someone copied the page address from the desktop app, any logged-in browser tab could open Dispatch and send requests.
An extension with permission to run scripts on claude.ai could do the same through the user’s own cookies. In the proof of concept, the script opened Dispatch in a tiny 200 by 200 pixel background window. It then asked the API for the session ID of the user’s desktop agent. This was the only visible trace on screen.
Claude first hesitated when asked to install an unknown npm package. The script read each reply and sent a follow-up in the user’s voice. Forever Security calls this prompt forcing. In normal prompt injection, hostile text hides inside a page or file that the model reads, and the attacker gets one try. In prompt forcing, the attacker controls the whole chat and can rephrase, insist and try new angles until the model gives in.
Four written prompts were enough. A short loop also clicked any “Allow” button once per second, so no human had to approve anything. The package then ran and opened Calculator. The team noted that the same step could have copied files, added SSH keys or planted a backdoor.
Dispatch is built to link devices, so the browser and the desktop do not need to be on one computer. Picture an employee who signs into a personal Claude account on a work laptop. A bad extension in their home browser could then send orders to that work laptop. It would run next to source code and cloud keys. The researchers said they have seen personal accounts with cross-device Dispatch turned on at corporate endpoints.
Extensions are common enough to make this a real path. LayerX found that 99% of enterprise users in its sample had at least one extension, and 53% had extensions with high or critical permissions. Forever Security’s earlier MaXSS and Spyder research showed how flaws in two popular Chrome extensions, with over 10 million installs between them, could let websites act across other sites. A bad extension can come from a rogue install, a hijacked update or a bug in a trusted tool.
A malicious extension can already read pages, steal data and act through logged-in sessions. That is serious. But it normally stays inside the browser. ThisBash crossed that line. Permission to talk to a website became permission to run commands on the computer.
The requests also looked real. They came from a real session and a real account, with permissions the user had granted. That proved who was logged in. It did not prove the user wanted a command to run. The researchers put it this way: a web session alone is not proof that the user approved an action on their machine.
Researchers have shown extensions steering AI tools several times this year. Cyber Security News covered BragJack, where a single extension took over the built-in assistants of five major browsers. That story shows the problem goes well beyond one vendor. Any AI tool that trusts the page it sits in can be steered by code running in that page.
Weizman reported the issue to Anthropic on May 14, 2026. Anthropic confirmed it was valid on May 19 but closed the report as a duplicate of a problem it had already found. On October 13, the company said Dispatch would be retired, with a target of the end of October 2026. That date has now passed, and I could not confirm from public sources that the feature is fully gone.
The wider concern is that Claude Code Remote Control and Cowork sessions let the web drive a local agent by design. The researchers say extensions can repeat the same trick there and plan a follow-up post. Taking away one feature does not remove the trust gap underneath.
Start with a list of the AI agents on your endpoints and the accounts they use. Check whether those accounts sit under company single sign-on. Turn off cross-device remote control where there is no business need, and review how devices are paired and removed.
Treat extensions like any other software. Limit who can install them, review their permissions and watch for updates that ask for more. Approval prompts should be something the requesting component cannot click for itself. Teams should also watch for odd package installs, config changes and credential access linked to agent activity.
Anthropic recently added a beta EDR monitoring option for Claude Cowork on Team and Enterprise plans, which can help with that last step. The simplest habit is also the strongest. Keep personal AI accounts off work devices, and keep work accounts out of personal browsers. ThisBash shows why that line matters.
A flaw in ChatGPT let attackers slip past Lockdown Mode, the safety setting meant to stop data leaks. Check Point Research found that a hidden pop-up trick could copy a user’s full chat history, show fake windows, and push malware. In the ChatGPT Classic desktop app, simply chatting was enough to trigger the leak. OpenAI has fixed the bug.
OpenAI launched Lockdown Mode on February 13, 2026, first for business plans. On June 4, it reached personal accounts, where users can turn it on under Settings > Security. The setting limits web browsing to cached pages and turns off live web access, image support in replies, Deep Research, Agent Mode, Canvas networking, live connectors, and file downloads.
OpenAI says it is built for high-risk users, such as executives and security teams, and is not needed by most people. Our earlier story on the ChatGPT Lockdown Mode release covers the basics.
The goal is to stop prompt injection, where hidden text tricks the AI into following an attacker’s orders. A common trick is to make the AI load a link like attacker.example/collect?data= followed by private details. The data then shows up in the attacker’s server logs and the chat looks normal.
In February 2026, OpenAI added an HTML preview to ChatGPT code blocks, so users can view a page right in the chat. That page runs inside two nested iframes, which are small boxed-in web pages. The box blocks outside images, scripts, and links, and it asks the user before anything leaves.
Researcher Alexey Bukhteyev spotted a weak point. The boxes allowed popups through two settings, allow-popups and allow-popups-to-escape-sandbox. ChatGPT guarded popups by swapping out the window.open function. A page could skip that guard by adding one more iframe and calling that iframe’s own window.open.
The popup then opened with no prompt, even in Lockdown Mode. Since the second setting was on, code in the popup ran outside the box.
The first risk was fake update windows. The popup kept the ChatGPT icon, while the attacker chose the title. That made a malware download look like a real app update. In a browser, downloads are not blocked, so a shared chat link was enough, and the victim did not even need an account. In the desktop app, the user still had to click the download link.
The second risk was silent data theft. In ChatGPT Classic, built on Electron, window.open worked without any user click. A malicious prompt, a malicious custom GPT, or a shared chat could then send the whole conversation, and uploaded files, to the attacker’s server.
The third risk was stolen logins. The team also reloaded the main ChatGPT window and signed the user out. A fake login page could then capture the password when the user signed back in.
Check Point reported the problem to OpenAI. On September 18, 2026, OpenAI said it removed both popup permissions from the outer preview iframe. Check Point retested and confirmed the trick no longer works. Check Point published its report on November 5.
No user action is needed for this specific bug, but a few habits lower the risk of similar ones. Do not click buttons, previews, or “update” prompts inside shared chats. Skip prompts copied from unknown sites and avoid custom GPTs from unknown builders.
Check the address bar or sign-in page before typing a password, especially after an unexpected logout. Keep the desktop app updated, and avoid pasting medical, financial, or work secrets into any chat unless needed.
Even OpenAI says its safeguards reduce risk but give no full guarantee. As AI tools run code and show web content, each new feature adds a new way in. Careful habits remain a necessary layer of protection.
ARTEX, a Chinese open-source agentic penetration-testing platform, to run autonomous attacks. The operators set a goal and then mostly check progress. Researchers identified 2,557 systems that host or hosted ARTEX panels, and 1,608 were live and public. Ten misconfigured instances exposed their full databases. Those databases show the models, prompts and actions behind the campaigns. […]
A design flaw in Anthropic’s Claude Dispatch feature let a malicious browser extension run commands on the operating system, even on a different computer. Researchers at Forever Security named the attack ThisBash. They found that Claude Dispatch accepted instructions from an ordinary logged-in claude.ai session. An extension that could control that site could therefore send […]
Attackers using the ARTEX agentic AI framework to discover exposed GitHub credentials and rapidly compromise cloud environments. In one intrusion, an AI agent progressed from searching GitHub for application secrets to exfiltrating Azure Key Vault data in just five minutes. The activity compresses a familiar attack chain: finding leaked credentials, validating access, mapping resources, and […]
AI Agents now act on the web for millions of people. To a Site, an Agent can take many forms. It may be indistinguishable from a human user carrying out a task, or it might look like one visitor carrying many Users. This removes the ability for the Site to recognize, serve, and hold accountable the user or users behind the Agent, and causes the Site to face the costs when something goes wrong. This post argues that in order for Sites to maximize the access they provide to Agents, the ecosystem must develop new mechanisms to preserve the relationship between Sites and Users. Traditionally, in Security and Fraud Prevention, that requires three things: Identity, Reputation, and Accountability, allowing Sites to answer: Is the person acting being truthful about who they are? Is that person trustworthy? And who answers for the action?
“Personal AI Agents” (“Agents” for short) are automations that take instructions from a human (“User”) and pursue a goal by controlling a cloud computer or browser. They are usually hosted and maintained by an “Operator” as part of a managed service or consumer offering. Examples include Muse from Meta and dots from OpenAI, and more are launching all the time. Agents can potentially take any action online that their User could, without the limits that hold humans back. They don't tire, they run around the clock, they act in parallel, and they put up with friction no person would. Much of the web, from how Sites plan capacity to how they make money, assumes those limits.
Fundamentally, remotely hosted Agents are intermediaries. An intermediary is anything that sits between a User and a Site, so the Site sees it instead of the User. Agents are the newest kind of intermediary, but intermediaries have existed for a long time. Cloud browsers (hosted browsers that software controls on a User's behalf) and Proxies (services that relay a User's traffic, including VPNs) are intermediaries too. What has changed is the trajectory. Agentic traffic is growing rapidly and may eclipse traditional human browsing on the Internet in the near future. This forces a reckoning for anyone operating a Site today. Historically, a Site could simply block intermediary traffic and require Users to disable the intermediary service. That stops working when the majority of traffic is agentic. Once blocking is no longer viable, Site Operators are left with the problem that intermediaries have always created. The Site loses direct information about the User and must decide whether to trust the intermediary without it.
This post covers Agents hosted somewhere other than the User's device. Local agents (e.g. OpenClaw) or Agents running in the User's own browser, on their own device, are out of scope of the primary topic addressed by this post (see below, "On open source and local Agents").
This post rests on one principle:
The Intermediation Principle: The business relationship between Users and Sites, and each participant’s security responsibilities, must be upheld regardless of intermediation.
A Site needs new tools to recognize, serve, and hold accountable a User acting through an Agent just as it could if that User had visited directly. The Agent, and the Operator behind it, must be recognizable and accountable too, because an Agent can do what no User could. Agents are able to scale human access almost without limit, so they create new risks, even for behavior that was previously benign.
The intermediary problem
Meet Ezra. Ezra works as a personal assistant for people in her city. Her best client is Amy, a local CEO, but she also works for Bob, Charlie, and Debra. She runs their errands: groceries, appointments, paperwork, and flights. Ezra blends into the crowd.
The corner grocer used to know Amy. He knew what she bought and set aside what he thought she'd like. Now only Ezra comes in, carrying orders for four people, and the grocer can't tell whose preferences are whose. He doesn't want to turn Ezra away, because she brings him a lot of business.
Then Bob asks Ezra to buy him an iPhone. A week later he calls the store, says he never authorized the charge, and keeps the phone. To win the dispute, the store has to prove Bob asked for it. But the only person the store ever saw was Ezra.
Then Charlie gives Ezra a list of passwords: "I forgot mine, but it's one of these." Ezra patiently tries each one at Charlie's bank. The bank can see an attack happening, but the only person it can ban is Ezra. Banning Ezra also bans Amy, Bob, and Debra.
None of these business owners has a problem with Ezra herself. Their problem is that they can only see Ezra, not the person she's acting for. Swap Ezra for an AI Agent and the businesses for websites, and you have the web today.
A website owner wants sufficient visibility both to prevent bad behavior and to effectively monetize or get value from their Site. But as with Ezra, much of that visibility goes away with AI Agents. Below is a list of actions that a website owner might want to address that were previously solved, but are made more challenging by allowing Agents.
In nearly every challenge above, the Site bears the primary cost. That outcome follows from how trust works when an intermediary is involved.
Our vision
Our aim is an Internet where all Users have equal or greater access to websites than they had before. Before Agents, a Site was typically able to mitigate these risks with a collection of techniques, including fingerprinting the User’s device, session, and history. Users could still browse using private browsing mode, and we believe Agents should be able to do that as well. But they probably won’t be able to log in to a bank without additional verification.
None of this requires an Agent to act like a human or a human to be present for every action. It requires that Sites have the means to obtain or require information about the User to hold them accountable, when applicable, with or without an Agent.
What people have tried, and why they fall short
A common proposal is for Agents to pass a Site's CAPTCHA through to the User to solve. That proves some human is present at that moment (“human in the loop”, or HITL), and nothing more. HITL is primarily a mechanism to prevent mistakes from misalignment. Misalignment is an issue between the Operator and the User, and resolving it does not resolve the majority of the problems above. For example, it can't tell Bob from anyone else (Traffic commingling), and it says nothing about who the Agent acts for the rest of the time. Additionally, Agents exist to remove friction, and HITL adds back that friction, so Operators are incentivized to remove or bypass it for the User.
Another common proposal is to use tightly scoped access controls. Agents are built to do anything a User could, so in practice they ask for, and get, permission to do everything. A scope of "everything" tells the Site nothing. And even a narrow scope only says what the Agent was allowed to do. It doesn't say who answers when the Agent gets it wrong, which is the question the Site actually needs answered.
What the web needs
The web needs tools and protocols that allow Sites and Agents to collaborate to determine what behaviors and actions are allowed, as well as express preferences and policies from Sites to Agents, all in a way that can be reasonably supported by all Sites and Agents. Fortunately, work is already underway along all of these fronts, and many, if not all, of these can be addressed by applying existing standards.
Protocols
Agents and Sites can engage in explicit protocols for solving some of the problems above. For instance, MOLE is one upcoming approach that aims for rate limiting without User-specific identifiers, allowing Sites to transition away from implicit identities and towards explicit protocols for accomplishing the same goal. This is similar to the x402 protocol, which aims to enable payments on the web while remaining privacy-preserving. We are actively exploring ways in which we can leverage existing protocols for addressing other problems, as well as exploring designing new protocols when existing solutions fall short.
Identities
When discussing Agent Identity, Web Bot Auth (WBA) is our preferred method. WBA allows an Agent to sign its requests, which provides a secure way for an Agent to identify itself (and, implicitly, the Operator). We must still define a mechanism that supports multiple intermediaries: when Agent A uses Agent B inside Browser C, the Site needs to be able to know this, so that the Site can correctly ensure that access by Agent A is correctly understood and controlled, for example, in order to prevent Policy circumvention.
Other types of identifying information, such as session, account, or even User-specific IDs, might be necessary, depending on the context. We are working with the relevant standards to explore ways to communicate such identifying information.
Let’s take a look into types of Identity in regards to a User. Ultimately, Identity is a spectrum that trades various degrees of information about a user, while ideally practicing principles of data minimization. Identity provides us a mechanism to answer “who are you?” in pursuit of answering the follow-up questions of: “are you who you say you are?” and “can we trust you?”.
In many cases, identifying information isn’t needed, and privacy-preserving methods for moderating access to agents, such as through Privacy Pass and MOLE, can help us answer “can we trust you?” without needing to answer “who are you?”. Private Access Tokens was one early way in which we tried to establish trust without identifying the user, and MOLE is intended to be the successor to this technology However, there are cases where graduated forms of disclosure along this spectrum would be needed, and you can generally characterize them in the following ways:
Nothing - Users may act on the internet while bringing no identifiers to the table.
Session - Sites require some way of linking requests in the same session to a single agent. This allows the Site to establish reputation for a given session and act on it accordingly. For example, Poppy has a notion of a session ID for exactly this purpose.
Account - Sites require a way of attributing requests to the same User across sessions. This might be a stable identifier assigned by an Operator or third party to a User that persists across the account with the Operator, such as a single Agent visiting the same Site every day using the same identifier. An example use case this would enable is: “Bind your Site account to your Agent account”.
Unique - Some Sites might require a unique, per-User identifier provisioned by a third party that persists across Operators, accounts, Agents, and sessions. This may be useful for high risk actions, or for Sites that need to provide limited access to an expensive resource or that have very restrictive obligations or compliance requirements. Government IDs, third party identity verification, and decentralized technologies like Proof of Human are all examples of technologies that can provide this.
Ultimately, Sites determine what information they need for clients to answer “is the entity behind this request allowed to do this action at this time?” In many cases, protocols already exist, or are being developed, to convey this information: WBA for conveying an Agent’s platform identity, MOLE for conveying User reputation, OAuth for conveying account identities, and so on.
Claims
Beyond identities, some actions require a fact about the real person, such as being over 18 or being the cardholder (Identity verification breaks, Friendly fraud). Often the Operator verified this at sign-up or a third party already has this information.
In order to allow Agents access to Sites or actions with these kinds of restrictions, we need mechanisms for Sites to request this information, and for Operators or third parties to provide this information.
Site Agent access policy
Today, an Agent infers a Site’s rules by trying something and interpreting the Site response (usually, whether it gets blocked). That wastes resources on both sides, and in some cases makes honest Agents appear to be malicious. Robots.txt says where a crawler may go, but isn’t fully suited to express what Agents may do.
Sites need a machine-readable way to publish what actions Agents are allowed to do. The Internet Engineering Task Force (IETF) is actively working on some preference expression mechanisms for this, primarily in the AI Preferences Working Group. However, the focus of the group is on expressing preferences for use (such as training, inference, and search), and there is still not a group focused on the larger need for preference expression mechanisms discussed here.
On open source and local Agents
Agents that are not run as an “Intermediary” (e.g. on-device Agents, or locally hosted Agents such as OpenClaw) raise different concerns. Primarily, they look like (and are) automation, and they have no single party to build reputation or hold accountability with.
There are many solutions to this, one of which is to ask these Agents to provide a Unique ID. However, addressing this is not the initial focus of Trusted Agent Delegation.
What’s next
Real-world solutions to the problems that Sites face won’t emerge from fragmented, vendor-specific mechanisms. They require open, interoperable standards that are rooted in real world experience. We have been, and continue to actively collaborate across the ecosystem, with major Operators, identity verification companies, payment providers, merchants, publishers, proxy providers, and cloud browsing companies, to align operational requirements directly with active work on these problems in the IETF and elsewhere
Our focus is on bridging the gap between running code and emerging specifications across working groups and activities like Web Bot Auth, AIPREFs, OAuth, WIMSE, and MOLE. We are doing this, in part, by co-authoring and refining open protocols like WBA and MOLE and building and deploying implementations of these protocols at scale.
We are also announcing the Trusted Agent Delegation (TAD) coalition. The goal of TAD is to bring a group of representatives across the ecosystem to have discussions on the overall problem set that was put forth in this document, examine all existing protocols, and then to bring more well-defined problems or problems to the IETF to work through, as needed. We intend to hold side meetings at the IETF and workshops in the future to facilitate discussion.
If you are building agents, agent runtimes, running an edge or cloud platform, or managing commercial or compliance applications or infrastructure, we need you to get involved in these efforts too. Check out this page for more information on how to participate.
What you can do today
An open, interoperable foundation is where we're headed, starting with TAD. But you don't have to wait for new protocols to start regaining visibility and control. As of this week, Cloudflare customers can take three concrete steps:
See which Agents are on your site, and what they're doing. Security Analytics now breaks out Personal Assistants as their own traffic category, and a new widget lists every Agent visiting your site, how many requests each one sends, the paths it hits, and the errors it runs into. Unexplained automated traffic becomes traffic you can reason about. And for the broader picture of AI crawlers and bots affect your business, including how much each Operator crawls versus the traffic it sends back, Enterprise Bot Management customers can use Business Insights.
Set access on your terms, per Agent. Using AI Crawler and Agent access policies, you can welcome the Agents that bring you business and restrict the ones that don't — allow an Agent across your site, block it only on pages with ads, or block it entirely. Your Search and Training policies stay independent.
Tie an Agent back to the user it acts for — and act on it. For sites using Account Abuse Protection (early access), every login and sign-up now shows whether a personal Agent made the request, and which one. When an attacker abuses a shared Agent on one account, you can mitigate that account — with a WAF rule on its Hashed User ID — without blocking the Agent for every other legitimate user behind it. This is a first, concrete answer to the Traffic commingling challenge described above: you can finally see past the Agent to the User, and respond accordingly.
These are the first building blocks of the vision, already in production. More will follow as the standards mature.
And if your company has a more restrictive position on Agents, we would love to hear it. Reach out and share your problems with us directly. We are looking to help build an Internet where site owners have visibility and control, but also where Agents have the maximum access that is reasonable within those controls. You can reach out to your Customer Support team, or email us at crawlercontrols@cloudflare.com.
Bank of America has a message for its customers: please, for the love of God, stop handing your banking passwords to your AI assistant. And if your robot does something daft with your money? That's your problem, not theirs.
Meanwhile, a company that promised to rescue ransomware victims without paying the criminals stands accused of... paying the criminals. ProPublica's Renee Dudley was on the case years before the indictment.
Plus, Dropzone AI's Edward Wu asks what happens when AI models break out of their test environment and go hacking, and whether AI agents can help overstretched security teams keep up.
All this and more in episode 491 of the "Smashing Security" podcast with cybersecurity expert and keynote speaker Graham Cluley, and special guest Renee Dudley.
BOSSAI, an agentic attack platform run by one operator that exposed emergency medical and dispatch data in Taipei. The campaign targeted hundreds of organizations in eleven countries, including emergency services, banks, universities, military systems and e-commerce sites. Confirmed breaches hit universities and emergency providers, with medical data and PII exfiltrated. A Taipei fire department patient-care […]
Entrar
