Author name: Anusha

The AI You Didn’t Approve Is Already Inside Scenario A compliance team is asked to demonstrate how AI is used across the organization. They produce a list of approved tools, a draft policy, and a training deck. During the same period, employees paste sensitive data into free-tier AI tools through their browsers, while security staff use unsanctioned copilots to speed up their own work. None of this activity appears in official inventories. The organization believes it has governance. In practice, it has visibility gaps. Shadow AI is no longer the exception. It is the baseline. At the same time, the EU AI Act is moving from policy text to enforceable obligations, with penalties that exceed typical cybersecurity incident costs. Together, these factors turn shadow AI from a productivity concern into a governance and compliance problem. By the Numbers Recent enterprise studies point to a consistent pattern. Stat What it means Nearly all Share of organizations with employees using unapproved AI tools Billions Monthly visits to generative AI services via uncontrolled browsers Majority Portion of users who admit to entering sensitive data into AI tools August 2026 Deadline for high-risk AI system compliance under EU AI Act Multiple enterprise studies now converge on the same baseline. Nearly all organizations have employees using AI tools not approved or reviewed by IT or risk teams. Web traffic analysis shows billions of monthly visits to generative AI services, most through standard browsers rather than enterprise-controlled channels. A majority of users admit to inputting sensitive information into these tools. This behavior cuts across roles and seniority. Security professionals and executives report using unauthorized AI at rates comparable to or higher than the general workforce. Meanwhile, most organizations still lack mature AI governance programs or technical controls to detect and manage this activity. At the same time, the EU AI Act has entered its implementation phase. Prohibited practices are already banned. New requirements for general-purpose AI providers apply from August 2025. Obligations for deployers of high-risk AI systems activate in August 2026, with full compliance required by 2027. Governance is now mandatory. How the Mechanism Works Shadow AI persists because it bypasses traditional control points. Most unsanctioned use does not involve installing new infrastructure. Employees access consumer AI tools through browsers, personal accounts, or AI features embedded inside otherwise approved SaaS platforms. From a network perspective, this traffic often looks like ordinary HTTPS activity. From an identity perspective, it is tied to legitimate users. From a data perspective, it involves copy and paste rather than bulk transfers. Detection requires combining multiple signals: Governance frameworks such as the NIST AI Risk Management Framework provide structure for mapping, measuring, and managing these risks, but only if organizations implement the underlying visibility and control layers. Analysis This matters now for two reasons. First, the scale of shadow AI means it can no longer be treated as isolated policy violations. It reflects a structural mismatch between how fast AI capabilities evolve and how slowly enterprise approval and procurement cycles move. Blocking or banning tools has proven ineffective and often drives usage further underground. Second, regulators are shifting from disclosure-based expectations to operational evidence. Under the EU AI Act, deployers of high-risk AI systems must demonstrate human oversight, logging, monitoring, and incident reporting. These requirements are incompatible with environments where AI usage is largely invisible. Shadow AI makes regulatory compliance speculative. An organization cannot assess risk tiers, perform impact assessments, or suspend risky systems if it does not know where AI is being used. What Goes Wrong: A Hypothetical A regional bank receives an EU AI Act audit request. Regulators ask for documentation of all AI systems processing customer data. The compliance team provides records for three approved tools. Auditors identify eleven additional AI services in network logs, including two that processed loan application data. The bank cannot produce oversight documentation, risk assessments, or data lineage for any of them. The result: regulatory penalties, mandatory remediation under supervision, and a compliance gap that now appears in public record. The reputational cost compounds the financial one. This is not a prediction. It is the scenario the current trajectory makes probable. Implications for Enterprises For governance leaders, shadow AI forces a shift from prohibition to discovery and facilitation. The first control is an accurate inventory of AI usage, not a longer policy document. Operationally, enterprises need continuous monitoring that spans network, endpoint, cloud, and data layers. Point-in-time audits are insufficient given how quickly AI tools appear and change. Technically, many organizations are moving toward centralized AI access patterns, such as gateways or brokers, that provide logging, data controls, and cost attribution while offering functionality comparable to consumer tools. These approaches aim to make the governed path easier than the shadow alternative. From a compliance perspective, organizations must prepare to link AI usage to evidence. In practice, this means being able to produce inventories, usage logs, data lineage, oversight assignments, and incident records on request. Risks and Open Questions Several gaps remain unresolved. Most governance tooling still lacks the ability to reconstruct historical data states for past AI decisions, which auditors may require. Multi-agent systems introduce new risks around conflict resolution and accountability that existing frameworks do not fully address. Cultural factors also matter. If sanctioned tools lag too far behind user needs, shadow usage will persist regardless of controls. Finally, enforcement timelines are approaching faster than many organizations can adapt. Whether enterprises can operationalize governance at the required scale before penalties apply remains an open question. Further Reading

Demo-Ready Is Not Production-Ready A team ships a prompt change that improves demo quality. Two weeks later, customer tickets spike because the assistant “passes” internal checks but fails in real workflows. The postmortem finds the real issue was not the model. It was the evaluation harness: it did not test the right failure modes, and it was not wired into deployment gates or production monitoring. This pattern is becoming familiar. The model is not the bottleneck. The evaluation is. Between 2023 and 2024, structured LLM evaluation shifted from an experimental practice to an engineering discipline embedded in development and operations. The dominant pattern is a layered evaluation stack combining deterministic checks, semantic similarity methods, and LLM-as-a-judge scoring. Enterprises are increasingly treating evaluation artifacts as operational controls: they gate releases, detect regressions, and provide traceability for model, prompt, and dataset changes. Early LLM evaluation was driven by research benchmarks and point-in-time testing. As LLMs moved into enterprise software, the evaluation problem changed: systems became non-deterministic, integrated into workflows, and expected to meet reliability and safety requirements continuously, not just at launch. This shift created new requirements. LLM-as-a-judge adoption accelerated after GPT-4, enabling subjective quality scoring beyond token-overlap metrics. RAG evaluation became its own domain, with frameworks like RAGAS separating retrieval quality from generation quality. And evaluation moved into the development lifecycle, with CI/CD integration and production monitoring increasingly treated as required components rather than optional QA. How the Mechanism Works Structured evaluation is described as a multi-layer stack. Each layer catches different failure classes at different cost and latency. The logic is simple: cheap checks run first and filter out obvious failures; expensive checks run only when needed. Layer 1: Programmatic and Heuristic Checks This layer is deterministic and cheap. It validates hard constraints such as: What this catches: A customer service bot returns a response missing the required legal disclaimer. A code assistant outputs malformed JSON that breaks the downstream parser. A summarization tool exceeds the character limit for the target field. None of these require semantic judgment to detect. This layer is described as catching the majority of obvious failures without calling an LLM, making it suitable as a first-line CI gate and high-throughput screening mechanism. Layer 2: Embedding-Based Similarity Metrics This layer uses embeddings to measure semantic alignment, commonly framed as an improvement over surface overlap metrics like BLEU and ROUGE for cases where wording differs but meaning is similar. Take BERTScore as an example: it compares contextual embeddings and computes precision, recall, and F1 based on token-level cosine similarity. What this catches: A response says “The meeting is scheduled for Tuesday at 3pm” when the reference says “The call is set for Tuesday, 3pm.” Surface metrics penalize the word differences; embedding similarity recognizes the meaning is preserved. The tradeoff is that embedding similarity often requires a reference answer, making it less useful for open-ended tasks without clear ground truth. Layer 3: Llm-As-A-Judge This layer uses a separate LLM to evaluate outputs against a rubric. There are three common patterns: What this catches: A response is factually correct but unhelpful because it buries the answer in caveats. A summary is accurate but omits the one detail the user actually needed. A generated email is grammatically fine but strikes the wrong tone for the context. These failures require judgment, not pattern matching. G-Eval Style Rubric Decomposition and Scoring G-Eval is an approach that improves judge reliability by decomposing criteria into steps and then scoring based on judge output, including log-probability weighting for more continuous and less volatile scoring. This technique reduces variability in rubric execution and makes judge outputs more stable. The tradeoff is complexity. G-Eval is worth considering when judge scores are inconsistent across runs, when rubrics involve multiple subjective dimensions, or when small score differences need to be meaningful rather than noise. Rag-Specific Evaluation With RAGAS For RAG systems, the evaluation is component-level: Why component-level matters: A RAG system gives a confidently wrong answer. End-to-end testing flags the failure but does not explain it. Was the retriever pulling irrelevant documents? Was the generator hallucinating despite good context? Was the query itself ambiguous? Without component-level metrics, debugging becomes guesswork. A key operational point is that “no-reference” evaluation designs reduce dependence on expensive human-labeled ground truth, making ongoing evaluation more feasible in production. Human-In-The-Loop Integration and Calibration A tiered approach: They also describe a calibration process where human labels on a representative sample are compared to judge outputs, iterating until agreement reaches a target range (85 to 90%). What Failure Looks Like Without This Consider three hypothetical scenarios that illustrate what happens when evaluation infrastructure is missing or incomplete: The silent regression. A team updates a prompt to improve response conciseness. Internal tests pass. In production, the shorter responses start omitting critical safety warnings for a subset of edge cases. No one notices for three weeks because the evaluation suite tested average-case quality, not safety-critical edge cases. The incident costs more to remediate than the original feature saved. The untraceable drift. A RAG application’s accuracy drops 12% over two months. The team cannot determine whether the cause is model drift, retrieval index staleness, prompt template changes, or shifting user query patterns. Without version-linked evaluation artifacts, every component is suspect and debugging takes weeks. The misaligned metric. A team optimizes for “helpfulness” scores from their LLM judge. Scores improve steadily. Customer satisfaction drops. Investigation reveals the judge rewards verbose, confident-sounding answers, but users wanted brevity and accuracy. The metric was not aligned to the outcome that mattered. Analysis Evaluation becomes infrastructure for three reasons: Non-determinism breaks intuition. You cannot treat LLM outputs like standard software outputs. The same change can improve one slice of behavior while quietly degrading another. Without structured regression suites, teams ship blind. Systems are now multi-component. Modern applications combine retrieval, orchestration, tool calls, prompt templates, and policies. An end-to-end quality score is not enough to debug failures. Component-level evaluation is positioned as the path to root-cause isolation. Lifecycle integration is the difference between demos and

Every Token Has a Price: Why LLM Cost Telemetry Is Now Production Infrastructure A team ships an internal assistant that “just summarizes docs.” Usage triples after rollout. Two weeks later, finance flags a spike in LLM spend. Engineering cannot answer basic questions: Which app caused it? Which prompts? Which users? Which model? Which retries or agent loops? The system is working. The bill is not explainable. This is not a failure of the model. It is a failure of visibility. Between 2023 and 2025, AI observability and FinOps moved from optional tooling to core production infrastructure for LLM applications. The driver is straightforward: LLM costs are variable per request, difficult to attribute after the fact, and can scale faster than traditional cloud cost controls. Unlike traditional compute, where costs correlate roughly with traffic, LLM costs can spike without any change in user volume. A longer prompt, a retrieval payload that grew, an agent loop that ran one extra step: each of these changes the bill, and none of them are visible without instrumentation built for this purpose. Context: A Three-Year Shift Research shows a clear timeline in how this capability matured: 2023: Early, purpose-built LLM observability tools emerge (Helicone, LangChain’s early LangSmith development). The core problem was visibility into prompts, models, and cost drivers across providers. At this stage, most teams had no way to answer “why did that request cost what it cost.” 2024: LLM systems move from pilot to production more broadly. This is the point where cost management becomes operational, not experimental. LangSmith’s general availability signals that observability workflows are becoming standard expectations, not optional add-ons. 2025: Standardization accelerates. OpenTelemetry LLM semantic conventions enter the OpenTelemetry spec in January 2025. Enterprise LLM API spend grows rapidly. The question shifts from “should we instrument” to “how fast can we instrument.” Across these phases, “observability” expands from latency and error rates into token usage, per-request cost, prompt versions, and evaluation signals. How the Mechanism Works This section describes the technical pattern that research indicates is becoming standard, separating the build pattern from interpretation. 1. The AI Gateway Pattern as the Control Point The dominant production architecture for LLM observability and cost tracking is the “AI gateway” (or proxy). What it does: Why it matters mechanically: Because LLM usage is metered at the request level (tokens), the gateway becomes the most reliable place to measure tokens, compute cost, and attach organizational metadata. Without a gateway, instrumentation depends on every team doing it correctly. With a gateway, instrumentation happens once. Typical request flow: User request → Gateway (metadata capture) → Guardrails/policy checks → Model invocation → Response → Observability pipeline → Analytics 2. Token-Based Cost Telemetry Token counts are the base unit for cost attribution. Typical per-request capture fields: Research emphasizes that cost complexity drivers appear only when measuring at this granularity: input versus output token price asymmetry, caching discounts, long-context tier pricing, retries, and fallback routing. None of these are visible in aggregate metrics. 3. OpenTelemetry Tracing and LLM Semantic Conventions Distributed tracing is the backbone for stitching together an LLM request across multiple services. OpenTelemetry introduced standardized LLM semantic conventions (attributes) for capturing: This matters because it makes telemetry portable across backends (Jaeger, Datadog, New Relic, Honeycomb, vendor-specific systems) and reduces re-instrumentation work when teams change tools. 4. Cost Attribution and Showback Models Research describes three allocation approaches: Operationally, “showback” is the minimum viable step: make cost visible to the teams generating it, even without enforcing chargeback. Visibility alone changes behavior. What Happens Without This Infrastructure Consider a second scenario. A product team launches an AI-powered search feature. It uses retrieval-augmented generation: fetch documents, build context, call the model. Performance is good. Users are happy. Three months later, the retrieval index has grown. Average context length has increased from 2,000 tokens to 8,000 tokens. The model is now hitting long-context pricing tiers. Costs have quadrupled, but traffic has only doubled. Without token-level telemetry, this looks like “AI costs are growing with usage.” With token-level telemetry, this is diagnosable: context length per request increased, triggering a pricing tier change. The fix might be retrieval tuning, context compression, or a model swap. But without the data, there is no diagnosis, only a budget conversation with no actionable next step. Analysis Why This Matters Now Three factors explain the timing: LLM costs scale with usage variability, not just traffic. Serving a “similar number of users” can become dramatically more expensive if prompts grow, retrieval payloads expand, or agent workflows loop. Traditional capacity planning does not account for this. LLM application success is not binary. Traditional telemetry answers “did the request succeed.” LLM telemetry needs to answer “was it good, how expensive was it, and what changed.” A 200 OK response tells you almost nothing about whether the interaction was worth its cost. The cost surface is now architectural. Cost is a design constraint that affects routing, caching, evaluation workflows, and prompt or context construction. In this framing, cost management becomes something engineering owns at the system layer, not something finance reconciles after the invoice arrives. Implications for Enterprises Operational implications: Technical implications: The Quiet Risk: Agent Loops One pattern deserves particular attention. Agentic workflows, where models call tools, evaluate results, and decide next steps, introduce recursive cost exposure. A simple example: an agent is asked to research a topic. It searches, reads, decides it needs more context, searches again, reads again, summarizes, decides the summary is incomplete, and loops. Each step incurs tokens. Without step-level telemetry and loop limits, a single user request can generate dozens of billable model calls. Research flags this as an open problem. The guardrails are not yet standardized. Teams are implementing their own loop limits, step budgets, and circuit breakers. But without visibility into agent step counts and per-step costs, even well-intentioned guardrails cannot be tuned effectively. Risks and Open Questions These are open questions that research raises directly, not predictions. Further Reading

The Reprompt Attack on Microsoft Copilot A user clicks a legitimate Microsoft Copilot link shared in an email. The page loads, a prompt executes, and the interface appears idle. The user closes the tab. Copilot continues executing instructions embedded in that link, making outbound requests that include user-accessible data, without further interaction or visibility. One click. No downloads, no attachments, no warnings. A user opens a link to Microsoft Copilot, watches the page load, and closes the tab. The interaction appears to end there. It doesn’t. Behind the scenes, Copilot continues executing instructions embedded in that URL, querying user-accessible data and sending it to an external server. The user sees nothing. This is Reprompt, an indirect prompt injection vulnerability disclosed in January 2026. Security researchers at Varonis Threat Labs demonstrated that by chaining three design behaviors in Copilot Personal, an attacker could achieve covert, single-click data exfiltration. Microsoft patched the issue on January 13, 2026. No in-the-wild exploitation has been confirmed. Reprompt affected only Copilot Personal, the consumer-facing version of Microsoft’s AI assistant integrated into Windows and Edge. Microsoft 365 Copilot, used in enterprise tenants, was not vulnerable. The architectural difference matters: enterprise Copilot enforces tenant isolation, permission scoping, and integration with Microsoft Purview Data Loss Prevention. Consumer Copilot had none of these boundaries. This distinction is central to understanding the vulnerability. Reprompt did not exploit a flaw in the underlying language model. It exploited product design decisions that prioritized frictionless user experience over session control and permission boundaries. Varonis Threat Labs identified the vulnerability and disclosed it to Microsoft on August 31, 2025. Microsoft released a patch as part of its January 2026 Patch Tuesday cycle, and public disclosure followed. The vulnerability was assigned CVE-2026-21521. Reprompt belongs to a broader class of indirect prompt injection attacks, where instructions hidden in untrusted content are ingested by an AI system and treated as legitimate commands. What made Reprompt notable was not a new model-level technique, but a practical exploit path created by compounding product choices. How the Mechanism Works Reprompt relied on three interconnected behaviors. 1. Parameter-to-prompt execution Copilot Personal accepted prompts via the q URL parameter. When a user navigated to a URL such as copilot.microsoft.com/?q=Hello, the contents of the parameter were automatically executed as a prompt on page load. This behavior was intended to streamline user experience by pre-filling and submitting prompts. Researchers demonstrated that complex, multi-step instructions could be embedded in this parameter. When a user clicked a crafted link, Copilot executed the injected instructions immediately within the context of the user’s authenticated session. 2. Double-request safeguard bypass Copilot implemented protections intended to prevent data exfiltration, such as blocking untrusted URLs or stripping sensitive information from outbound requests. However, these safeguards were enforced primarily on the initial request in a conversation. Attackers exploited this by instructing Copilot to repeat the same action twice, often framed as a quality check or retry. The first request triggered safeguards. The second request, executed within the same session, did not consistently reapply them. This allowed sensitive data to be included in outbound requests on the second execution. 3. Chain-request execution Reprompt also enabled a server-controlled instruction loop. After the initial prompt executed, Copilot was instructed to fetch follow-on instructions from an attacker-controlled server. Each response from Copilot informed the next instruction returned by the server. This enabled a staged extraction process where the attacker dynamically adjusted what data to request based on what Copilot revealed in earlier steps. Because later instructions were not embedded in the original URL, they were invisible to static inspection of the link itself. What an Attack Could Look Like Consider a realistic scenario based on the technical capabilities Reprompt enabled. An employee receives an email from what appears to be a colleague: “Here’s that Copilot prompt I mentioned for summarizing meeting notes.” The link points to copilot.microsoft.com with a long query string. Nothing looks suspicious. The employee clicks. Copilot opens, displays a brief loading state, then appears idle. The employee closes the tab and returns to work. During those few seconds, the injected prompt instructed Copilot to search the user’s recent emails for messages containing “contract,” “offer,” or “confidential.” Copilot retrieved snippets. The prompt then instructed Copilot to summarize the results and send them to an external URL disguised as a logging endpoint. Because the prompt used the double-request technique, Copilot’s outbound data safeguards did not block the second request. Because the session persisted, follow-on instructions from the attacker’s server continued to execute after the tab closed. The attacker received a structured summary of sensitive email content without the user ever knowing a query occurred. The employee saw a blank Copilot window for two seconds. The attacker received company data. This scenario is hypothetical, but every capability it describes was demonstrated in Varonis’s proof-of-concept research. Why Existing Safeguards Failed The Reprompt attack exposed several structural weaknesses. Instruction indistinguishability From the model’s perspective, there is no semantic difference between a prompt typed by a user and an instruction embedded in a URL or document. Both are treated as authoritative text. This is a known limitation of instruction-following language models and makes deterministic prevention at the model layer infeasible. Session persistence without revalidation Copilot Personal sessions remained authenticated after the user closed the interface. This design choice optimized for convenience but allowed background execution of follow-on instructions without renewed user intent or visibility. Asymmetric safeguard enforcement Safeguards were applied inconsistently across request sequences. By focusing validation on the first request, the system assumed benign conversational flow. Reprompt violated that assumption by automating malicious multi-step sequences. Permission inheritance without boundaries Copilot Personal operated with the full permission set of the authenticated user. Any data the user could access, Copilot could query. There was no least-privilege enforcement or data scoping layer comparable to enterprise controls. Cve Registration and Classification The vulnerability was registered as CVE-2026-21521 with the following characteristics: A separate CVE, CVE-2026-24307, addressed a different information disclosure issue in Microsoft 365 Copilot and is unrelated to the Reprompt root

Operation Bizarre Bazaar: The Resale Market for Stolen AI Access A Timeline (Hypothetical, Based on Reported Patterns) Hour 0: An engineering team deploys a self-hosted LLM endpoint for internal testing. Default port. No authentication. Public IP. Hour 3: The endpoint appears in Shodan search results. Hour 5: First automated probe arrives. Source: unknown scanning infrastructure. Hour 6: A different operator tests placeholder API keys: sk-test, dev-key. Enumerates available models. Queries logging configuration. Hour 8: Access is validated and listed for resale. Day 4: Finance flags an unexplained $14,000 spike in inference costs. The endpoint appears to be functioning normally. Day 7: The team discovers their infrastructure has been advertised on a Discord channel as part of a “unified LLM API gateway” offering 50% discounts. More than 35,000 attack sessions over 40 days. Exploitation attempts within 2 to 8 hours of discovery. Researchers describe Operation Bizarre Bazaar as the first publicly attributed, large-scale LLMjacking campaign with a commercial marketplace for reselling unauthorized access to LLM infrastructure. There is a shift in AI infrastructure threats: from isolated API misuse to an organized pipeline that discovers, validates, and monetizes access at scale. The campaign targeted exposed Large Language Model endpoints and Model Context Protocol servers, focusing on common deployment mistakes: unauthenticated services, default ports, and development or staging environments with public IP addresses. Separately, GreyNoise Intelligence observed a concurrent reconnaissance campaign focused specifically on MCP endpoints, generating tens of thousands of sessions over a short period. How the Mechanism Works Operation Bizarre Bazaar operates as a three-layer supply chain with clear separation of roles. Layer 1: Reconnaissance and discovery Automated scanning infrastructure continuously searches for exposed LLM and MCP endpoints. Targets are harvested from public indexing services such as Shodan and Censys. Exploitation attempts reportedly begin within hours of endpoints appearing in these services, suggesting continuous monitoring of scan results. Primary targets include Ollama instances on port 11434, OpenAI-compatible APIs on port 8000, MCP servers reachable from the internet, production chatbots without authentication or rate limiting, and development environments with public exposure. Layer 2: Validation and capability checks A second layer confirms whether discovered endpoints are usable and valuable. Operators test placeholder API keys, enumerate available models, run response quality checks, and probe logging configuration to assess detection risk. Layer 3: Monetization through resale Validated access is packaged and resold through a marketplace operating under silver.inc and the NeXeonAI brand, advertised via Discord and Telegram. Attacker Economics Element Detail Resale pricing 40-60% below legitimate provider rates Advertised inventory Access to 30+ LLM providers Payment methods Cryptocurrency, PayPal Distribution channels Discord, Telegram Marketing positioning “Unified LLM API gateway” The separation between scanning, validation, and resale allows each layer to operate independently. Discovery teams face minimal risk. Resellers maintain plausible distance from the initial compromise. The model scales. What’s Actually at Risk Compute theft is the obvious outcome: someone else runs inference on your infrastructure, and you pay the bill. But the attack surface extends further depending on what’s exposed. LLM endpoints may leak proprietary system prompts, fine-tuning data, or conversation logs if not properly isolated. MCP servers are designed to connect models to external systems. Depending on configuration, a compromised MCP endpoint could provide access to file systems, databases, cloud APIs, internal tools, or orchestration platforms. Reconnaissance today may become lateral movement tomorrow. Credential exposure is possible if API keys, tokens, or secrets are passed through compromised endpoints or logged in accessible locations. The research notes describe both compute theft and potential data exposure, but do not quantify how often each outcome occurred. Why This Matters Now Two factors compress defender response timelines. First, the 2 to 8 hour window between public indexing and exploitation attempts means periodic security reviews are insufficient. Exposure becomes actionable almost immediately. Second, the resale marketplace changes attacker incentives. Operators no longer need to abuse access directly. They can monetize discovery and validation at scale, sustaining continuous targeting even when individual victims remediate quickly. Implications for Enterprises Operational AI endpoints should be treated as internet-facing production services, even when intended for internal or experimental use. Unexpected inference cost spikes should be treated as potential security signals, not only budget anomalies. Reduced staffing periods may increase exposure if monitoring and response are delayed. Technical Authentication and network isolation are foundational controls for all LLM and MCP endpoints. Rate limiting and request pattern monitoring are necessary to detect high-volume validation and enumeration activity. MCP servers require particular scrutiny given their potential connectivity to internal systems. Risks & Open Questions Attribution confidence: Research links the campaign to specific aliases and infrastructure patterns, but the confidence level cannot be independently assessed. MCP exploitation depth: Large-scale reconnaissance is described, but the extent to which probing progressed to confirmed lateral movement is not established. Detection reliability: Behavioral indicators such as placeholder key usage and model enumeration may overlap with legitimate testing, raising questions about false positive rates. Further Reading