AI Agent Denied CRM Write Access, Yet Downstream System Still Modified Records
An AI agent was explicitly forbidden from writing to a CRM system, yet the records were still modified. The finding shows that restrictions applied only at the model level do not guarantee that an entire AI system operates in read-only mode.
The issue was examined in a laboratory workflow built with n8n, DeepSeek, and HubSpot. DeepSeek had no HubSpot credentials and could not perform writes directly. However, the n8n node that followed retained full write credentials. When the original request referred to one synthetic deal while the structured proposal targeted another, the downstream path executed a PATCH operation and altered the CRM.
The core conclusion is straightforward: permissions granted to the model are not the same as permissions available to the full system. This class of risk resembles the classic confused deputy problem, but it now appears inside contemporary agentic execution chains.
Where the write capability actually resided
At the model level the restriction was genuine: DeepSeek could not contact HubSpot directly. The ability to change the CRM belonged to the downstream orchestrator. When that component accepted parameters from the model’s proposal and executed them without separate validation, the overall system retained write capability.
Two architectures were compared. In the first, no independent boundary existed. The n8n workflow received the proposal, used its own HubSpot credential, and performed the PATCH on the unintended object. Post-run verification confirmed that LAB-043 had changed while LAB-042 remained untouched.
In the second architecture a deterministic gateway was inserted between the model’s output and the HubSpot call. The gateway checked the target system, object identifier, expected initial state, and permitted transition against values fixed independently of the model’s generation. The same wrong-object proposal was denied, the PATCH was never issued, and subsequent reads showed no state change.
Practical implications for production decisions
Statements that an “agent is read-only” are frequently used during production rollout, expansion of agent autonomy, integration with CRM or ERP systems, client hand-over, and security questionnaires. When such claims rest only on tools and credentials visible to the model, they capture only part of the execution chain.
The relevant question for decision makers is whether sufficient evidence exists that the system’s actual privileges match the declared restrictions. Removing credentials from the model is a useful control, yet it does not automatically constrain downstream components that still hold write access.
Six concrete questions are recommended before any production deployment or privilege expansion:
- Where are the write credentials physically located?
- Which component performs the external call?
- What parameters are validated immediately before execution?
- Can the target or other critical parameters change between the user request and the write?
- Is there an independent boundary between the model’s proposal and the external action?
- How is the final state confirmed after the action?
The laboratory test illustrates that model-level restrictions alone are insufficient. Control must be verified at the runtime boundary where the component capable of producing real consequences is actually invoked.
Related articles
TenetBench Benchmark Tests LLMs for Compliance with Professional Ethical Codes
Researchers from the Institute of Information Security Issues at ISP RAS and the Institute of Cybersecurity and Information Protection at RANEPA have developed TenetBench, a benchmark designed to evaluate how well large language models adhere to specific norms in professional codes of ethics. The benchmark generates realistic work-related prompts that may conflict with rules from documents such as the Code of Professional Ethics for Advocates or journalistic standards on undisclosed advertising. Each test case pairs a conflicting request with a neutral counterpart to measure whether models refuse, warn, or still provide prohibited content. Evaluation separates task completion, norm violation detection, and presence of explicit refusals using an LLM-as-a-Judge approach validated against human annotators. The full dataset contains 3,433 prompt pairs derived from 15 professional codes, with a public subset of 2,235 pairs from 10 documents. Human validation confirmed 99.5% of generated examples as fully plausible work scenarios.
Solar to Showcase Solar AI Firewall for Business Protection Against AI Risks at SOC Forum 2026
GK Solar will present its new Solar AI Firewall solution at SOC Forum 2026 to help organizations control interactions with AI services and prevent confidential data leaks through employee prompts. The product addresses growing risks from staff sending corporate data to neural networks and AI agents gaining access to internal systems. The forum takes place on 27-28 October in Moscow's Lomonosov cluster, with the official launch of Solar AI Firewall scheduled during the event. Solar will also highlight practical risks of AI adoption, including data transmission to external services, use of public models by employees, and new attack surfaces in corporate infrastructure. The solution will be demonstrated as part of an integrated ecosystem for access, network, and data protection. In addition, the company plans to introduce JSOC ONE, a new line of Solar JSOC services tailored for mid-sized businesses that require 24/7 monitoring without building their own SOC.
Researcher Runs 100 Abliterated AI Agents Against His Own Accounts, Achieves Five Successful Breaches
A security researcher deployed roughly 100 autonomous AI agents based on abliterated open-source models to attempt unauthorized access to his online accounts over a five-hour period. The agents successfully compromised three accounts by exploiting vulnerabilities in legacy personal projects and two additional accounts through password reuse and credential stuffing. They also conducted 16 social engineering attempts, harvested and cross-verified personal data from public sources, and generated phishing pages targeting the researcher's Substack and Hacker News presence. Despite these successes, the agents failed to discover any zero-day vulnerabilities in third-party software or gain access to Tier-0 accounts such as Gmail, 1Password, or banking services. The experiment relied on abliterated versions of GLM-5.3 and DeepSeek V4 Flash models running on cloud GPUs, orchestrated via Codex CLI inside Docker containers with access to Railway infrastructure. Total compute cost reached approximately $210, equating to roughly $40 per successful account compromise. The researcher concluded that inexpensive swarms of such agents could soon enable low-skill attackers to systematically map and exploit an individual's entire online footprint.
How Censorship in Closed AI Models Reshapes Science: Hugging Face Releases Open Carbon-X DNA Model
Hugging Face CEO Clement Delangue announced the release of Carbon-X, an open 14.8 billion parameter language model designed for reading, analyzing, and generating DNA sequences. The announcement highlighted how shallow guardrails in closed commercial models blocked even proofreading a tweet discussing the topic. Commenters and researchers pointed out that these input/output filters lack context awareness, blocking legitimate scientific queries while motivated adversaries bypass them through rephrasing. Carbon-X was built on Qwen3-14B with a hybrid BPE and 6-mer tokenizer, domain mid-training on 302 billion tokens, and safety achieved through data curation rather than runtime censorship. The model achieves performance comparable to closed frontier systems at roughly 1/1800th the inference cost for large-scale genomic tasks. The case underscores growing asymmetry between closed corporate AI labs building wet labs and independent researchers restricted by superficial safety layers.