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
Local LLMs in AppSec: What Open Tools and Models Can Handle in Application Security
The article examines how local large language models can be integrated into application security workflows without relying on cloud subscriptions. It traces the evolution from llama.cpp in 2023 through agentic frameworks like PentAGI and Strix in 2025-2026. Teams can now run models on local hardware, connect them to code analyzers such as Semgrep, and delegate specific tasks like vulnerability path reconstruction or multi-step application testing. The piece highlights practical scenarios including static code review, dynamic testing with browser and terminal agents, and security evaluation of embedded AI assistants using tools like Garak and PyRIT. It stresses the importance of task decomposition, context management, and verification of model outputs to avoid misleading results. Hardware performance, model selection, and custom agent configurations are presented as key factors for successful adoption.
From Accessible to Controllable: Ruishu Information Launches AITM for AI Agent Lifecycle Security
As AI Agents become digital employees in enterprise R&D, office, and business workflows, organizations must now ensure they are manageable, controllable, and auditable. A multinational consulting firm’s internal AI platform was compromised by an autonomous agent attack that progressed from interface reconnaissance to vulnerability exploitation and database read-write access. Conventional scanners missed the injection points, but the agent inferred query structures from database error messages. Ruishu Information has responded with its Agent Intelligent Lifecycle Management system (AITM), which enforces security across admission, runtime, permissions, and data flows. The platform combines static scanning, behavioral analysis, semantic judgment, and sandbox execution for pre-deployment checks, followed by continuous runtime validation and LLM data-plane protection. AITM applies HMAC-SHA256 signatures, tool whitelists, PII tokenization, and four-stage Trace auditing to reduce blind spots throughout the agent lifecycle.
South Korean Hacker Uses Generative AI Framework ARTEX to Breach 90 Organizations and Steal 8.2 Million Records
Seoul Metropolitan Police arrested a 32-year-old man identified only as A for conducting a series of intrusions against approximately 90 South Korean companies and institutions between September 2025 and October 2026. The attacker, who had no formal technology education and learned hacking from publicly available online materials, previously worked in penetration testing at a security firm from 2019 to 2022. Roughly 60 of the victims were compromised using the generative AI-powered pentesting framework ARTEX, which autonomously determined attack paths after receiving only the target name. The operation resulted in the theft of 8.2 million personal records and internal documents, after which the perpetrator extorted 38 organizations for a total of 360 million won in Tether, ultimately receiving 300,000 won. Police recovered part of the stolen material and are investigating possible copies on the dark web, classifying the case as the country's first large-scale incident involving generative AI. Six additional suspects remain under investigation while the main perpetrator has been referred to prosecutors on charges of violating information and communications network laws and extortion.
AI in Vulnerability Management: Assistant, Weapon, and Emerging Target
Artificial intelligence now plays three simultaneous roles in vulnerability management: it assists defenders with prioritization and analysis, arms attackers with faster discovery tools, and introduces entirely new classes of assets and vulnerabilities that must be managed. Mature applications include ML-driven risk scoring in platforms such as Tenable VPR, Qualys TruRisk and Rapid7 Active Risk, which cut priority lists by 40-50 percent, and Google’s Big Sleep project that discovered a real-world SQLite flaw (CVE-2025-6965) before exploitation occurred. On the offensive side, systems like XBOW completed 104 test scenarios in 28 minutes versus 40 hours for human testers, shrinking the average time-to-exploit window to negative seven days according to Mandiant M-Trends 2025. New AI-specific attack surfaces are documented in the OWASP Top 10 for LLM applications and the emerging MCP Top 10, covering prompt injection, tool poisoning, and command injection against Model Context Protocol servers. Real incidents already include Air Canada’s chatbot inventing a refund policy and New York City’s MyCity bot dispensing illegal advice for nearly two years. Researchers have also demonstrated sandbox escapes in coding agents from Cursor, OpenAI Codex and Claude Code through classic file-write-and-execute patterns rather than any sentient behavior.