Uncategorized

The Evidence Problem: State AI Laws Are Asking for Documents Most Enterprises Don’t Have Colorado, Connecticut, and Maryland are turning AI governance into recurring work with deadlines, documentation requirements, and user rights obligations. The question for enterprise teams is not whether frameworks exist, but whether the evidence to satisfy them is ready. Short Scenario A product team launches an AI-assisted hiring tool. It ingests resumes, scores candidates, and flags whom to advance. The model performs well in testing. Legal clears the launch. Once the regime is in force, a compliance inquiry arrives, whether from a regulator, an internal audit, or a procurement diligence process. The request covers the impact assessment conducted before deployment, training data documentation, performance metrics, discrimination risk evaluation, vendor documentation provided to the deployer, applicant notices, and any explanation or appeal process. None of this is about whether the model worked. It is about whether governance was treated as a system requirement from the start. Several U.S. states are establishing AI governance regimes that regulate certain systems not because they are “AI,” but because they materially affect people’s rights, opportunities, or access to essential services. Colorado’s enacted Colorado AI Act SB 24 205 , Connecticut’s pending SB 2, and Maryland’s enacted AI Governance Act for state agencies represent the most developed frameworks. A parallel track is forming through California’s ADMT regulations and a separate frontier-model transparency regime under SB 53. These frameworks share a common logic: define a category of systems called “high-risk” or “high-impact,” attach governance obligations to that category, and require evidence that those obligations were met. The shared trigger is consequential decisions: those with legal or similarly significant effects in domains such as financial or lending services, housing, insurance, education, employment, healthcare, or access to essential goods and services. Colorado and Connecticut focus on private-sector developers and deployers. Maryland focuses on public-sector agencies. California spans both, depending on the provision. Key deadlines: Colorado’s core obligations take effect June 30, 2026. Connecticut’s SB 2 would take effect February 1, 2026 if enacted. Maryland’s agency inventory deadline was December 1, 2025, with impact assessments for certain existing systems due by February 1, 2027. California’s frontier-model obligations under SB 53 are effective January 1, 2026, with ADMT rules following January 1, 2027. Organizations not yet in-scope for every regime may already have suppliers, customers, or public-sector counterparts that are. How the Mechanism Works Classification: “High-Risk” and “Consequential Decisions” The governance trigger is not the presence of AI. It is the role the system plays. Colorado and Connecticut both use the framing of “high-risk AI systems” that make, or are a substantial factor in making, consequential decisions. Once a system crosses that threshold, it becomes a governed system with documented controls rather than a standard software feature. In practice, classification is harder than it appears. Many systems sit at the edges: they inform rather than decide, or they contribute to a workflow where a human nominally makes the final call. Getting classification right is the prerequisite to everything that follows. Developer Obligations vs. Deployer Obligations Both Colorado and Connecticut split responsibilities between developers (those who create or provide the AI system) and deployers (those who use it in an operational context affecting people). Developers are responsible for reasonable care, for providing deployers with the technical documentation needed to conduct assessments, and for publishing statements about high-risk systems and risk management practices. Colorado adds a notification requirement: developers must alert the Attorney General and known deployers within 90 days of discovering, or receiving a credible report, that a system has caused or is likely to cause algorithmic discrimination. Deployers carry the implementation burden: a risk management policy and program for each high-risk system, comprehensive impact assessments, annual reviews, consumer notices, and rights processes for adverse decisions. Deployers cannot complete their obligations without adequate documentation from developers. Gaps in vendor-supplied materials are a compliance blocker, not just a legal footnote. Evidence Artifacts Compliance is not a checkbox. Required artifacts typically include a risk management policy and program; a comprehensive impact assessment per highrisk AI system covering purpose, data categories, performance metrics, discrimination evaluation, and safeguards; documentation packages flowing from developers to deployers; and public statements about high-risk system categories. These artifacts must be maintained over time, not produced once at launch. Transparency and User-Facing Controls Colorado and Connecticut both require AI interaction disclosures for systems intended to interact with consumers, and consumer notice when a high-risk system is used in a consequential decision context. Both include rights to explanation, correction, and appeal or human review following adverse consequential decisions. Connecticut SB 2 adds watermarking requirements for AI-generated content under specified circumstances. These obligations require operational readiness across support, legal, and product teams, including the ability to field appeals, trace decisions, and enable meaningful human review. Public Sector Governance Maryland requires state agencies to maintain inventories of high-risk AI systems, adopt procurement and deployment policies, and conduct impact assessments on a defined schedule. California’s government inventory requirement mandates statewide visibility into high-risk automated decision systems and reporting. Framework Alignment as a Defense Colorado and Connecticut both reference the NIST AI Risk Management Framework as a basis for asserting reasonable care or an affirmative defense. This creates an incentive to build one internal governance program mapped across jurisdictions rather than separate compliance tracks per state. A Second Scenario: The Vendor Problem An enterprise deploys a third-party AI model to score commercial loan applications. The vendor provides a model card and a brief technical summary. When the deployer’s compliance team begins its impact assessment, it finds the vendor documentation does not include discrimination testing results across protected classes, does not describe training data sources with enough specificity to evaluate potential bias, and does not provide the performance metrics expected for the impact assessment. The deployer cannot complete its assessment without that information. Procurement did not require it at contract time. The compliance deadline is fixed. This is a representative failure mode implied directly by the developer-deployer split these frameworks create. Procurement processes

LLMjacking: The Credential Leak That Becomes an AI Bill A team enables Amazon Bedrock for an internal assistant in late Q3. Adoption is modest but growing. In early Q4, a developer opens a support ticket: the assistant is returning errors and occasionally timing out. The on-call engineer suspects a model quota issue and checks the Bedrock console. Quotas are nearly exhausted. She assumes a misconfigured load test and files it for the morning. The billing alert arrives two days later. Overnight spend has spiked to a level that triggers the cost anomaly threshold. By the time the investigation reaches CloudTrail, the pattern is clear: the same IAM principal has been invoking models at high volume across two regions for five days. The first invocations included a call to GetModelInvocationLoggingConfiguration and a ValidationException on an InvokeModel call with max_tokens_to_sample = -1. Neither event triggered an alert. The engineer recognizes them now for what they were: an automated tool checking whether the key had invocation rights and whether logging was configured. It did, and logging did not appear to be enabled. The abuse began shortly after. “LLMjacking” describes a practical attack pattern: adversaries steal cloud credentials or API keys, then use them to invoke managed LLM services at the victim’s expense. Reporting and vendor write-ups from 2024 through early 2026 document recurring tradecraft across providers, including reconnaissance against AI service APIs, high-volume inference abuse, and resale of hijacked access through reverse proxies. The term and pattern emerged publicly in late 2024 from an incident reporting that described stolen AWS access keys being used to abuse Bedrock and other hosted LLM services. Through 2025 and into early 2026, multiple sources treated LLMjacking as a distinct subcategory of cloud service hijacking, documenting it in mainstream industry reporting, threat detection reports, and technical incident analyses. Across these sources, the defining feature is not a novel exploit in model infrastructure. It is the reuse of familiar cloud compromise paths, followed by targeted abuse of AI service APIs that carry high variable costs and are often governed primarily by identity and quota controls. How the mechanism works LLMjacking is typically described as a lifecycle with four stages: credential acquisition, service enumeration, access verification and quota probing, then sustained abuse and monetization. 1. Credential acquisition Sources describe three common paths: 1. Exploitation of internet-facing applications to gain execution, then harvesting credentials from environment variables, configuration files, or instance metadata. Several reports highlight vulnerable Laravel deployments CVE 2021 3129) as one such foothold leading to credential theft and later LLM abuse. 2. Leakage of static cloud keys or vendor API keys in public repositories, CI/CD logs, or misconfigured pipelines, followed by automated discovery and validation by scanners. 3. Phishing, credential stuffing, or purchase of valid cloud identities from credential markets, including developer and service accounts that already hold AI permissions. 2. Enumeration of AI services and regions Once a credential is obtained, actors validate the principal and enumerate AI capabilities using standard cloud APIs. Examples cited include AWS calls such as GetCallerIdentity and Bedrock model listing calls such as ListFoundationModels and ListCustomModels, along with equivalent enumeration of Azure OpenAI and GCP Vertex AI. Region selection also appears in incident reporting. Actors probe regions that support the target AI service to maximize throughput and avoid wasted calls. 3. Stealthy access verification and logging checks A recurring technique in detailed writeups is deliberate misuse of model invocation parameters to trigger a predictable validation error. For AWS Bedrock, sources describe invoking InvokeModel with an intentionally invalid parameter value (for example, max_tokens_to_sample = -1 ) so the service returns a ValidationException. The distinction matters: a validation error indicates the principal can reach the service and has invocation rights, while AccessDenied would indicate missing permissions. Reports also describe queries to determine whether model invocation logging is enabled, including calls like GetModelInvocationLoggingConfiguration. Some tooling reportedly avoids keys where prompt and response logging is active, consistent with an attacker’s preference for minimizing visibility. 4. Sustained inference abuse and resale After confirmation, actors ramp to high-volume invocations, sometimes across multiple regions and providers. The abuse can serve two operational goals: 1. Offloading compute costs for the attacker’s own workloads, including the generation of phishing content or other malicious outputs described in several sources. 2. Reselling access by placing a reverse proxy in front of a pool of stolen keys. Multiple reports describe “OAI Reverse Proxy” or similar tooling as a way to centralize credential inventory and expose a single service endpoint to downstream customers while distributing usage across compromised accounts. What the Attacker Sees The defender experience described above spans days. The attacker’s side of the same event takes minutes and is largely automated. A scanner ingests a newly discovered key, likely pulled from a public repository commit or a credential market. It calls GetCallerIdentity to confirm the key is valid and resolves the account ID and principal. It then calls ListFoundationModels against a set of target regions to identify which AI services the principal can enumerate. Two regions return results. The tool issues an InvokeModel call with max_tokens_to_sample = -1. The service returns a ValidationException, not AccessDenied. The key has invocation rights. A call to GetModelInvocationLoggingConfiguration returns no active logging configuration. The key passes all checks. The key is added to a proxy pool. From that point, the proxy routes inference requests from downstream customers through the compromised account, distributing load across a rotating set of stolen keys. The original account holder’s quota absorbs the traffic. The attacker’s customers pay the proxy operator a fraction of retail API pricing. The account holder pays the cloud bill. No model-side exploit is required. The initial access comes from standard credential compromise paths, and the abuse uses legitimate AI service APIs. The primary impact can be cost and quota exhaustion, and some reporting also discusses follow-on goals such as data access or pivoting depending on how the service is integrated. The entire entry sequence can be executed quickly and is largely automated. Analysis Two practical shifts explain why

Green Tests, Red Production How enterprise LLM evaluation became a continuous engineering discipline. The scenario A team tweaks a system prompt to reduce hallucinations and improve tone. Demos look better. Two weeks later, support tickets spike because a downstream workflow breaks on subtle formatting shifts, and a retrieval step starts returning less relevant context. Nothing in the application code changed, so the usual test suite stays green. This is not a model failure. It is an evaluation failure. Enterprise LLM evaluation is shifting from model-centric, one-time accuracy checks to application-centric, continuous evaluation pipelines that run like CI/CD. The change is driven by production failure modes that accuracy scores do not capture, alongside growing emphasis on auditability, safety testing, drift monitoring, and adversarial resilience.| Early LLM evaluation relied on static benchmarks and surface-level similarity metrics developed for translation and summarization. These approaches can misalign with enterprise risk, particularly for hallucinations, subtle reasoning failures, and safety issues that do not surface as obvious lexical differences. Production deployments introduced additional reliability problems tied to nondeterministic outputs, multi-step pipelines (especially RAG, and evolving attack surfaces such as prompt injection and data extraction. The convergence across 2025 and 2026-era tooling is toward continuous evaluation as an engineering discipline: offline regression suites, trace-based datasets, drift monitoring, and automated safety and adversarial tests integrated into developer workflows. How the mechanism works Modern evaluation stacks are multi-dimensional and continuous. They combine several types of checks that map more closely to how LLM applications fail in production. 1. Offline regression suites wired into CI/CD Instead of running a benchmark once, teams maintain golden datasets and scenario suites that run on each change to prompts, model versions, retrieval logic, and routing policies. Tooling in this space includes CI/CD support, version-to-version comparisons, and automated evaluation execution. 2. Trace-centric observability that turns production into test data Several platforms emphasize tracing and converting production interactions into datasets. This enables continuous monitoring, faster regression reproduction, and targeted improvements to the evaluation suite based on real failures. 3. LLM-as-a-judge plus human calibration LLM-as-a-judge has become a common mechanism for evaluating subjective qualities such as faithfulness, relevance, coherence, and rubric-based criteria at scale. Known judge biases exist, including sensitivity to response order and preference effects. Mitigation patterns include pairwise comparisons, multiple judges, and human review for calibration or high-risk decisions. 4. Drift detection, including RAG-specific failure modes For RAG systems, evaluation extends to the retrieval layer. “Embedding drift” is a failure mode where the retrieval space or query distribution shifts over time, causing silent degradations. For example, imagine a retrieval index that is not updated after a product line is renamed: queries using the new terminology start surfacing stale or irrelevant chunks, and generation quality degrades silently for weeks before anyone traces it back to the retrieval layer. Monitoring approaches include distance and distribution tests (cosine distance, Euclidean distance, MMD, KS test), plus architectural mitigations such as hybrid retrieval (dense plus lexical) and re-ranking steps before generation. 5. Adversarial and security evaluation as a gate AI red teaming is distinct from patching deterministic software vulnerabilities. The focus is on probabilistic weaknesses and layered controls. Adversarial testing covers prompt injection, jailbreaking, data extraction, and denial of service (including token exhaustion and cost-based attacks). Some evaluation approaches use attack success rate thresholds as deployment gates. Analysis Three forces are pushing evaluation toward industrialization.First, accuracy-only metrics are increasingly treated as insufficient proxies for enterprise quality and risk, particularly in high-stakes domains where factual grounding and safety matter more than surface similarity. Second, the application layer has become the unit of reliability: prompts, retrieval, tool calls, routing, and guardrails can regress independently of model weights. Third, governance pressure is rising, with evaluation artifacts increasingly positioned as evidence rather than diagnostics, especially where systems must be auditable over time. In practice, this shifts evaluation from a pre-release checklist to an operational control loop: generate test cases from failures, gate changes in CI/CD, monitor drift and safety in production, and preserve traceability across versions. What good looks like A mature evaluation pipeline is less a tool and more a workflow. A change to a system prompt triggers an automated regression run. Flagged results require human review before the change is merged. Production traces from last week’s incidents are already in next week’s test suite. The evaluation history is preserved and queryable, not discarded after each release. Implications for enterprises Operational 1. Release governance becomes measurable. Prompts, routing rules, retrieval indexes, and model versions can be treated as change-controlled artifacts with regression gates, not informal configuration. 2. Faster incident response. Trace-based datasets and evaluation replays shorten time-to-diagnosis when behavior changes without code changes. 3. Cost and latency become first-class metrics. Some platforms track token usage, latency, and throughput alongside quality, enabling explicit trade-offs and budgeting controls as part of evaluation. Technical 1. Evaluation extends beyond the model. Retrieval quality, tool-call correctness, and end-to-end workflows need evaluation, not just response text. 2. Security testing shifts left. Prompt injection resistance, jailbreak susceptibility, and data leakage checks can become routine evaluation cases, with newly discovered failures becoming permanent tests. 3. Instrumentation becomes infrastructure. OpenTelemetry-native tracing and gateway patterns position telemetry as a prerequisite for both evaluation and governance evidence. Risks and open questions 1. Judge reliability and bias. LLM-as-a-judge introduces systematic biases and may require ongoing calibration against human-labeled sets to remain defensible. 2. Adversarial coverage limits. Red teaming can reduce risk but may not cover the full space of possible prompt-based attacks, especially as systems integrate more tools and data sources. 3. RAG drift observability. Drift detection methods can flag distribution shifts, but operational thresholds and false positive management remain an engineering and governance challenge. 4. Audit trail scope and retention. Regulatory-oriented expectations for logs and decision reconstruction raise implementation questions about metadata capture, storage, and access controls for sensitive traces. Further reading Deepchecks — “How to Build an LLM Evaluation Framework in 2025” Prompts.ai — “Best LLM Evaluation Companies To Use In 2026” Maxim AI — “The Best 3 LLM Evaluation and Observability

AI Compliance Is Becoming a Live System The Scenario A team ships an AI feature after passing a pre-deployment risk review. Three months later, a model update changes output behavior. Nothing breaks loudly. No incident is declared. But a regulator asks a simple question: can you show, right now, how you monitor and supervise the system’s behavior in production, and what evidence you retain over its lifetime? The answer is no longer a policy document. It is logs, controls, and proof that those controls run continuously. The Alternative Now consider what happens without runtime controls. The same team discovers the behavior change six months later during an annual model review. By then, the system has processed 200,000 customer interactions. No one can say with confidence which outputs were affected, when the drift began, or whether any decisions need to be revisited. Remediation becomes forensic reconstruction: pulling logs from three different systems, interviewing engineers who have since rotated teams, and producing a timeline from fragmented evidence. The regulator’s question is the same. The answer takes eight weeks instead of eight minutes. The Shift Between 2021 and 2026, AI governance expectations shifted from periodic reviews to continuous monitoring and enforcement. The pattern appears across frameworks, supervisory language, and enforcement posture: governance is treated less as documentation and more as operational infrastructure. There is a turning point in 2023 with the release of NIST AI Risk Management Framework 1.0 and its emphasis on tracking risk “over time.” They also describe enforcement signals across regulators, including the SEC and FTC, that emphasize substantiation and supervision rather than aspirational claims. In parallel, there is also a related shift in data governance driven by higher data velocity and real-time analytics. Governance moves from “after-the-fact” auditing to “in-line” enforcement that runs at the speed of production pipelines. How Governance Posture Is Shifting Risk assessment Pre-deployment, then annual review Ongoing, with drift detection and alerting Evidence Assembled during audits from tickets, docs, and interviews Generated automatically as a byproduct of operations Policy enforcement Manual review and approval workflows Deterministic controls enforced at runtime Monitoring Periodic sampling and spot checks Real-time dashboards with automated escalation Audit readiness Preparation project before examination Always-on posture; evidence exists by default Incident detection Often discovered during scheduled reviews Detected in near real time via anomaly alerts How the Mechanism Works There is a common runtime pattern: deterministic enforcement outside the model, comprehensive logging, and continuous monitoring. Policy enforcement sits outside the model. There is a distinguish between probabilistic systems (LLMs) and deterministic constraints (policy). The proposed architecture places a policy enforcement layer between AI systems and the resources they access. A typical flow includes context aggregation (identity, roles, data classification), policy evaluation using machine-readable rules, and enforcement actions such as allow, block, constrain, or escalate. The phased rollouts: monitor mode (log without blocking), soft enforcement (block critical violations), and full enforcement. Evidence is produced continuously. A recurring requirement is that evidence should be generated automatically as a byproduct of operations: immutable audit trails capturing requests, decisions, and context; tamper-resistant logging aligned to retention requirements; and lifecycle logging from design through decommissioning. The EU AI Act discussion highlights “automatic recording” of events “over the lifetime of high-risk systems as an architectural requirement. Guardrails operate on inputs and outputs. The runtime controls including input validation (prompt injection detection, rate limiting by trust level) and output filtering (sensitive data redaction, hallucination detection). Monitoring treats governance as an operational system. The monitoring layer includes performance metrics, drift detection, bias and fairness metrics, and policy violation tracking. The operational assumption is that governance failures should be detected and escalated promptly, not months later. Data pipelines use stream-native primitives. Kafka is for append-only event logging, schema registries for write-time validation, Flink is for low-latency processing and anomaly detection, and policy-as-code tooling (Open Policy Agent) to codify governance logic across environments. Why This Matters Now Two forces drive the urgency. First, regulatory and supervisory language is operationalizing “monitoring.” The expectations are focused on whether firms can monitor and supervise AI use continuously, particularly where systems touch sensitive functions like fraud detection, AML, trading, and back-office workflows. Second, runtime AI and real-time data systems reduce the value of periodic controls. Where systems operate continuously and decisions are made in near real time, quarterly or annual reviews become structurally misaligned. Implications for Enterprises Operational: Audit readiness becomes an always-on posture. Governance work shifts from manual review to control design. New ownership models emerge, with central standards paired with local implementation. Incident response expands to include governance events like policy violations and drift alerts. Technical: A policy layer becomes a first-class architectural component. Logging becomes a product requirement, tying identity, policy decisions, and data classifications into a single auditable trail. Monitoring must cover both AI behavior and system behavior. CI/CD becomes part of the governance boundary, with pipeline-level checks and deployment blocking tied to policy failures. Risks and Open Questions There are limitations that enterprises should treat as design constraints: standardization gaps in what counts as “adequate” logging; cost and complexity for smaller teams; jurisdiction fragmentation across regions; alert fatigue from continuous monitoring; and concerns that automated governance can lead to superficial human oversight. What This Means in Practice The shift is not a future state. Regulatory language, enforcement patterns, and supervisory expectations are already moving in this direction. The question for most enterprises is not whether to adopt continuous governance, but how quickly they can close the gap. Three questions worth asking now: Governance is becoming infrastructure. Infrastructure requires design, investment, and ongoing operational ownership. Treating it as paperwork is increasingly misaligned with how regulators, and AI systems themselves, actually operate. Further Reading

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

Retrieval Is the New Control Plane A team ships a RAG assistant that nails the demo. Two weeks into production, answers start drifting. The policy document exists, but retrieval misses it. Permissions filter out sensitive content, but only after it briefly appeared in a prompt. The index lags three days behind a critical source update. A table gets flattened into gibberish. The system is up. Metrics look fine. But users stop trusting it, and humans quietly rebuild the manual checks the system was supposed to replace. This is the norm, not the exception. Enterprise RAG has an awkward secret: most pilots work, and most production deployments underperform. The gap is not model quality. It is everything around the model: retrieval precision, access enforcement, index freshness, and the ability to explain why an answer happened. RAG is no longer a feature bolted onto a chatbot. It is knowledge infrastructure, and it fails like infrastructure fails: silently, gradually, and expensively. The Maturity Gap Between 2024 and 2026, enterprise RAG has followed a predictable arc. Early adopters treated it as a hallucination fix: point a model at documents, get grounded answers. That worked in demos. It broke in production. The inflection points that emerged: One pattern keeps recurring: organizations report high generative AI usage but struggle to attribute material business impact. The gap is not adoption. It is production discipline. The operational takeaway: every bullet above is a failure mode that prototypes ignore and production systems must solve. Hybrid retrieval, reranking, evaluation, observability, and freshness are not enhancements. They are the difference between a demo and a system you can defend in an incident review. How Production RAG Actually Works A mature RAG pipeline has five stages. Each one can fail independently, and failures compound. Naive RAG skips most of this: embed documents, retrieve by similarity, generate. Production RAG treats every stage as a control point with its own failure modes, observability, and operational requirements. 1. Ingestion and preprocessing Documents flow in from collaboration tools, code repositories, knowledge bases. They get cleaned, normalized, and chunked into retrievable units. If chunking is wrong, everything downstream is wrong. 2. Embedding and indexing Chunks become vectors. Metadata gets attached: owner, sensitivity level, org, retention policy, version. This metadata is not decoration. It is the enforcement layer for every access decision that follows. 3. Hybrid retrieval and reranking Vector search finds semantically similar content. Keyword search (BM25) finds exact matches. Reranking sorts the combined results by actual relevance. Skip any of these steps in a precision domain, and you get answers that feel right but are not. 4. Retrieval-time access enforcement RBAC, ABAC, relationship-based access: the specific model matters less than the timing. Permissions must be enforced before content enters the prompt. Post-generation filtering is too late. The model already saw it. 5. Generation with attribution and logging The model produces an answer. Mature systems capture everything: who asked, what was retrieved, what model version ran, which policies were checked, what was returned. Without this, debugging is guesswork. Where Latency Budgets Get Spent Users tolerate low-single-digit seconds for a response. That budget gets split across embedding lookup, retrieval, reranking, and generation. A common constraint: if reranking adds 200ms and you are already at 2.5 seconds, you either cut candidate count, add caching, or accept that reranking is a luxury you cannot afford. Caching, candidate reduction, and infrastructure acceleration are not optimizations. They are tradeoffs with direct quality implications. A Hypothetical: The Compliance Answer That Wasn’t A financial services firm deploys a RAG assistant for internal policy questions. An analyst asks: “What’s our current position limit for emerging market equities?” The system retrieves a document from 2022. The correct policy, updated six months ago, exists in the index but ranks lower because the old document has more keyword overlap with the query. The assistant answers confidently with outdated limits. No alarm fires. The answer is well-formed and cited. The analyst follows it. The error surfaces three weeks later during an audit. This is not a model failure. It is a retrieval failure, compounded by a freshness failure, invisible because the system had no evaluation pipeline checking for policy currency. Why This Is Urgent Now Three forces are converging: Precision is colliding with semantic fuzziness. Vector search finds “similar” content. In legal, financial, and compliance contexts, “similar” can be dangerously wrong. Hybrid retrieval exists because pure semantic search cannot reliably distinguish “the policy that applies” from “a policy that sounds related.” Security assumptions do not survive semantic search. Traditional IAM controls what users can access. Semantic search surfaces content by relevance, not permission. If sensitive chunks are indexed without enforceable metadata boundaries, retrieval can leak them into prompts regardless of user entitlement. Access filtering at retrieval time is not a nice-to-have. It is a control requirement. Trust is measurable, and it decays. Evaluation frameworks like RAGAS treat answer quality like an SLO: set thresholds, detect regressions, block releases that degrade. Organizations that skip this step are running production systems with no quality signal until users complain. A Hypothetical: The Permission That Filtered Too Late A healthcare organization builds a RAG assistant for clinicians. Access controls exist: nurses see nursing documentation, physicians see physician notes, administrators see neither. The system implements post-generation filtering. It retrieves all relevant content, generates an answer, then redacts anything the user should not see. A nurse asks about medication protocols. The system retrieves a physician note containing a sensitive diagnosis, uses it to generate context, then redacts the note from the citation list. The diagnosis language leaks into the answer anyway. The nurse sees information they were never entitled to access. The retrieval was correct. The generation was correct. The filtering was correctly applied. The architecture was wrong. What Production Readiness Actually Requires Operational requirements: Technical requirements: Five Questions to Ask Before You Ship If any answer is “I don’t know,” the system is not production-ready. It is a demo running in production. Risks and Open Questions Authorization failure modes. Post-filtering is risky if

Why Your LLM Traffic Needs a Control Room A team deploys an internal assistant by calling a single LLM provider API directly from the application. Usage grows quickly. One power user discovers that pasting entire documents into the chat gets better answers. A single conversation runs up 80,000 tokens. Then a regional slowdown hits, streaming responses stall mid-interaction, and support tickets spike. There is no central place to control usage, reroute traffic, or explain what happened. As enterprises move LLM workloads from pilots into production, many are inserting an LLM gateway or proxy layer between applications and model providers. This layer addresses operational realities that traditional API gateways were not designed for: token-based economics, provider volatility, streaming behavior, and centralized governance. There is a clear evolution. Early LLM integrations after 2022 were largely direct API calls optimized for speed of experimentation. By late 2023 through 2025, production guidance converged across open source and vendor platforms on a common architectural pattern: an AI-aware gateway that sits on the inference path and enforces usage, cost, routing, and observability controls. This pattern appears independently across open source projects (Apache APISIX, LiteLLM Proxy, Envoy AI Gateway) and commercial platforms (Kong, Azure API Management), which suggests the requirements are structural rather than vendor-driven. While implementations differ, the underlying mechanisms and tradeoffs are increasingly similar. When It Goes Wrong A prompt change ships on Friday afternoon. No code deploys, just a configuration update. By Monday, token consumption has tripled. The new prompt adds a “think step by step” instruction that inflates completion length across every request. There is no rollback history, no baseline to compare against, and no clear owner. In another case, a provider’s regional endpoint starts returning 429 errors under load. The application has no fallback configured. Users see spinning loaders, then timeouts. The team learns about the outage from a customer tweet. A third team enables a new model for internal testing. No one notices that the model’s per-token price is four times higher than the previous default. The invoice arrives three weeks later. These are not exotic edge cases. They are the default failure modes when LLM traffic runs without centralized control. How the Mechanism Works Token-aware rate limiting LLM workloads are consumption-bound rather than request-bound. A gateway extracts token usage metadata from model responses and enforces limits on tokens, not calls. Limits can be applied hierarchically across dimensions such as API key, user, model, organization, route, or business tag. The research describes sliding window algorithms backed by shared state stores such as Redis to support distributed enforcement. Some gateways allow choosing which token category is counted, such as total tokens versus prompt or completion tokens. This replaces flat per-request throttles that are ineffective for LLM traffic. Multi-provider routing and fallback Gateways decouple applications from individual model providers. A single logical model name can map to multiple upstream providers or deployments, each with weights, priorities, and retry policies. If a provider fails, slows down, or returns rate-limit errors, the gateway can route traffic to the next configured option. This enables cost optimization, redundancy, and resilience without changing application code. Cost tracking and budget enforcement The gateway acts as the system of record for AI spend. After each request completes, token counts are multiplied by configured per-token prices and attributed across hierarchical budgets, commonly organization, team, user, and API key. Budgets can be enforced by provider, model, or tag. When a budget is exceeded, gateways can block requests or redirect traffic according to policy. This converts LLM usage from an opaque expense into a governable operational resource. Streaming preservation Many LLM responses are streamed using Server-Sent Events or chunked transfer encoding. Gateways must proxy these streams transparently while still applying governance. A core challenge: token counts may only be finalized after a response completes, while enforcement decisions may need to happen earlier. Gateways address this through predictive limits based on request parameters and post-hoc adjustment when actual usage is known. A documented limitation is that fallback behavior is difficult to trigger once a streaming response is already in progress. Request and response transformation Providers expose incompatible APIs, schemas, and authentication patterns. Gateways normalize these differences and present a unified interface, often aligned with an OpenAI-compatible schema for client simplicity. Some gateways also perform request or response transformations, such as masking sensitive fields before forwarding a request or normalizing responses into a common structure for downstream consumers. Observability and telemetry Production gateways emit structured telemetry for token usage, latency, model selection, errors, and cost. There is an alignment with OpenTelemetry and OpenInference conventions to enable correlation across prompts, retrievals, and model calls. This allows platform and operations teams to treat LLM inference like any other production workload, with traceability and metrics suitable for incident response and capacity planning. Multi-tenant governance The gateway centralizes access control and delegation. Organizations can define budgets, quotas, and permissions across teams and users, issue service accounts, and delegate limited administration without granting platform-wide access. This consolidates governance that would otherwise be scattered across application code and provider dashboards. Prompt Lifecycle Management and Shadow Mode As LLM usage matures, prompts shift from static strings embedded in code to runtime configuration with operational impact. A prompt change can alter behavior, cost, latency, and policy compliance immediately, without a redeploy. For operations teams, this makes prompt management part of the production control surface. In mature gateway architectures, prompts are treated as versioned artifacts managed through a control plane. Each version is immutable once published and identified by a unique version or alias. Applications reference a logical prompt name, while the gateway determines which version is active in each environment. This allows updates and rollbacks without changing application binaries. The lifecycle typically follows a consistent operational flow. Prompts are authored and tested, published as new versions, and deployed via aliases such as production or staging. Older versions remain available for rollback and audit, so any output can be traced back to the exact prompt logic in effect at the time. Shadow mode

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