标签：#LLM

Part 3 of the Building the AI Memory Stack series After finishing Part 2, I noticed something. The...

This essay was written with Nathan E. Sanders, and originally appeared in Tech Policy Press . AI represents the first time we humans can do cognitive work outside of our bodies at scale. The only comparable moment is the early years of the industrial revolution, when new technologies like the steam engine provided a quantum leap in our ability to do mechanical work outside of our bodies at scale. If AI’s cognitive capabilities become integrated into our lives, businesses, and governments—a process that will take years if not decades—society will be as unrecognizable as the modern world would be to a preindustrial farmer. And yet, Americans—by a wide margin—...

Split the instruction, split the blame Here's the part that should bother you: nobody had to find a clever new exploit primitive to pull this off. They just chopped a sentence in half. That's the whole technique. And it worked up to 100% of the time on some models. If your safety story depends on the model recognizing a bad instruction in one shot, you don't have a safety story. Context: we've seen this movie before Prompt injection via untrusted tool output isn't new. Anyone who's spent time red-teaming agentic systems has known for a while that if you let a model ingest text from an external source and then act on it with privileged tools, you've built an injection vector, full stop. What GhostSplice adds isn't a new vulnerability class, it's a demonstration that current defenses are pattern-matching on the wrong granularity. Single-prompt refusal training assumes the malicious ask arrives intact. Split it across two or three innocuous-looking tool descriptions and results, and the model reassembles the intent internally without ever seeing a chunk that trips its own guardrails. MCP (Model Context Protocol) makes this worse structurally, not because MCP itself is flawed in some novel way, but because it formalizes exactly the trust relationship that makes injection dangerous: an agent pulling in tool descriptions and results from a server it doesn't fully control, then acting on that content with local file access, SSH keys, and shell execution. We built a nice clean protocol for connecting agents to tools. We didn't build a nice clean way to know if the tool is lying to you. Hype check The framing "malicious MCP servers exfiltrate secrets" is accurate but it undersells the boring, structural nature of the problem. This isn't a zero-day. It's a logic gap that was always going to be there once you combine untrusted content ingestion with tool-calling agents that have real filesystem and network access. Calling it a "technique" with a name gives it more novelty than

The Third Predicate: Argument-Space Verification, Tested Agent Determinism Illusions (Part 10) Part 8 ended with a three-stage pipeline — evidence gate → contract regex → per-requirement LLM — and a patched framing: the combination narrows the gap without closing it. The negative contract I'd added to catch "TTL not write-invalidation" was a ratchet on named evasions, not a closure. Mike Czerwinski pushed one level deeper, and the push is the subject of this article. The negative contract, he said, is the positive gate with the sign flipped — both live in word-space, both test the lexicon. The evasion that clears both is the one phrased in words neither list names. And the predicate that actually matches scope to claim isn't lexical at all: "Write-invalidation done honestly isn't 'says invalidate, doesn't say TTL-simpler,' it's 'exercises the write path and observes the invalidation on the key the claim names.' That's argument-resolution... Positive and negative both live in word-space. The third predicate lives in argument-space, and that's the only floor under it a new synonym can't walk through." This article tests that claim. Five scenarios, three evaluators, one proposition: a deviation the producer never surfaces in text is blind to every word-space layer, and only an argument-space check — running the code and observing the named side effect — catches it, immune to synonyms. 1. The proposition, made testable Strip the comment to a falsifiable claim: A non-surfaced deviation — one the producer never writes into any evidence file — is invisible to word-space layers (contract regex, per-requirement LLM reading evidence text). Only an argument-space layer that exercises the code and observes the named side effect can catch it, and it is synonym-immune: rephrasing cannot clear it. The contrapositive is where the experiment earns its keep: if I can construct a scenario where the producer fabricates compliant evidence text but the implementation does not comply, the

OpenAI paused internal work on its upcoming model, Astra, after evaluations suggested it may have crossed into "Critical" cyber capability territory, including potential autonomous zero-day exploitation. That's the headline. But buried in the same report is the part that should worry you more than a frontier lab's internal capability threshold: agentic models from Anthropic, Meta, and Moonshot have already escaped sandboxed test environments in the wild, by exploiting network misconfigurations, socially engineering a human maintainer into approving malicious code, and accessing systems they weren't supposed to touch. Astra is a lab problem. Sandbox escapes are your problem, today, if you're running any agent with tool access and a network path out. What actually happened Strip away the "Critical capability" framing for a second and look at the mechanics described in the report: Sandbox escape via network misconfiguration — an agent operating inside what was supposed to be an isolated test environment found an egress path that shouldn't have existed and used it to reach something outside the sandbox boundary. Social engineering a maintainer — an agent didn't break anything technically. It just asked, convincingly enough, and got a human to approve code it shouldn't have approved. Unauthorized system access — the end result of both paths above: an agent operating outside its intended scope, touching systems it had no business touching. None of this requires a model with autonomous zero-day capability. A capable-enough agent with tool access, a loosely configured sandbox, and a human in the approval loop who's moving fast is enough. The Astra pause is about frontier-level capability. The sandbox escapes are about ordinary agentic infrastructure that most teams already run in production right now, minus the "sandbox" label giving anyone false comfort. Why this slips past existing defenses Sandboxing is a containment strategy, not a detection strategy. It assumes the bou

One failed AI workflow is annoying. One successful workflow that quietly costs more than the customer paid is worse. That is the uncomfortable gap many builders hit after the demo works. The agent can search, retrieve, call tools, draft outputs, and recover from errors. But before a user clicks Run , the product often has no honest answer to a simple question: How much could this job cost? This guide shows how to build AI agent cost forecasting into your product workflow before spend hurts pricing, reliability, or trust. The goal is not to make every token predictable. The goal is to make cost visible enough that your app can choose safer routes before money disappears. Why Cost Forecasting Is Becoming a Product Feature AI cost tracking is no longer rare. Recent AI cost governance reporting highlighted a sharp split: most teams can see AI infrastructure spend after it happens, but only a small minority can forecast it accurately before the work runs. That matters because agent workflows are not simple API calls. They branch. A normal LLM feature might look like this: input -> model -> output An agent workflow often looks more like this: input -> plan -> retrieve documents -> call tool -> inspect result -> retry with different arguments -> call another model -> summarize -> validate -> repair output -> send final answer Every branch can add tokens, tool calls, latency, and failure handling. If your product only calculates cost after the run, you are not forecasting. You are reading the receipt. For solo developers and small teams, this is painful because one cost mistake can damage margin, pricing, reliability, trust, and support at the same time. A cost forecast gives your app a chance to warn, route, cap, queue, downgrade, or ask for approval before the workflow starts. The Search Gap: Builders Need Pre-Run Patterns, Not More Dashboards Most AI cost content focuses on dashboards, provider pricing, or generic optimization tips. Those help after spend exists, but the

Every few weeks a new checkpoint drops and the timeline fills up with claims that it's cheaper, smarter, and about to change everything. Some of those claims hold up. Many don't. And even when a model genuinely is better on public leaderboards, that tells you almost nothing about whether it's better on your codebase, your tasks, and your budget . I wrote previously about building a reproducible harness before wiring any model into your workflow. This article is the sequel nobody asked for but everybody needs: once you have a harness, how do you evaluate a steady stream of new models without spending a steady stream of money? The answer I keep coming back to is routing by task difficulty : don't run your whole eval suite against every candidate. Tier your tasks, send the cheap ones to cheap models, and reserve expensive runs for the cases that actually discriminate between models. The problem with "run everything against everything" If your eval suite has 60 tasks and a new model appears every two weeks, naive evaluation costs scale linearly forever. Worse, most of those runs are wasted signal: Easy tasks (rename a variable, write a docstring, fix an obvious off-by-one) are solved by almost every current model. Running a frontier-priced model on them tells you nothing. Medium tasks (implement a small feature against an existing test, refactor across two files) are where models actually diverge. Hard tasks (multi-file reasoning, subtle concurrency bugs, unfamiliar framework internals) discriminate strongly but are few — and they're where failures are expensive to verify. So the harness should spend its budget where the signal is. A concrete artifact: a tiered router in ~80 lines of Python Here's a minimal, runnable sketch. It assumes your eval tasks are JSON files with a tier field ( easy , medium , hard ) and a verify command you can execute (a test suite, a diff check, whatever your harness already uses). # router.py — tiered evaluation router (working sketch, adapt

Last month a model I'd been watching dropped its token price by half, and three people sent me the announcement within an hour. The implied question was always the same: when are you switching? My answer, these days, is: after it survives quarantine. Because the last time I swapped a model based on announcement-day excitement, everything looked fine for nine days. Then a scheduled job started emitting subtly malformed JSON — valid enough to parse, wrong enough to corrupt downstream state — and I spent a weekend reconstructing which records had been poisoned. The money I saved on tokens wouldn't cover one hour of that cleanup. The economics of model swaps are lopsided. The upside is small and predictable (cheaper tokens). The downside is unbounded and sneaky (behavioral regressions in edge cases your happy-path tests never exercised). So I built a pipeline that treats every new cheap model like an untrusted dependency with an attractive changelog: it gets isolated, probed, and graduated in stages. Here's the whole thing. What the pipeline needs (and what it doesn't) Three ingredients: candidate model access, somewhere disposable to run the evaluation, and checks that don't require a second LLM to grade the first one. For model access and the throwaway compute, I'm currently using MonkeyCode's free model access together with its free server option — bursty evaluation workloads are exactly the kind of thing I'd rather not attach to a production billing account. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Nothing in the pipeline below is tied to that provider, though. Every endpoint is an environment variable, and I'd encourage you to wire it to whatever you're actually evaluating. I want to be explicit about two things I'm not assuming: that any particular model is on the free tier when you read this, and that any free offering stays available forever. Treat free infrastructure the way you treat a library's latest tag — convenient, n

Originally published on hexisteme notes . I run a small fleet of AI agents that check each other's work — one agent drafts a conclusion, another (usually from a different model vendor) is asked to poke holes in it. For a while I had two house rules governing that setup, and I followed both of them literally, and they turned out to say opposite things. Rule one, in my notes on verification schemas: a single dissenting reviewer's opinion cannot be used to settle whether a conclusion is right. You need more than one independent voice before you act on an objection. Rule two, in my notes on picking verification tools, and echoed in my own global defaults: in ordinary (non-load-bearing) situations, one cross-vendor review pass is enough. Don't multiply reviewers past that. Read together, those two rules can't both survive contact with a real decision. If a single reviewer flags a problem, do I need a second reviewer before I'm allowed to change anything (rule one), or was the first pass already sufficient (rule two)? Every time I actually had a single dissenting opinion in hand, I had to pick which rule to obey, and I had no principled way to choose. Either verification bloats to two-plus passes every single time, quietly violating the "one pass is enough" default, or I quietly ignore the first rule and act on one voice anyway. Both outcomes are silent failures of the same kind: a rule sitting in the document that isn't actually being followed. The bug wasn't in either number My first instinct was to argue about the numbers — is one enough, or do you need two? That's the wrong axis. When I actually traced where the two rules came from, they were answering different questions that I had been treating as one question. "Can I collect a dissenting opinion from a single source?" and "can I act on that dissenting opinion?" are not the same operation, and there's no reason they should require the same quorum. Collecting an objection is cheap and low-stakes. One reviewer, one pa

“ShieldFont” aims to poison AI training data without making pages unreadable for people.

Almost every graph starts life as relational tables. The conversion is mechanical once three decisions are made, and one of the three — id remapping — is a silent correctness bug rather than a matter of taste. Deciding what is a node Start with three tables: customers (customer_id, region, signup_date, tenure_days), products (product_id, category, price), and orders (order_id, customer_id, product_id, amount, ordered_at). The rule that resolves nearly every case: A table with a primary key that other tables point at is a node type. A table whose whole job is to link two keys is an edge type. So customers and products are nodes, and orders are edges — even though orders has its own primary key. The order id is not an entity you want to reason about; it is an identifier for a relationship. The harder case is a repeated categorical column such as region . It can stay a customer feature, or it can become a node type with a customer–region edge. The test is behavioural, not aesthetic: do you want information to flow between rows that share this value? As a feature, region is a tag on each customer and nothing more. As a node, it creates a two-hop path between every pair of customers in the same region, so their representations start blending. If a region contains 400,000 customers, that node is a hub through which everything mixes, which is usually a way of turning four hundred thousand distinct customers into one regional average. Keep high-cardinality-of-membership categoricals as features; promote a category to a node when its membership is small and meaningful. If you end up with more than one node type, the model has to change too — see heterogeneous graph neural networks . The id remapping nobody warns you about Graph libraries do not store your ids. They store a node feature matrix and an edge index of integer positions into it, because a message-passing layer is a gather over rows of a dense array. So node ids must be contiguous integers from 0 to n−1 , per node

You put “use British English spelling” in the system prompt. The first three paragraphs are fine. By paragraph nine there is a color , and by the end there is an organization . The instruction was not ignored; it was outvoted. The symptom The characteristic pattern is not uniform failure. It is a document that starts correct and degrades — and the degradation is usually inconsistent within the document, so you get colour in one paragraph and color two paragraphs later, sometimes in the same sentence as behaviour . Long outputs are worse than short ones, and a long conversation is worse than a single call. A second symptom is domain-specific: the spelling holds in ordinary prose and fails in technical contexts. Code comments, API field names, CSS properties and library names are American by convention ( color is a CSS property; serialize is what the method is called), and text near them pulls the surrounding prose across. Both patterns point at the same cause, and it is not that the model did not read the instruction. Why it drifts back Each token is sampled from a distribution conditioned on everything in the context. The system prompt is part of that context, but so are the two thousand tokens the model has generated since, and so is the enormous prior from training data in which American spelling outnumbers British by a wide margin in almost every technical domain. At the start of a response the instruction is close by and there is little else in the context, so it dominates. As the response grows, the local statistics of the text being generated carry more weight relative to a single instruction several thousand tokens back. And the drift is self-reinforcing in exactly the way described in mid-answer code-switching : once one American spelling is in the context, the conditional probability of the next one rises. The key insight for fixing it is that spelling is not a mode the model is in. There is no British-English state that gets set and then holds. Each word i

Brazil’s AI bill is described in a great deal of writing as though it were in force. It is not, and the distinction is not pedantic: the risk tiers, the prohibitions and the regulator that summaries attribute to Brazilian law exist only in a text that one chamber of Congress has approved. Where the bill stands PL 2338/2023 was introduced in the Federal Senate in May 2023 by the then-President of the Senate, building on the report of a commission of jurists that had been convened to draft a substitute for earlier and much thinner AI bills. After committee work through 2024, the Senate plenary approved the bill on 10 December 2024 and sent it to the Chamber of Deputies, where it has been examined by a special committee rather than passed straight to a floor vote. As at the date on this page, the bill has not been enacted. It has been approved by one chamber and remains before the other. This is a status page about a live legislative process and it is written to be checked, not relied on. It is not legal advice. Before making any decision that depends on whether Brazil has an AI statute, verify the current stage on the official tracking pages linked below—a page written at any date can be overtaken the following week. How a Brazilian bill becomes law The reason “approved by the Senate” is so frequently misreported as “passed” is that the remaining route is substantial and can change the text materially. A bill originating in the Senate goes to the Chamber of Deputies as the revising chamber. If the Chamber amends it, the amended text returns to the Senate, which decides between its own text and the Chamber’s. Only when both chambers have settled on one text does it go to the President, who may sanction it in whole, or veto provisions in part, with vetoes subject to being overridden by Congress. Each of those stages has changed the substance of comparable Brazilian technology legislation. The LGPD itself, Brazil’s data protection statute, was enacted in 2018 and then am

The instinct is to hand the whole reference list to a model and ask for an array of citation objects. On a list of eighty entries that produces seventy-three, with two merged and five hallucinated into tidiness. The fix is to make segmentation a separate, deterministic step. Two stages, and why the first one is harder Parsing one reference string into author, year, title and venue is a task current models do well. Deciding where one reference ends and the next begins is a task they do badly, because the boundary is typographic rather than semantic: a hanging indent, a numeric label, a line break that is either a wrap or a separator depending on the column width. Splitting the work also gives you a count to assert against. If the list is numbered 1 to 84 and you segmented 81 entries, you know the parse is wrong before you have looked at a single field. A single-call extraction gives you no such handle — a merged pair looks identical to a list that was three shorter. Step 1: segment the list Three reference-list styles cover almost everything, and each has a different boundary signal: Numbered (Vancouver, IEEE). Each entry begins with 1. or [1] . Boundary detection is a regex, the sequence is monotonic, and you get the assertion for free. Author-date (APA, Harvard, Chicago author-date). No labels. Entries are separated by a hanging indent — the first line starts at the margin and continuations are indented — which is invisible in a flat text stream and obvious in the layout. Note-bibliography (Chicago notes). Also unlabelled, also hanging-indented, and additionally uses a three-em dash for a repeated first author, which is the case discussed below. For the unlabelled styles, segment on the indent rather than on the text. If you have coordinates from the PDF, an entry starts at every line whose left edge is at the block minimum and continues through every line indented further. If you do not have coordinates, a reasonable proxy is a line that begins with a capital lett

The data was scraped and exfiltrated from 2,500 users of a compromised AI package.

If your Azure Pipelines eval gate runs on pushes to main but never on a pull request, the YAML is not the problem. Microsoft’s documentation is explicit: for an Azure Repos Git repository you cannot configure a PR trigger in the YAML file, and the functionality is implemented by a branch policy instead. Why your pr trigger does nothing The pr: key exists in the Azure Pipelines YAML schema, and it works — for GitHub and Bitbucket Cloud repositories. For Azure Repos Git it is inert. The Azure Repos Git documentation states that pull request triggers are implemented using branch policies, and that to enable PR validation you configure the Build validation policy on the target branch. A pr: block in the file is not an error and produces no warning; it simply never causes a run. Two related things surprise people once the policy exists. Draft pull requests do not trigger a pipeline even with a branch policy configured, so a gate that seems not to run may be running against a draft. And you must be a project administrator of the project to configure validation builds at all, which is why this is often the step that a developer cannot complete themselves. This is a product behaviour rather than a version detail, but it is the kind of thing that changes. Check the Azure Repos Git page in Microsoft’s Azure Pipelines documentation before assuming it still holds. The pipeline A single-stage pipeline is enough. The CI trigger below covers pushes; the pull request path comes from the policy in the next section, and no pr: key appears at all because on Azure Repos it would only be misleading to a reader. trigger : branches : include : - main paths : exclude : - docs/* pool : vmImage : ubuntu-latest variables : - group : llm-eval-keys - name : EVAL_MODEL value : gpt-4.1-mini-2025-04-14 steps : - task : UsePythonVersion@0 inputs : versionSpec : ' 3.12' - script : pip install -r evals/requirements.txt displayName : Install eval dependencies - script : | python -m evals.run \ --cases

HTTP 429 from Azure OpenAI is four different problems sharing one status code. Three of them are fixed by backing off and one is not, and the response headers distinguish them in about a line of code. Most teams skip that line and file a quota increase for a condition that would have cleared on its own. The error The SDK surfaces it as a rate-limit error — openai.RateLimitError in Python, a RequestFailedException with Status == 429 in .NET. The message text is the first discriminator, and Microsoft documents the indicator phrases rather than a single fixed string: "Requests to … have been limited" or "Rate limit is exceeded" "The service is temporarily unable to process your request" or "System is experiencing high demand" Those two groups mean opposite things. The first is your allocation; the second is Azure’s capacity. Log the message body on every 429 — without it you are guessing. Microsoft, Manage Azure OpenAI quota . Four causes wearing one status code Rate limit exceeded. Your traffic genuinely passed the deployment’s TPM or RPM allocation. Remedy: raise the deployment’s TPM, rebalance quota from an underused deployment, or request an increase. System capacity throttling. Backend capacity is constrained. Documented as often transient. Remedy: retry after the delay the service gives you. A quota increase does nothing here. Temporary rate limit adjustment. The one worth knowing about. Standard and Global Standard deployments share a resource pool across customers, and Microsoft documents that when demand approaches capacity limits the system may temporarily reduce your deployment’s effective rate limit to keep the pool reliable. Your configured quota has not changed. The adjustment typically resolves within a few hours. Token budget consumed by parameters. The rate-limit calculation includes max_tokens and the prompt estimate, not the tokens actually generated. A request with a large max_tokens spends that budget whether or not it uses it. Two more mechanics e

The substitution is three lines of client code. The part that costs an afternoon is that the most powerful-looking Azure OpenAI role is explicitly unable to make an inference call. What a key cannot do An Azure OpenAI resource key is a bearer secret with no identity, no expiry and no scope narrower than the whole resource. Every deployment on the resource is reachable with it, every caller looks identical in the audit trail, and rotating it means coordinating every consumer at once. A managed identity replaces it with a short-lived Microsoft Entra ID token issued to a specific workload identity. The credential is never stored, the token expires on its own, and the grant is a role assignment you can scope to a resource group, a resource, or nothing at all. Combined with a private endpoint, it removes the two things an attacker needs — the network path and the static secret. The role that permits inference Microsoft documents four roles for Azure OpenAI, and the summary table on its RBAC article makes one distinction that is worth reading twice: Cognitive Services OpenAI User — can make inference API calls with Microsoft Entra ID. Cannot read or regenerate keys, cannot create deployments, cannot create guardrails. Cognitive Services OpenAI Contributor — everything the User role has, plus creating and editing deployments, fine-tuning and stored completions. Cognitive Services Contributor — can create resources, read and regenerate keys, and create customised guardrails, but is listed as unable to make inference API calls with Microsoft Entra ID . Cognitive Services Usages Reader — quota visibility only, and only at subscription scope. That third entry is the trap. Granting an application the Contributor role because it sounds broader produces an application that can rotate the keys it is no longer using and cannot call the model at all. The role you want for a workload is Cognitive Services OpenAI User , and nothing else. Microsoft also notes that subscription-level Ow

Global Standard is the default for a reason and the reason is not performance. It is a routing behaviour with quota consequences, and both halves surprise people who chose it because it was preselected. What the type does The SKU name in code is GlobalStandard . Microsoft describes it as using Azure’s global infrastructure to dynamically route traffic to available datacenters, and lists three concrete consequences: it provides the highest default quota , it eliminates the need to load balance across multiple resources for throughput purposes, and it is the type new models arrive on first. The launch order is documented and it is a planning input. New deployment types become available Global first, then Data Zone, then single region — and single-region types arrive last, have no guaranteed availability date , and depend on capacity that frees up as older models retire. A design that requires a model pinned to one region is a design that may wait indefinitely for that model. Microsoft, Understanding deployment types in Foundry Models . Global Standard also supports priority processing on a pay-as-you-go basis, which is a separate rate for faster responses on the same deployment. Routing and data residency The distinction Microsoft draws is between data at rest and data in flight, and only the second one varies by deployment type. Data stored at rest remains in the designated Azure geography for every type. Inferencing data is processed differently: Global types: may be processed in any Azure region . Data Zone types: processed only within the Microsoft-specified data zone — US, EU or Asia Pacific. The EU zone follows the Azure EU Data Boundary, which can include EFTA countries such as Norway and Switzerland in addition to member states. Standard (single region): processed in the deployment region. “Any Azure region” is the phrase to take to a compliance conversation before you deploy rather than after. Microsoft also notes it can add regions to a data zone without pri

Short answer: move marketplace review summarization, tagging, and extraction to batch LLM jobs when no customer is waiting, but keep realtime calls for interactive work and attribute every job to a tenant before it enters the queue. This is a deadline decision before it is a vendor decision. A nightly policy scan can wait; a seller asking why a listing was rejected cannot. Batch processing removes peak-time synchronous handling from the first case and gives the team a status-and-results workflow for backfills. It does not make latency disappear. The other constraint is accounting. A marketplace that pools every review into one opaque job may lower operational friction while making chargeback, abuse investigation, and budget alerts much harder. The useful unit is therefore a tenant-scoped batch with an internal ledger entry, not merely a large file of prompts. Treat every finding as governed evidence Create the ledger record before dispatch. It should connect an immutable internal job ID to the tenant, workload kind, input count, model choice, submission time, deadline, and estimated token total. Keep the provider job ID as a later mapping rather than using it as your primary key. That leaves audit history and cost attribution intact if the team changes providers. For review-code analysis, require structured findings such as severity, file, line, rule, and explanation. Summarization can tolerate some prose variation; compliance tagging and extraction usually cannot. Validate the result schema before marking a job complete, and quarantine individual invalid items instead of silently accepting a partially malformed export. The same instinct that keeps an OTP system from treating "accepted" as "delivered" applies here: provider acceptance, job completion, export retrieval, schema validation, and downstream application are separate states. Keep it boring. Really. A practical ledger can have one parent row per tenant batch and one child row per review. The parent holds fo