标签：#m

A practical, end-to-end walkthrough of taking a read-only slice of an enterprise source system and exposing it to an AI agent as a set of Model Context Protocol (MCP) tools — using Azure Logic Apps, API Management, and Agent Foundry. All identifiers below are placeholders; swap in your own. The goal We wanted a simple outcome: a user asks a business question in plain language and gets a straight answer — no dashboards, no field names, no training on the underlying system. That means an AI agent with safe, read-only access to a backend system of record, exposed as discrete tools the model can call. The constraints shaped every decision: Read-only. The agent can retrieve and analyze, never write. Safe. Records in most business systems contain free text (notes, subjects, descriptions) that could carry prompt-injection payloads. Tool output must be treated as data, never instructions. Composable. The agent should see many small, well-described tools — "list records", "aggregate by category", "record change history" — not one giant "query the system" tool. The architecture Five layers, one direction of flow: Agent (Agent Foundry) │ MCP (JSON-RPC over HTTP) ▼ MCP server (API Management) │ REST operation per tool ▼ API gateway (API Management) │ single POST, routed by body ▼ Tool executor (Logic App) │ OAuth token + REST calls ▼ Source system (REST API) The key design choice: one backend endpoint, many logical tools. The Logic App exposes a single HTTP trigger that accepts { "tool": "records.list", "parameters": { ... } } and routes internally. API Management then fans that single endpoint out into many named operations, and its MCP feature turns those operations into agent tools. This keeps the backend trivial to maintain while the agent still sees a rich, typed tool catalog. Step 1 — Design the tools Start from the questions , not the schema. A useful toolset usually falls into a few families: Records: list / get / search / filter for the core business entities. Activity

GitHub announced enterprise-managed OpenTelemetry export for Copilot activity from VS Code and Copilot CLI on July 8, 2026. Primary source: GitHub Changelog, July 8, 2026 . Export availability is only the start. The receiving collector becomes an enterprise ingress point. This is an unexecuted operating plan; signal types, attributes, endpoint requirements, and controls must be checked against current GitHub documentation. Isolate the path managed clients -> private telemetry ingress -> dedicated OTel Collector pool -> field policy + bounded queue -> dedicated backend dataset Do not point every developer client directly at the primary observability backend. Give the collector write-only destination credentials, separate its dataset from production application telemetry, and define retention before rollout. Isolation is not anonymity. Stable user, device, organization, or repository identifiers may still be sensitive. Start with a field budget Category Initial policy Product and version Keep bounded values Operation and status Keep documented enums Timing and counts Keep numeric measures Raw prompts or generated code Drop by default File paths and repository URLs Drop or transform after review User identity Prefer scoped pseudonymous identity Free-form errors Drop raw text; keep reviewed classes These categories are recommendations, not a description of GitHub's payload. Inspect a restricted canary before naming actual keys. processors : memory_limiter : check_interval : 1s limit_mib : 512 spike_limit_mib : 128 attributes/field_budget : actions : # Illustrative keys only; replace after payload review. - key : user.email action : delete - key : file.path action : delete - key : command.arguments action : delete batch : send_batch_size : 512 timeout : 5s Verify processors against the chosen Collector distribution. A valid startup does not prove that records satisfy policy. Drill three failures Backend outage: block the exporter. Retries must be bounded, queue growth vi

OpenAI published an audit of SWE-Bench Pro on July 8, 2026 and estimated that roughly 30% of its tasks are broken. The reported issues make a familiar leaderboard assumption unsafe: every task in the denominator is a valid, equally interpretable trial. Primary source: OpenAI, “Separating signal from noise in coding evaluations” . The operational response should not be “ignore all benchmarks.” It should be: version task validity, preserve disputed cases, and publish how conclusions change across plausible denominators. Model task state separately from model result task validity: unreviewed | valid | broken | disputed model result: pass | fail | infrastructure_error | missing Never convert infrastructure_error to model failure without reporting that policy. Never delete broken tasks while retaining an old score label. A row needs provenance: { "task_id" : "repo-issue-17" , "dataset_revision" : "sha256:..." , "harness_revision" : "git:..." , "model_config" : "immutable-config-id" , "validity" : "disputed" , "result" : "pass" , "review_revision" : 3 , "evidence" : [ "fixture.log" , "review.json" ] } Publish three denominators Let: P_v , N_v : passes and total among reviewed-valid tasks; P_a , N_a : passes and total across all attempted tasks; D : disputed tasks. Report: valid-only score = P_v / N_v all-attempted score = P_a / N_a uncertainty interval = score if every disputed task hurts conclusion .. score if every disputed task helps conclusion This interval is not a statistical confidence interval. It is a sensitivity bound for unresolved task validity. A tiny sensitivity calculator #!/usr/bin/env python3 import json , sys rows = [ json . loads ( line ) for line in open ( sys . argv [ 1 ]) if line . strip ()] valid = [ r for r in rows if r [ " validity " ] == " valid " ] disputed = [ r for r in rows if r [ " validity " ] in ( " unreviewed " , " disputed " )] attempted = [ r for r in rows if r [ " result " ] in ( " pass " , " fail " )] rate = lambda passed , total : pa

OpenAI introduced GPT-Live on July 8, 2026 and describes it as a full-duplex voice architecture: it can listen and speak at the same time. GPT-Live-1 and GPT-Live-1 mini are rolling out in ChatGPT Voice, while API availability was described as coming later. Primary source: OpenAI, “Introducing GPT-Live” . Full duplex changes the mobile failure surface. The app may hold microphone input, play output, detect interruptions, and continue background work concurrently. A polished desk demo does not answer what happens when a phone call arrives, Bluetooth disconnects, the app backgrounds, or permission changes. This is the test plan I would run before shipping a full-duplex voice workflow. It is a plan, not a report of measured GPT-Live API behavior. Record the environment device : " physical device model" os : " exact OS version" app_build : " immutable build" voice_model : " product/model label visible during test" audio_route : " speaker | wired | bluetooth" network : " wifi | 5g | constrained" battery_start : " percent" low_power_mode : false microphone_permission : granted background_permission : " record actual setting" A result without device, route, and network context is difficult to reproduce. Define observable states idle -> connecting -> listening <-> speaking -> reconnecting -> paused_by_system -> ended -> error Track three channels separately: audio input — is the microphone active? audio output — what route is speaking? task state — is a delegated/background operation still running? The UI should never imply “listening” after the OS revoked microphone access. Interruption sequence Use a harmless scripted conversation and timestamp every event: T+00 connect on phone speaker T+10 user speaks while assistant is speaking T+20 switch to Bluetooth headset T+35 background the app for 30 seconds T+65 return to foreground T+80 trigger an incoming call or system audio interruption T+95 decline/end interruption T+110 disable microphone permission in Settings T+130 retu

OpenAI's July 14 guidance for managing AI investments recommends five moves: improve visibility into usage and spend, evaluate efficiency by outcome ROI, govern advanced workflows before scaling, fund workflows that compound, and match capacity to proven demand. Primary source: OpenAI, “How to manage AI investments in the agentic era” . The hard part is the denominator. “This agent used $800” says little. “This workflow cost $14 per accepted reconciliation, including review and rework” can support a decision. Here is a one-page ledger I would require for an agent pilot. Define one accepted outcome Do not start with tokens, seats, or tasks launched. Define the business state that counts after review. workflow : vendor-invoice-reconciliation accepted_outcome : " invoice matched, exceptions reviewed, result posted" owner : finance-ops pilot_window_days : 21 minimum_sample : 100 invoices quality_gate : false_postings : 0 exception_recall : " >= 0.98" reviewer_minutes_p50 : " <= 3" A generated draft is not an outcome if a person must rebuild it. An agent run is not successful if its result never enters the system of record. Capture the complete cost AI cost + orchestration and observability + human review + rework + incident handling + allocated implementation cost = total workflow cost Use a table with declared variables: Variable Meaning Example only C_model model and tool-call spend $600 C_platform workflow infrastructure $200 H_review reviewer hours 35 R_hour loaded reviewer rate $45 C_build pilot build cost allocated to window $2,000 N_accept accepted outcomes 850 total = C_model + C_platform + H_review * R_hour + C_build cost_per_accepted_outcome = total / N_accept With the illustrative numbers, total cost is $4,375 , or about $5.15 per accepted outcome. These are not benchmark claims; replace every value with measured data. Compare against the real baseline The baseline must use the same unit and quality gate: Metric Manual baseline Agent pilot attempted invoices

The label that gets the sequence backwards "AI-first" has become a branding exercise....

This article is my submission for the Agents of SigNoz Hackathon: Blog Track, where participants...

submitted by /u/fagnerbrack [link] [留言]

There are beginner mistakes. Then there are "I spent three days doing the wrong thing" mistakes. This is one of mine. When I first joined a company as a trainee, I was excited... and completely unprepared for real-world software development. Back in college, our web development classes mostly covered HTML and CSS. We did touch a bit of programming, but if I'm being honest, many of our projects involved copying code, tweaking a few lines, and hoping everything still worked. I graduated knowing how to make things look nice , but not necessarily how professional development teams solved problems. Reality hit pretty quickly. Our First Task A few days into training, my friend and I were assigned our first real task by our senior team lead. He gave us an Excel file. It had two sheets , each with roughly 1,000 rows of data. Every row had around 7 to 10 columns . Then he said something like: "Import all of this into the database." Simple enough... right? Well... Neither of us had ever imported data into a database before. Asking the Wrong Person Instead of asking our team lead for clarification, we asked another trainee who happened to be our former classmate. His advice? "Just make an INSERT INTO script." Perfect. Say no more. Without questioning it, my friend and I started generating SQL INSERT statements. One row. After another. After another. And another. By the end, we had spent almost three days creating what felt like an endless wall of SQL. At the time, we were actually proud of ourselves. "Look at us. Future software engineers." Looking back... We were basically expensive copy-paste machines. The Reality Check Our senior team lead eventually came over to check our progress. He looked at our SQL file for a few seconds. Then smiled and said: "You tricked me, huh? That's not what I meant." My friend and I just stared at him. Confused. We thought, "But... the data is going into the database. Mission accomplished, right?" Wrong. What he actually wanted was a CakePHP scr

Flutter State Management in 2026: Riverpod vs Bloc vs Provider in Production Every Flutter team eventually hits the same wall. The app works, the demo looks great, and then somewhere around screen thirty the setState calls start colliding with each other, a widget rebuilds three times for one tap, and nobody on the team can explain why a loading spinner is stuck on a screen the user already navigated away from. That's the moment state management stops being a "nice to have" architectural decision and becomes the thing standing between you and a shippable product. We've built and maintained Flutter apps across fintech, e-commerce, logistics, and healthcare — different domains, wildly different feature sets, but the same recurring question from every engineering lead we work with: Riverpod, Bloc, or Provider? There's no shortage of opinions online, and most of them are shallow — "Bloc is too much boilerplate," "Riverpod is the future," "Provider is basically deprecated." None of that is useful when you're the one who has to live with the decision for the next two years of feature work. This is a practitioner's comparison, not a popularity contest. We'll walk through what each of these actually does under the hood, where each one falls apart in production, and how we decide which one to reach for on a new project. Why state management is the architecture decision that matters most In most application frameworks, state management is one of several important decisions. In Flutter, it's disproportionately important, because Flutter's entire rendering model is built around widget rebuilds driven by state changes. Get state management wrong and you don't just get messy code — you get a slow app, because unnecessary rebuilds are a real performance cost, not just an aesthetic one. There are three problems every state management approach in Flutter has to solve: Where does state live , and how does a widget deep in the tree access state that was created somewhere else? How do

Update: This investigation spawned a complete stress-testing toolkit. See the apktool-diagnostics repo for the full tool with security scanning, round-trip validation, and fuzzing setup. The Setup I was deep into a project stress-testing apktool — the standard tool for decompiling and rebuilding Android APKs — hunting for real bugs to fix, not hypothetical ones. While digging through recent issues and advisories, I ran across a patched vulnerability: CVE-2026-39973 , a path traversal bug that let a malicious resources.arsc make apktool write decoded files outside the intended output directory. Already fixed upstream. Advisory published. Case closed, according to everyone else. I didn't believe it until I broke it myself. Why "already patched" wasn't good enough Advisories describe what should happen. They don't prove it. And a tool like apktool has one job that matters more than any other: you point it at a file you don't trust — someone else's APK — and it processes that file on your machine. If the sanitization it depends on for that trust boundary can silently regress in a refactor (which is exactly what happened here — a PR reorganizing resource-file-path construction dropped the call to BrutIO.detectPossibleDirectoryTraversal() without anyone noticing), then "patched now" only tells you about today. It doesn't tell you the mechanism actually holds, and it doesn't tell you what "vulnerable" concretely looks like on your own machine, with your own files. So instead of writing "confirmed CVE-2026-39973, see upstream fix" and moving on, I decided to reproduce it myself, end to end. Building both sides of the fence Step one: build apktool twice from source — once at v3.0.1 (the last vulnerable tag), once at current HEAD (post-fix). Now I had a vulnerable binary and a patched binary sitting side by side, and no more reason to trust anyone's summary of what the difference actually did. Step two: I needed a malicious input. The vulnerability lived in how ResFileDecoder

El ecosistema de agentes autónomos está evolucionando. Mientras la atención se centra en modelos y frameworks, empiezan a aparecer proyectos que cubren necesidades operativas básicas: comunicación, almacenamiento, finanzas. Aquí van cinco que vale la pena observar. 1. Apumail: el correo nativo para agentes Apumail ofrece direcciones de email que los agentes pueden crear y leer mediante una API REST plana. El contenido se negocia automáticamente: texto plano para agentes, HTML para humanos. Señal relevante: es el primer intento serio de darle a un agente un buzón de correo con el mismo estándar que usamos los humanos, sin adaptadores. Si los agentes empiezan a gestionar correspondencia, este tipo de servicio será indispensable. 2. RogerThat: chat entre agentes Una capa de mensajería en tiempo real diseñada para que agentes conversen entre sí. RogerThat no es un chat humano con bots, sino un canal donde los agentes coordinan acciones. Contexto: si varios agentes intervienen en un mismo workflow, necesitan un bus de eventos. RogerThat plantea que ese bus puede ser un chat, con las garantías de entrega y orden que eso implica. 3. DOBI: agente para DePIN y activos del mundo real Agent autónomo que opera sobre la cadena para gestionar infraestructuras físicas descentralizadas (DePIN). Ejecuta acciones on-chain a partir de decisiones tomadas por el modelo. Patrón: no es un simple bot de trading; apunta a mantenimiento de equipos, comprobación de sensores, distribución de incentivos. La frontera entre software y hardware se desdibuja. 4. CIDIF: financiamiento de I+D para agentes Plataforma que automatiza la presentación y seguimiento de solicitudes a fondos de innovación. El agente rellena formularios, adjunta documentación y trackea el estado. No obvio: la burocracia gubernamental es un entorno altamente estructurado (pocas decisiones abiertas, muchos campos fijos). Es un terreno ideal para agentes, aunque el ruido político lo opaque. 5. Orquesta: orquestación de flujos mu

HTML Forms and the <form> Tag HTML forms are used to collect information from users through a webpage. They are commonly found in login pages, registration forms, contact forms, search bars, and online shopping websites. The <form> tag acts as the main container that groups different form elements together. When a user submits the form, the browser collects the entered data and prepares it to be sent to a server. <form> <label for= "name" > Full Name </label> <input type= "text" id= "name" name= "fullname" > <button type= "submit" > Submit </button> </form> Understanding the action and method Attributes The action attribute specifies where the form data should be sent after submission. This destination is usually called an endpoint . The method attribute defines how the data is sent. The GET method sends data through the URL, while the POST method sends data inside the request body, making it suitable for sensitive information. <form action= "/submit" method= "post" > <input type= "text" name= "username" > <button type= "submit" > Submit </button> </form> Understanding Common Form Attributes The <form> tag supports several attributes that control its behavior. Attributes such as autocomplete , target , enctype , novalidate , and accept-charset improve the user experience and define how the browser handles form data before and after submission. <form action= "/submit" method= "post" autocomplete= "on" target= "_self" > </form> How an HTML Form Works When a user enters information and clicks the Submit button, the browser collects all form data and sends it to the location specified by the action attribute using the HTTP method defined in method . The server processes the request and returns a response to the browser. <form action= "/login" method= "post" > <input type= "email" name= "email" > <input type= "password" name= "password" > <button type= "submit" > Login </button> </form> Why HTML Forms Are Important HTML forms make websites interactive by allowing users t

I want to start with a moment most of us have lived through. It's 3 a.m. A dashboard is red. You're eight terminals deep in grep , trying to work out which service actually fell over and why. And the whole time there's this nagging feeling that you're doing archaeology on a system you wrote last month. Here's what got under my skin about it. The answer was never actually lost. Back in the source code it said, in plain terms, that the payment service talks to Postgres through a connection pool. That this retry backs off three times. That this particular dependency is external and you must never, ever try to "just restart it." That was all right there at build time. Then we packaged everything up, deployed, threw that structure in the bin, and asked a sleep-deprived human to reconstruct it from log lines. That gap bugged me enough that I spent a while building something around it. This post is about that. Autoscaling is good at the wrong problem We've gotten genuinely good at reacting to resource pressure. Traffic climbs, a box gets slow, CPU pins, and the autoscaler adds capacity or sheds load. No complaints there, it's kept things running for years. The problem is it has no idea what your app is for . It can't tell a service that's slow because it's healthy and hammered from a service that's fast because it's quietly writing garbage to the database. It never had a model of the application in the first place. So a whole category of failures just sails right past it. A connection pool getting drained by something downstream. A poison message kicking off a retry storm. A schema change that breaks one code path and leaves the other one looking perfectly fine. Infrastructure that only thinks in CPU and memory is blind to all of that. The "throw an LLM at it" era The going answer right now is to bolt a large language model onto your observability stack. Fire hose all the logs, traces, and metrics at a big central model and ask it what happened. I get why. I also think it'

In 1995, Netscape released SSL. The web didn't really take off commercially until then. Before SSL, you couldn't trust a website with your credit card. After SSL, e-commerce exploded. AI agents are at the same inflection point in 2026. Here's why. The problem Agents are starting to call each other autonomously. Each hop is a trust decision. But agents have no way to verify each other. Today, when Agent A calls Agent B: Is Agent B who it claims to be? No way to verify Has Agent B been audited for security? No standard Has Agent B's key been compromised? No revocation mechanism This is exactly where the web was in 1994. No SSL, no trust, no commerce. The analogy Web (1995) Agents (2026) HTTP (transport) A2A + MCP (transport) No HTTPS = can't trust No ATC = can't trust SSL certificate ATC Trust Card Certificate Authority MarketNow Sentinel CA Revocation list (CRL) /api/atc?action=verify What I built ATC (Agent Trust Card) — SSL certificates for AI agents. How it works Agent registers with MarketNow CA CA signs the agent's identity with Ed25519 Agent presents its ATC to other agents Other agents verify the signature with the CA public key If compromised, the CA revokes the ATC Real cryptography (not a mock) Ed25519 signatures (RFC 8032) CA private key in Vercel env var (never exposed) CA public key committed to public GitHub repo Every ATC persisted as signed JSON in _data/atc/ Anyone can verify signatures offline using crypto.verify Sentinel integration The ATC's trust score comes from Sentinel — the 8-layer security audit pipeline: L1.5: metadata checks L1.6: Semgrep + secrets + OSV L1.7: binary/malware detection L1.8: malware family signatures (Emotet, Cobalt Strike, etc.) The positioning MarketNow is not competing with A2A or MCP. It's the trust layer that sits on top: ATC (Trust Layer) <- MarketNow A2A / MCP (Transport Layer) <- Google / Anthropic HTTP / WebSocket (Network) <- Standard Every agent with an A2A card can have an ATC Trust Card. Every MCP skill can hav

In my last post, I walked through a RAG pipeline that answers questions from a company policy document. The next question I wanted to answer: what happens when I want other AI systems to use that same capability, without hardcoding a Python import? That's what pulled me into building an MCP server. In this article, I will explain how I built a custom MCP server that exposes tools to AI agents and how this architecture enables more powerful enterprise AI applications. What is MCP? Model Context Protocol is an open protocol that standardizes how AI applications communicate with external tools and data sources. Instead of creating custom integrations for every AI application, MCP provides a common interface where servers expose tools that AI clients can discover and invoke. Technology Stack Python, MCP SDK, Ollama / Local LLM, AI Agent Client, FastAPI (optional integration). What's actually in the server I built this with FastMCP, and it currently exposes four tool categories: Calculator tools — calculator_add and calculator_multiply. search_company_documents — the RAG agent from my last project, but now reached over HTTP instead of a direct function call. The MCP tool sends a request to the RAG agent's FastAPI /search endpoint and returns the answer. This one requires an api_key parameter. get_employee_leave — looks up an employee's remaining PTO from an in-memory store. Simple lookup, no external calls. get_ticket_information — same pattern, returning ticket status, assigned team, and priority. Each tool is registered with a @mcp .tool() decorator, which is what makes FastMCP genuinely pleasant to work with. Challenges I Encountered The calculator, employee, and ticket tools were straightforward pure functions with no external dependencies. The RAG search tool was a different problem entirely, and it was the hardest part of this whole project. My RAG agent runs as its own FastAPI service, on its own process, with its own vector store loaded into memory. The MCP serve

The defense secretary’s idea of administering testosterone therapy to service members of the US Armed Forces reveals little understanding of the complexity of hormones.

You subscribed to newsletters because you wanted to read them. Then they landed in Gmail, between a password reset and a calendar invite, and reading stopped being the point. Surviving the inbox became the point. Readwise Reader fixes the environment problem. It is a read-later app with a proper feed, highlighting, and offline sync. The setup below gets every newsletter you care about flowing into it automatically. Everything in the first four sections works with no product of mine involved; there is a disclosed plug at the end. Step 1: Find your two Reader addresses Every Reader account comes with two custom email addresses, not one: an address ending in @library.readwise.io an address ending in @feed.readwise.io Mail sent to the library address lands in your Library, the place for things you have committed to reading. Mail to the feed address lands in your Feed, the triage stream you skim and pick from. Readwise recommends the feed address for newsletter subscriptions and forwarding rules, and the library address for one-off documents. That split is worth respecting. A newsletter is a candidate, not a commitment. To find both addresses in the web app, click the + button in the bottom left and choose "More import options". On mobile they are listed under Settings. You can also rename them ("Personalize email addresses" on the Add to Library page) if the random string bothers you. Two caveats from Readwise's own docs: a guessable address can attract spam, and if you personalize a second time, the previous personalized address goes dead. Step 2: New subscriptions go straight to Reader From now on, when you subscribe to a newsletter, put your feed address in the signup box. No forwarding, no filters. The issue arrives in your Feed and never touches your inbox. Two mechanical notes: There is no allowlist to manage. Anything sent to the address gets in, which is the opposite of the Kindle personal-documents dance. If a newsletter uses double opt-in, the confirmation ema

Your agent feels fast during a demo. Then a real session reaches twenty turns, several tools have returned large payloads, and every response starts taking longer and costing more. This pattern is often called token drift : the effective input context grows as an agent carries more conversation history, tool output, retrieved documents, and state into each model call. The model itself is not gradually becoming less efficient. The application is asking it to process more material on every turn. Token drift is manageable, but only if context is treated as a budgeted system resource rather than an unlimited transcript. What Token Drift Actually Means Most conversational agents build each request from several sources: a system prompt, tool definitions, recent messages, retrieved context, durable memory, and sometimes a summary of older work. Whether the application sends that state on every request or a provider manages part of it, the model still has an effective context to process. Consider an illustrative session: Turn Effective input What changed 1 1,200 tokens System prompt, tools, and one user message 8 6,900 tokens Conversation history and two tool results 20 18,400 tokens More history, retrieved documents, and accumulated state The exact price and latency depend on the model, provider, cache behavior, and workload. The important signal is the trend: later calls repeatedly process a larger context. Why Agents Accumulate Tokens So Quickly Conversation history is only one source of growth. Production agents often accumulate tokens in several places at once: Repeated transcripts: Every prior user and assistant message remains in context. Tool schemas: Large tool descriptions and JSON schemas may be attached to every model call. Tool results: Search results, stack traces, database rows, and API responses can be much larger than the user's request. Retrieved documents: RAG pipelines sometimes add too many chunks or keep stale retrieval results across turns. Retries an

On July 14, 2026, the Linux Foundation stood up the x402 Foundation — neutral governance for the protocol that lets AI agents pay each other over HTTP 402. The member list is the entire payments industry: Visa, Mastercard, Amex, Stripe, AWS, Google, Cloudflare, Coinbase, Circle, Ripple, Shopify, and two dozen more. Read the launch release end to end and one thing is missing. There is no conformance suite. No security profile. No certification program. No validation procedure. The industry just gave agent payments a standards home and standardized the rails — not the proof that the payment an agent executed was the one it was authorized to make. This is a pattern, not a one-off. Standards bodies standardize the protocol. The conformance surface lags — and the security surface lags behind that. It happened with MCP. The protocol matured fast; the testing of it arrived later and is still catching up. It is happening again with x402, on a compressed timeline, with more money behind it. The gap matters because a signed, well-formed record is not the same thing as a true one. Look at what landed in the research this month. ShareLock (arXiv 2606.27027 , Liu et al., June 2026) distributes a malicious instruction as benign-looking secret shares across several MCP tool descriptions using a Shamir threshold scheme. Each fragment passes per-tool inspection. The payload reconstructs only when the shares are aggregated, after a quiet trigger during a server update. The paper reports an average attack success rate above 90% against tool-description detectors. Every individual record was valid. The composite was hostile. A conformance check that validates each tool description in isolation passes the whole attack straight through. That is the shape of the coming problem for agent payments. Signed receipts, content-addressed evidence records, canonicalized envelopes — the industry is converging on the format of trustworthy agent evidence fast, and getting that format ratified inside