MCP's July 28 Spec Revision Eliminates Protocol-Level Sessions
The Model Context Protocol's 2026-07-28 specification revision makes its biggest architectural change since launch: eliminating protocol-level sessions in favor of a stateless core. Previously, MCP servers had to maintain per-session state for each connected client, which became a scaling headache in cloud deployments fronted by load balancers that can't reliably route repeat requests to the same backend instance. Under the new model, protocol version, client identity, and capability information travel in a _meta parameter with every request instead of being pinned to a session — a pattern similar to how the Claude Messages API treats each request as self-contained. Routing information now lives in HTTP headers alongside the JSON-RPC payload, so infrastructure can route requests without inspecting message bodies or tracking session state at all.
The revision also formally deprecates several features: sampling, roots (filesystem location tracking), and verbose logging are all on the way out, and the Tasks feature — previously used for long-running operations — has been moved out of the core spec and into an optional extension. Deprecated features remain functional for a minimum of 12 months, but backward compatibility with older clients isn't guaranteed once a server adopts the new spec. For teams using official SDKs, the upgrade path should be straightforward; for anyone who rolled their own MCP server or client implementation, expect meaningful rework — an Anthropic representative quoted alongside the announcement put it bluntly: custom implementations are in for "a lot of uplift to make this correct."
Read more — The Register
Ten Agentic AI Deployment Anti-Patterns Teams Keep Repeating
A widely-circulated breakdown of agentic AI deployment failures argues that most programs don't stall because the underlying model is too weak — they stall because the deployment around the model repeats a small set of predictable mistakes. The three flagged as critical: tool-call chaos, where teams expose broad internal APIs to an agent without permission boundaries (the recommended fix is to treat every tool exposed to an agent like a public API — minimum permission, explicit allowlist, audit log, starting from an empty list and adding only what's needed); silent-upgrade regression, where pinning an agent to a "latest" model alias means behavior can shift unreviewed whenever a vendor pushes a new snapshot, which should instead be treated as a version bump requiring eval-gated review like any other dependency upgrade; and observability-after-launch, where teams skip trace IDs, prompt capture, and tool-call telemetry until an incident forces the issue, by which point failures can't be reconstructed.
Further down the severity list: shipping prompt or model changes without CI-gated regression tests (even a ten-prompt fixture set with a pass/fail threshold beats nothing), governance policies that live in a wiki page but aren't enforced anywhere in code or runtime, flipping a feature flag from zero to full production traffic in one deploy instead of shadow-testing duplicate traffic first, and editing prompts directly in a vendor console instead of keeping them in version control where they can be code-reviewed like any other production artifact. The piece's broader argument is that postmortems which blame "the model hallucinated" usually miss the real root cause, since the deployment layer — prompts, tool definitions, eval sets, governance — is where most of these failures actually originate.
Read more — Digital Applied
Safe & Secure AI Agent Practices
Docker's Credential-Leak Case Study: What Coding Agents Handed Attackers in the s1ngularity Incident
Docker published a technical walkthrough of the s1ngularity supply-chain attack, using it as a concrete case study for why coding agents need filesystem isolation. The attack shipped a malicious version of the Nx build package — which has roughly 4 million weekly downloads — with a post-install script that scanned for credentials in .env files, SSH keys, cloud config, and npm/GitHub tokens. Rather than writing its own credential scanner, the script detected whichever AI coding CLI was already installed on the machine and invoked it directly with permission-bypass flags: --dangerously-skip-permissions for Claude Code, --yolo for Gemini CLI, and --trust-all-tools for Amazon Q. It then prompted the agent to recursively search the home directory for credential files and write the results to a local inventory file, which it base64-encoded and pushed to public GitHub repositories under the victim's own account — then used the stolen GitHub tokens to flip additional private repositories public, compounding the exposure. The result: 2,349 distinct secrets leaked across 1,079 compromised repositories, with over 1,100 credentials still valid when researchers analyzed the incident. GitGuardian's 2026 State of Secrets Sprawl report separately found that AI-assisted code leaks credentials at roughly twice the baseline rate of hand-written code.
Docker's argument is that this attack only works because typical agent setups run as the developer, with full filesystem access to .env files, ~/.ssh, and ~/.aws, live credentials sitting in the working context, and no isolation layer between a model's decision and shell execution. Docker Sandboxes address this with two properties: the agent's filesystem view is scoped to the project workspace only, so per-user config outside that boundary — including the home directory and .env files — simply isn't visible to the VM; and credentials are stored in the host OS keychain and injected by a proxy at the network boundary as requests leave the sandbox, so the agent only ever holds a placeholder value, never the real secret. Replayed against this architecture, the same reconnaissance script that harvested thousands of credentials in the wild would find nothing to steal.
Read more — Docker
Microsoft's Least-Privilege Framework Treats Every Agent as a First-Class Identity
Microsoft published a detailed least-privilege framework for AI agents, arguing that agents need to be treated as first-class principals with a dedicated identity rather than sharing credentials or reusing existing service accounts. Each agent should have a unique principal with a named human owner and an explicit stated purpose, which enables real accountability and normal identity lifecycle management — onboarding, credential rotation, and suspension — instead of a shared secret nobody can trace back to a responsible party.
On top of identity, Microsoft recommends task-based RBAC roles scoped to discrete workflows (for example, "read-only knowledge retrieval" as a distinct role from "create draft ticket") rather than broad team-level permission sets, with read and write operations kept separate and high-impact actions like deletion gated behind a step-up approval. Permissions should be constrained across three boundaries simultaneously: the resource boundary (which tenant or subscription), the data boundary (which collection or sensitivity level), and the operation boundary (read vs. write vs. export) — with just-in-time elevation granting narrowly-scoped privileges only for the duration of a specific workflow rather than standing access. The framework also calls for end-to-end audit logging that captures agent identity, role, scope, resource, action, and a correlation ID for every operation, plus periodic aggregate permission analysis, since several individually-reasonable roles can combine into an unexpectedly high-impact chain of access when granted to the same agent.
Read more — Microsoft Security Blog
Docker Joins Nvidia's Open Secure AI Alliance
Docker announced it is joining Nvidia's Open Secure AI Alliance, a collaborative initiative building trust, security, and governance frameworks for agentic AI systems across the industry. Docker's framing is that intelligence comes from the model, but trust comes from the runtime, identity, governance, and security surrounding it — and that as customers deploy more agents in production, they need confidence those agents will behave predictably and stay within well-defined boundaries regardless of which model vendor sits behind them. Docker's contribution centers on runtime security for agent execution environments, governance and identity tooling for deterministic control over agent behavior, and support for routing between open-weight and proprietary frontier models without customers needing to rearchitect their applications for each one. The alliance's broader pitch to developers is that no single vendor controls trust in the agentic AI stack — it has to be built collectively, through shared runtime and governance standards rather than per-vendor lock-in.
Read more — Docker
