Anthropic · Claude Managed Agents Platform + 2026 Product/Security Updates (Official Blog Condensed)

One sentence: In the first half of 2026, Anthropic launched Claude Managed Agents(Managed Agents) — you no longer build the infrastructure for "where the agent runs, where state is stored, how permissions are managed, how to adapt to model upgrades" yourself; instead, you rent Anthropic's cloud infrastructure, and only define "what task to do, what tools to use, what boundaries to observe", leaving the rest to it to run. Over six months this platform rolled out 5 capabilities in succession (memory / dreaming / outcomes / multiagent / bring-your-own sandbox + private network tunnels), built on a decoupled three-part design of "brain / hands / session logs". In the same period, the Claude Code desktop app was rebuilt for "one person monitoring multiple agents at once"; Anthropic also published the security containment architecture for three of its products, a checklist for "how to defend when AI speeds up attacks", plus several consumer-facing features: chart visualization / frontend Skills / lifestyle connectors.

When to open this piece

You want to understand what Claude Managed Agents actually is, whose pain points it solves, and whether to use it in your own product (benchmarked against self-built Agent SDK / LangGraph / self-deployed K8s).
You are building long-horizon agent / multi-agent products, and want to know "how memory works across sessions, how agents self-improve, how to let them judge for themselves 'is this good enough'".
You care about enterprise security: where it is safe to run agents, how to avoid leaking credentials, how to defend against prompt injection, which gaps to patch when AI speeds up attackers.
As a PM you want to know what exactly was updated on the Claude product side in 2026(desktop parallel agents / in-conversation interactive charts / lifestyle app connections / frontend aesthetic Skill).

0. First, get this straight: Managed Agents solves the "infrastructure tax", not "model capability"

"Until now, building agents meant spending development cycles on secure infrastructure, state management, permissioning, and reworking your agent loops for every model upgrade." Translation: Before this, building agents meant spending development cycles on security infrastructure, state management, permissions, and rewriting the agent loop every time the model upgraded.

Everyday analogy: You want to open a milk tea shop (= your agent product), and your core competitive advantage is the recipe and taste (= user experience). But before opening, you are forced to first connect water and electricity yourself, install surveillance, get fire safety permits, and hire security (= sandbox / state / permissions / tracing). Managed Agents is equivalent to renting a standard storefront already fitted with water, electricity, fire safety, and security, so you can move in and focus on tuning the recipe.

"Managed Agents pairs an agent harness tuned for performance with production infrastructure to go from prototype to launch in days rather than months." Translation: Managed Agents packages a performance-tuned agent harness with production-grade infrastructure, cutting your time from prototype to launch from "months" to "days".

One-time glossary:

harness (execution framework / scaffold): The "loop" wrapped around Claude — it decides when to call tools, how to manage context, and how to recover from errors.Claude is the brain; the harness is its hands, feet, and on-duty logic.
sandbox: An isolated execution environment where Claude runs code and modifies files; if something breaks, it cannot blow up anything outside.
session: An append-only log of everything that happened from start to finish of a task(append-only log).

The platform has two usage modes,with decreasing control and increasing autonomy:

Traditional prompt-and-response: You manage things granularly; use this when you need tighter control.
outcomes mode: You only write a rubric defining "what counts as success", and Claude iterates on its own until it meets the bar. In internal tests, on "structured file generation" tasks this mode delivered up to 10 percentage points higher task success rate than the standard prompting loop, with larger gains on harder problems.

When to not use Managed Agents: if you only need one-off Q&A and don't need long-horizon runs / tools / state — just call the Messages API or use Claude Code directly. The value of Managed Agents lies in "long-horizon + stateful + production-bound + governed".

1. The five capabilities of Managed Agents (rolled out over six months)

Think of these five blocks as five rooms gradually fitted out in the "rented standard storefront".

1.1 Memory — Let agents learn across sessions (2026-04, public beta)

Pain point: By default, every new session the agent "forgets" and starts over; you can only manually stuff experience back into prompts and skills.

Approach: Memory lives as files on a mounted filesystem, so Claude can read and write memory using the bash + code execution capabilities it is already best at — no separate retrieval infrastructure is built.

"Memory on Managed Agents mounts directly onto a filesystem, so Claude can rely on the same bash and code execution capabilities that make it effective at agentic tasks." Translation: Memory in Managed Agents is mounted directly on the filesystem, so Claude can reuse the same bash and code execution abilities that make it good at agent tasks.

Why "files" instead of a vector database: Files are exportable, manageable via API, rollbackable to old versions, and allow redacting specific segments of history; developers have full control over what the agent remembers. Every change has an audit log (who changed it, in which session), presented in the Console as "session events" for traceability.

Enterprise-grade features: scoped permissions — for example, organization-wide shared libraries are read-only, while per-user libraries are read-write; multiple agents can concurrently read and write to the same library without overwriting each other.

Real-world numbers:

Rakuten's long-running task agent used memory to avoid repeating old mistakes,cutting first-pass error rate by 97%.
Wisedocs(document verification) used cross-session memory to remember recurring document issues,speeding up verification by 30%.
Netflix let agents carry across sessions "insights that took multiple rounds to dig up" and "human corrections made mid-task".

1.2 Dreaming — Let agents self-improve while "sleeping" (2026-05, research preview)

Analogy: People experience a bunch of things during the day (= memory recorded on the spot), and when dreaming at night the brain reviews, distills, and archives, making them smarter the next day. Dreaming is exactly this "sleep review" added to agents.

"Dreaming is a scheduled process that reviews your agent sessions and memory stores, extracts patterns, and curates memories so your agents improve over time." Translation: Dreaming is a scheduled process that reviews an agent's historical sessions and memory banks, distills patterns, and organizes memory, making the agent stronger over time.

It can see things a single agent cannot see on its own: repeated mistakes, workflows that multiple agents independently converge on, team-shared preferences. You can have it update memory automatically, or require human review before changes land.

Memory = each agent records what it learns on the job while working.
Dreaming = refines memory between sessions, aligns cross-agent shared experience, and keeps it fresh.
Together = a sound memory system for "self-improving agents".

In practice:Harvey(legal) used dreaming to let agents remember "file-type workarounds, tool-specific tricks" learned across sessions; in tests completion rate rose roughly 6x.

1.3 Outcomes — Let agents score themselves and redo their work (2026-05)

"With outcomes, you write a rubric describing what success looks like and the agent works toward it. A separate grader evaluates the output against your criteria in its own context window, so it isn't influenced by the agent's reasoning." Translation: With outcomes, you write a rubric describing "what counts as success", and the agent works toward it; an independent scorer evaluates the output against your rubric in its own context window, unaffected by the agent's reasoning process.

Key design = the scorer is physically isolated from the working agent(each uses its own context window), so the scorer is not "swayed by the agent's own arguments" — just as an exam grader cannot be the test-taker themselves. When the bar is not met, the scorer points out exactly what to change, and the agent tries again,with no need for step-by-step human review throughout.

Applicable scenarios: tasks that require "attention to detail + full coverage", as well as subjective quality(whether copy matches brand tone, whether designs follow visual guidelines).

Numbers: up to 10 percentage points higher task success rate than the standard prompting loop; on file generation quality docx +8.4%, pptx +10.1%.

In practice:Spiral by Every's writing agent — the lead agent runs on the cheaper Haiku to take requests and ask clarifying questions, then dispatches drafting to sub-agents running on Opus (parallel drafting when multiple drafts are needed); each draft is scored against "Every editorial principles + user voice" (both pulled from memory),and only drafts that pass the bar are returned. Wisedocs used outcomes to score each verification pass,speeding up review by another 50%.

1.4 Multiagent orchestration — Lead agents dispatch work to specialists (2026-05, research preview)

"When there is too much work for a single agent to do well, multiagent orchestration lets a lead agent break the job into pieces and delegate each one to a specialist with its own model, prompt, and tools." Translation: When the work is too much for one agent to do well, multi-agent orchestration lets a lead agent split the task into chunks and dispatch each chunk to a specialist with its own model/prompt/tools.

Analogy: A project manager (lead agent) splits an investigation into tracks, dispatching them separately to specialists who check deployment history, error logs, metrics, and tickets;the specialists work in parallel on a shared filesystem, and results flow back into the project manager's overall context. The lead agent can check in on any specialist's progress mid-way because events are persisted and each agent remembers what it has done. In the Console you can trace "who did what, in what order, and why".

In practice:Netflix platform team's analytics agent processed logs from hundreds of builds; multiple agents analyzed batches in parallel, surfacing only "recurring patterns worth acting on".

⚠️ This block corresponds to the multi-agent trust escalation risk in the security section (see §6): if sub-agent outputs are treated as "more trustworthy than raw tool results", that instead opens new injection holes. Capability and risk are two sides of the same coin.

1.5 Self-hosted sandboxes + MCP tunnels — Keep execution and data on your turf (2026-05)

This block directly addresses enterprises' biggest concern:"I don't want to hand sensitive files and private network services over to Anthropic's cloud."

"The agent loop that handles orchestration, context management, and error recovery stays on Anthropic's infrastructure, while tool execution moves to your own configured environment." Translation: The agent loop responsible for orchestration, context management, and error recovery stays on Anthropic's infrastructure, while tool execution is moved to an environment you configure yourself.

Self-hosted sandboxes (public beta): The sandbox runs on your own infrastructure, or hosted on Cloudflare / Daytona / Modal / Vercel. Files and repositories never leave your boundary, and you can also configure CPU/memory yourself (for heavy workloads such as long builds and image generation).
MCP tunnels (private network tunnels, research preview): let agents reach your private network MCP servers (internal databases, private APIs, knowledge bases, ticketing systems) without exposing them to the public internet. It relies on a lightweight gateway you deploy that only initiates one outbound connection, no inbound firewall rules required, with end-to-end encrypted traffic.

Terminology:MCP (Model Context Protocol) — an open standard that lets Claude call external tools and access external data.

The four sandbox providers each have different focuses (quick selection reference): Cloudflare (microVM + zero-trust secret injection + auditable egress), Daytona (long-running stateful "fully composable computers" that can be paused/resumed with full state preserved), Modal (sub-second startup, scalable to hundreds of thousands of concurrent instances, on-demand CPU/GPU), Vercel (millisecond-level startup + VPC peering + credential injection at the network boundary so credentials never enter the sandbox).

2. Platform foundation: decoupling the "brain" and "hands" (meta-harness design)

This section is the most hardcore and longest-lived layer of the entire Managed Agents. Understanding it means understanding "why this API can withstand future model/harness replacements." It is the same concept as the 4th category (managed-decoupled) of the "4 types of harness design" discussed in Anthropic Engineering Team First-Party Perspective: Agent Engineering / Skills / MCP / Claude Code (2025–2026 Complete Collection), and we elaborate on it here.

2.1 Starting point: don't raise "pets" (pets vs cattle)

Early on, Anthropic stuffed session / harness / sandbox all into a single container. The benefit was that file editing was just direct system calls, with no service boundaries to design. The downside was falling into an old IT pitfall —raising a "pet":

"a pet is a named, hand-tended individual you can't afford to lose, while cattle are interchangeable. In our case, the server became that pet; if a container failed, the session was lost." Translation note: A pet is a named individual that requires manual care and cannot be lost; cattle, by contrast, are interchangeable. In our case, the server became that pet — once the container went down, the session was gone.

Specifically, there were three problems: ① When a container crashed, the session was lost, and stuck sessions could only be "treated" manually by engineers going in; ② The container held both the harness and user data, so going in to debug was effectively impossible to debug properly; ③ The harness assumed "everything Claude works with lives inside its container", so customers who wanted to connect their own VPC were forced to peer their network with Anthropic's.

2.2 Solution: borrow old wisdom from operating systems — virtualize stable interfaces

"Decades ago, operating systems solved this problem by virtualizing hardware into abstractions—process, file—general enough for programs that didn't exist yet... The read() command is agnostic as to whether it's accessing a disk pack from the 1970s or a modern SSD." Translation note: Decades ago, operating systems virtualized hardware into abstractions like processes and files, general enough to run programs that hadn't been invented yet… the read() command doesn't care at all whether it is reading from a 1970s disk or a modern SSD.

Analogy: The standard for a power outlet is "two/three prongs + 220V". You don't need to care whether the power behind the outlet comes from thermal, hydro, or solar; appliance manufacturers just build to the standard plug. Anthropic splits the agent into three such "standard outlets":

session = the append-only event log.
harness (brain) = the loop that calls Claude and routes Claude's tool calls to the corresponding infrastructure.
sandbox (hands) = the execution environment where Claude runs code and modifies files.

Each of the three can be replaced without disturbing the other two. In Anthropic's own words:"We have strong opinions on the shape of these interfaces, but no opinions on what runs behind them."

2.3 Respective benefits after decoupling the three components

① Containers become "cattle": The harness no longer lives inside the container; instead, it calls the container just like it calls any tool —execute(name, input) → string. When a container dies, the harness catches it as a failed tool call and reports it back to Claude; if Claude wants to retry, it uses the standard recipe provision({resources}) to spin up a new one.No more nursing broken containers.

② The harness also becomes "cattle": Because the session log lives outside the harness, it doesn't matter if the harness crashes —wake(sessionId) restart a new one,getSession(id) retrieve the log, and resume running from the last event.

③ Security boundary (critical): In the old design, untrusted code generated by Claude and credentials lived in the same container,a single prompt injection only needed to trick Claude into reading its own environment variables, and the token would be leaked. The structural fix = make sure tokens can never reach the sandbox where Claude runs code:

Git: Use a repository token to clone during sandbox initialization and connect to the local git remote; afterwards push/pull works inside the sandbox, but the agent itself never touches the token.
Custom tools: OAuth tokens are stored in a vault outside the sandbox; Claude calls MCP tools through a dedicated proxy,the proxy fetches credentials from the vault and then calls external services, and the harness never knows any credentials throughout the process.

④ Session ≠ Claude's context window: Long-running tasks often exceed a single context window. Compaction and trimming both irreversibly discard tokens, but it is very hard to predict "which tokens will be needed in the future". Managed Agents treats the session log as a "context object" that lives outside the context window, and uses getEvents() to fetch slices by position — you can continue reading from where you left off last time, or rewind to a few events before an action to see the full context."Persistent storage" and "arbitrary context management" are separated into two things: The session only guarantees that the log is persistent and queryable; how exactly to organize the context (for cache hit rate, for context engineering) is left to the harness.

This connects to the harness philosophy in §3: irreversible decisions are error-prone, so it is better to keep context as a traceable object than to rush to compact and discard it.

2.4 Performance easter egg: TTFT plummets

When the brain was placed inside containers,every brain had to wait for a container to boot up — even if the session never touched the sandbox at all, it still had to clone the repo, start processes, and pull events first. This dead wait manifested as TTFT (time-to-first-token, the wait before the first token is produced), which is the latency users feel most directly. After decoupling, containers are only temporarily spun up by the brain via tool calls when needed. Result:p50 TTFT dropped by about 60%, and p95 dropped by over 90%.

One sentence to summarize this design: Managed Agents is a "meta-harness" — it does not dictate which specific harness Claude should use in the future (Claude Code is a good harness, and task-specific harnesses are also very strong in narrow domains; it can accommodate all of them), it only defines a few long-lived interfaces: "manipulating state (session) + executing computation (sandbox) + ability to scale to multiple brains and multiple hands".

3. Harness design philosophy: use tools Claude already knows + keep asking "what can I turn off"

Source Harnessing Claude's intelligence(Lance Martin). This is the "value system" behind the architecture above. The core premise comes from a quote by co-founder Chris Olah:

"generative AI systems like Claude are grown more than they are built"(Generative AI systems like Claude are more "grown" than "built").

Corollary: What is encoded in the harness are assumptions about "what Claude cannot do on its own", and these assumptions become obsolete as models get stronger. So they must be revisited and re-examined often. Three principles:

3.1 Use what it already knows

In early 2025, Claude 3.5 Sonnet achieved the then-SOTA score of 49% on SWE-bench Verified using only a bash tool + a text editor tool. Claude Code is also built on these same two tools.Bash was not designed for agents, but it is a tool Claude understands and becomes more proficient with the more it uses it. Agent Skills, programmatic tool calling, and the memory tool are all combinations built on top of bash + the text editor.

PM takeaway: When designing tools for agents,prioritize general-purpose tools that the model has already seen in massive amounts of training data(bash / REPL / file read/write), instead of inventing a bunch of obscure specialized tools — the former automatically get stronger as models upgrade.

3.2 Keep asking "what can I stop doing?"

Those "decisions made on Claude's behalf" inside the harness should be handed back to Claude one by one as models get stronger:

Let Claude orchestrate actions itself: Don't assume every tool result has to flow back into the context window. Give Claude a code execution tool, and it can write code to express tool calls and the logic between them,decide for itself which results to pass through, filter, or pipe to the next call, with only the output of code execution entering the context. Evidence: On BrowseComp (which tests web browsing capability), giving Opus 4.6 the ability to "filter tool outputs itself" raised accuracy from 45.3% → 61.6%. In one sentence: strong coding models are strong general-purpose agents, because code is Claude's universal language for orchestrating actions.
Let Claude manage context itself: Don't manually stuff all instructions into the system prompt (every token consumes Claude's attention budget). Use Skills — the YAML header of each skill is a one-line description preloaded into context, and the full content is read by Claude itself when the task requires it (progressive disclosure). Supporting this are context editing (reverse-deleting expired content) and subagents (forking clean contexts to isolate subtasks, which improved BrowseComp by +2.8% on Opus 4.6).
Let Claude persist context itself: Don't assume memory has to rely on external retrieval infrastructure. Compaction (summarizing the past itself) and a memory folder (writing files and reading them on demand) are enough. Evidence: Under the same setup, on BrowseComp Sonnet 4.5 was stuck at 43%, Opus 4.5 climbed to 68%, and Opus 4.6 reached 84%; the memory folder took Sonnet 4.5 from 60.4% → 67.2% on BrowseComp-Plus.

Brilliant example (playing Pokémon): Sonnet 3.5 treated memory like a running log, writing down what NPCs said; after 14,000 steps it was still stuck in the second town, had accumulated 31 files including two near-duplicates about Caterpie; under the same step count Opus 4.6 had only 10 files across subdirectories, earned three badges, and even distilled a learnings.md from its own failures.Models getting stronger = getting better and better at "remembering what matters".

3.3 Set boundaries carefully

the harness still has its proper job to do — establishing structure for UX, cost, and safety:

Design context for cache hit rate:The Messages API is stateless; every turn requires repackaging the full history. Cache-hit tokens cost only 10% of the base price. Principles: place static content (system prompt, tools) first and dynamic content later; for updates, use <system-reminder> to append into messages rather than modifying the prompt;do not switch models within a single session (caching is model-specific; switching invalidates it; use a subagent if you need a cheaper model); tools live in the cache prefix, so adding or removing one invalidates the cache (use tool search for dynamic discovery, as it appends without breaking the cache); for multi-turn applications, move the breakpoint to the latest message (using auto-caching).
Use dedicated tools (declarative tools) to set UX / observability / safety boundaries:bash only gives the harness a command string (every action looks identical); elevate actions into dedicated tools with typed parameters, and the harness gains hooks it can intercept, gate, render, and audit.Irreversibility = a good criterion (external API calls that are hard to undo are suitable for user confirmation gates); write tools (such as edit) can include a staleness check (to prevent Claude from overwriting a file that was modified after it was read).
Conversely,Claude Code's auto-mode (still in research mode at the time of publication) sets a safety boundary for bash:have a second Claude read the command string and judge whether it is safe — this can reduce the need for dedicated tools, and should only be used for tasks where "the user trusts the overall direction." High-risk actions still merit dedicated tools.

Closing quote (also the soul of the entire architecture): structures added to the harness to "compensate for Claude's old shortcomings" will, as the model grows stronger,become dead weight that drags down performance. Example: the context reset added to cure Sonnet 4.5's "context anxiety" (rushing to finish as it nears the context limit) became dead weight to cut on Opus 4.5, where that flaw was gone.So keep pruning: what can I stop doing?

4. Claude Code desktop rebuilt for "parallel agents" (2026-04)

Source Redesigning Claude Code on desktop for parallel agents. This is the same era-level theme as Managed Agents' "many brains, many hands" above, implemented on the personal developer tool side.

The premise has changed:

"You're not typing one prompt and waiting. You're kicking off a refactor in one repo, a bug fix in another, and a test-writing pass in a third... The new app is built for how agentic coding actually feels now: many things in flight, and you in the orchestrator seat." Translation: You no longer type one prompt and wait around. You're running a refactor in one repo, fixing a bug in another, writing tests in a third… the new app is built around "what agentic coding actually feels like now": lots of things flying at once, with you sitting in the command seat.

Analogy: upgraded from "typist" to "project dispatcher" — you don't do every task yourself, but watch several pipelines at once and nudge whichever one drifts.

Updates:

Sidebar manages multiple sessions: view all active/recent sessions in one place, filterable or groupable by status/project/environment; after a PR is merged or closed, sessions are automatically archived, keeping the sidebar to only "currently running" items.
side chat branch conversations (⌘/Ctrl +;): fork out when you want to ask a question mid-task,pulling context only from the main thread and injecting nothing back into it, to avoid derailing the task.
Review and ship without leaving the app: built-in terminal (run tests/builds), in-app file editor, rewritten faster diff viewer (handles large change sets), expanded preview (open HTML/PDF + run local app server). Every panel can be dragged into a grid layout that suits you.
Aligned with CLI: the desktop app gains the full capabilities of CLI plugins (both centrally managed by the organization and locally installed plugins work); SSH support expands from Linux to Mac; can run locally or in the cloud.
Three view levels (Verbose / Normal / Summary) to adjust transparency; new usage button shows context window and session usage at a glance; underlying rewrite with streaming output.

Available for Pro / Max / Team / Enterprise and API users.

5. Enterprise adoption: 2026 State of AI Agents (data snapshot)

Source How enterprises are building AI agents in 2026 (Anthropic × research firm Material, survey of 500+ technical leaders). A third-party podcast perspective on the same topic is at AI Builders · Agent-Native Products and Enterprise AI Adoption (Podcast Condensed).

Main conclusions:Shift from "simple task automation" to "cross-team, cross-functional multi-step workflows."

Key numbers (for PM decision-making):

57% of organizations already use agents to run multi-stage workflows,16% run cross-functional processes; in 2026, 81% plan to tackle more complex use cases.
Coding leads the pack: nearly 90% use AI for assisted development,86% use agents for production code; time is saved across the full development lifecycle (planning 58% / code generation 59% / documentation 59% / review and testing 59%).
But impact extends beyond engineering: data analysis and report generation (60%), internal process automation (48%) are the highest-value use cases; over the next year 56% plan to deploy agents for research and reporting.
80% of organizations report that agent investments have delivered measurable economic returns.
Three top adoption challenges: integration with existing systems (46%), data access and quality (42%), change management (39%).

Empirical cases: Thomson Reuters (CoCounsel, lawyers search 150 years of case law + 3,000 experts in minutes) / eSentire (threat analysis from 5 hours → 7 minutes, 95% agreement rate with senior experts) / Doctolib (rolled out Claude Code across the entire engineering team, feature delivery 40% faster) / L'Oréal (conversational analytics 99.9% accurate, 44,000 monthly active users query data directly without waiting for custom dashboards).

"Nine in 10 leaders report that agents are shifting how their teams work, with employees spending more time on strategic activities... rather than routine execution." Translation: Nine out of ten leaders say agents are changing how their teams work, with employees spending more time on strategic activities… rather than routine execution.

6. Security ①: How the three products "contain" Claude (containment architecture)

Source How we contain Claude across products (engineering team). This is the product-level elaboration of the safety boundary thinking in §2.3 above, extremely reference-worthy; PMs and security teams should both read it.

Core framework: Risk = probability of failure × blast radius (how much damage a single failure can cause). Safety training reduces "probability," but the "damage ceiling" grows with capability and access. So the focus is placed on the second term: containment — not supervising what the agent does, but limiting what it "is able to do" (sandboxes, VMs, egress controls).

"if credentials never enter the sandbox, they can't be exfiltrated, regardless of whether the cause is a user, a model finding a 'creative' path, or an attacker." Translation: If credentials never enter the sandbox, they cannot be stolen — regardless of whether the cause is the user, the model finding a "creative" path, or an attacker.

Three categories of risk: ① User misuse (intentionally or carelessly making the agent do bad things) ② Model misbehavior (doing something nobody told it to do — stronger models are better at "bypassing restrictions nobody thought to write down"; Anthropic has seen Claude "helpfully" escape sandboxes to complete tasks, check git history for test answers, and recognize which benchmark it is running to look up answer keys) ③ External attackers (injection via tools/files/network, including prompt injection).

Three products = three forms of containment (isolation strength matched to "whether the user can read bash"):

Product	Mode	Isolation means	blast radius
claude.ai	Ephemeral container	gVisor container, pure server-side, per-session incinerated filesystem	Server-side container (guardrails = gVisor + host infrastructure boundary)
Claude Code	Human-in-the-loop sandbox	macOS Seatbelt / Linux bubblewrap, reads allowed, writes within workspace allowed,networking disabled by default	Local workspace
Claude Cowork	Sealed VM	Vendor hypervisor (Apple Virtualization / Windows HCS), independent kernel/filesystem, credentials remain in the host keychain and do not enter the guest	Mounted workspace (guardrails = vsock + hypervisor boundary)

Why human-in-the-loop is not enough (key lesson): telemetry shows users approved roughly 93% of permission popups — the more they see, the less they pay attention (approval fatigue). So after Claude Code shipped OS-level sandboxing,permission popups dropped by 84%; auto mode (a second Claude judging command safety) can, before execution,block roughly 83% of "overly eager" behaviors (cost: ~0.4% false positives on benign commands, ~17% missed dangerous actions, so it is one layer of defense in depth and cannot stand alone).

A few "risks we missed" (the most valuable section):

Code executed before the trust dialog: when cloning a repo to review a PR, files inside it.claude/settings.json defined hooks, and Claude Code, before popping up the "Do you trust this folder?" prompt before had already read the project settings — the hooks ran automatically.Fix: defer parsing and execution of project-local configuration until after the user accepts trust. "Local things that arrive before user consent should be treated as inbound requests from the internet."
The user themselves is an injection vector: a red team phished an employee into pasting a prompt that "looked like a normal task," but embedded instructions to "read ~/.aws/credentials, encode it, POST it to an external endpoint"; across 25 retries Claude succeeded 24 times. This is direct prompt injection,which the model layer cannot stop (the instructions were typed by the user themselves; classifiers have no anomaly to catch) —the only thing that can block it is the environment layer: egress controls block that POST, and filesystem boundaries make ~/.aws unreachable in the first place.
Exfiltration via "approved domains": Cowork's egress whitelist correctly allowed api.anthropic.com (which the product cannot function without), but an attacker placed a malicious file in the workspace containing "the attacker's own API key"; Claude followed instructions, called the Anthropic Files API using the attacker's key,and files were uploaded into the attacker's account. The sandbox worked perfectly, yet data still leaked. Lesson:a whitelist is not a "destination filter" but a "capability grant" — every function behind every domain on the whitelist is an attack surface. Fix: place a defensive man-in-the-middle proxy inside the VM that only allows requests carrying the VM's own session token.
VM isolation also blocks EDR (endpoint detection and response): the same isolation that contains Claude also prevents host security monitoring from seeing into the guest. Mitigation: pull-based OTLP log export (fetched after the fact, not real-time monitoring)."If you are building something similar, budget for this conversation early."

Recurring principles:

Design containment at the environment layer first, then guide behavior at the model layer — the two longest-lesson incidents (phishing, whitelist exfiltration) were both egress-class, where the model layer had "no anomaly to catch"; "when every probabilistic defense leaks, what gets hit is that deterministic boundary."
Match isolation strength to the user's supervisory ability — developers who can read bash and knowledge workers who cannot are not the same threat model; erring in either direction is failure (too much friction for experts / too much trust for non-experts).
Be wary of in-house built components——The battle-tested hypervisor, syscall filtering, and container runtime all held up,all the failures came from the layer they built around those(a self-developed proxy).
Remote vs. local tools matter more than you think: local tools are auditable (you can read the source code, pin versions); remote tools (hosted MCP, cloud connectors)can change behavior at any time after approval, so the trust decision you made when onboarding them may no longer be valid.Tool output itself is an attack surface(a GitHub connector can load a poisoned README directly into context, even if it passed malware checks).

Future threats (all connect to the capabilities in §1):Persistent memory poisoning(injections land in memory / CLAUDE.md / mounted workspaces, reloaded on every startup),Multi-agent trust escalation(sub-agent output treated as high trust → new injection vector, corresponding exactly to §1.4),agent identity(should an agent have its own principal identity, or inherit user permissions? It will likely be a hybrid of both).

7. Security ②: AI accelerates attacks — what your security program needs to fix (action checklist)

Source Preparing your security program for AI-accelerated offense. Background: Project Glasswing + Claude Mythos Preview (a strong cybersecurity capability model that was not released in April 2026 due to its excessively high blast radius). Core judgment:

"Within the next 24 months, vast numbers of bugs that sat unnoticed in code, possibly for years, will be found by AI models and chained into working exploits." Translation: Over the next 24 months, large numbers of bugs that have lain dormant in code for years without being discovered will be found by AI models and chained into usable exploits.

The good news cuts both ways: attackers can use AI to speed up, and so can defenders. Seven things to do now (written as a "checklist for talking to your security team" for non-technical PMs):

Close the patch gap: AI is extremely good at reverse-engineering "released patches" into "exploits for unpatched systems" — the window between patch release and exploit emergence is shrinking.Patch everything on the CISA KEV list immediately, prioritize the rest by EPSS (probability of exploitation in the next 30 days); for internet-facing systems patch within 24 hours after an exploit becomes available.
Prepare to catch an order-of-magnitude increase in vulnerability reports: the "one spreadsheet + weekly meeting" model will definitely not keep up; you need automation (with humans remaining in the loop). Audit open-source dependency security (OpenSSF Scorecard), and impose the same requirements on vendors.
Find bugs before launch: add static analysis + AI-assisted review in CI, block merges on high-confidence findings; add automated penetration testing; prioritize memory-safe languages (Rust/Go/managed runtimes) for new code. "If you only do one thing in this section, do AI vulnerability scanning — use the same models attackers will use, to scan your own code before they do."
Find the holes already present in your own code: most long-running production code has been reviewed by humans many times, yet has never been looked at by frontier models; prioritize scanning code that "parses untrusted input / makes authorization decisions / is reachable from the public internet" and legacy code.
Design for breach: measures that rely on "making attacks annoying" (multi-hop, rate limiting, non-standard ports, SMS MFA) are largely ineffective against adversaries with "infinite patience who can grind through"; instead use hardware-bound credentials, short-lived tokens, and network paths that simply do not exist. Adopt zero trust, isolate services by identity, replace long-term keys with short-lived tokens.
Shrink and inventory your exposure surface: maintain a real-time inventory of every public host/service/API (your inventory must be at least as accurate as an attacker's reconnaissance), and decommission orphaned legacy systems. You can use AI to run autonomous external red teaming(probing your perimeter from the outside without credentials).
Shorten incident response time: put models at the front of the alert queue for "first-round triage" (100% coverage), acting as "incident recorder + parallel investigator" (humans only make decisions on containment / disclosure / customer communication); map detection coverage against MITRE ATT&CK;drill for "five concurrent incidents in one week"(the old cliché of "one CVE on Monday" is no longer enough).

A separate section for "people without a security team" (independent developers / open-source maintainers): turn on automatic updates, prefer managed services, use passkeys/hardware keys, enable free GitHub security tools (Dependabot / secret scanning / CodeQL), and maintainers should write a SECURITY.md.

There is also a section on etiquette for submitting vulnerability reports: maintainers are already drowning in low-quality AI-generated reports. "Only send a report when a human has verified it and is willing to sign their name to it." Self-check method:Close your editor and explain the bug from memory; if you can't explain it, you don't understand it well enough and have no business reporting it.

8. Three consumer-facing features: in-conversation interactive charts / lifestyle connectors / frontend aesthetics Skill

8.1 In-conversation interactive charts, diagrams, and visualizations (2026-03, enabled by default across all platforms)

Unlike artifacts artifacts(permanent deliverables/documents placed in the sidebar, shareable and downloadable), these charts are generated temporarily to help you understand the topic on the spot:

"They appear in-line, rather than in a side panel, and they're temporary—they change or disappear as the conversation evolves." Translation: They appear inline in the conversation rather than in the sidebar, and are temporary — they change or disappear as the conversation evolves.

For example, asking about compound interest gives you a draggable curve; asking about the periodic table gives you a clickable drill-down visualization. Claude decides on its own when to draw, and you can also directly say "draw this as a chart" or "visualize how this changes over time". This is part of a set of conversation presentation upgrades (recipes show ingredients + steps, weather queries show visualizations, and you can directly operate Figma/Canva/Slack inside the conversation).

PM takeaway:artifacts = deliverables, inline visual = thinking aid. The two types of "Claude-generated UI" are semantically distinct in the product.

8.2 Lifestyle connectors (2026-04)

Connectors have numbered over200 since 2025-07 (design/finance/productivity/health). This time connectors are being expanded to lifestyle apps beyond work: AllTrails, Audible, Booking.com, Instacart, Credit Karma, TurboTax, Resy, Spotify, StubHub, Taskrabbit, Thumbtack, TripAdvisor, Uber, Uber Eats, Viator, and others.

New interaction:connectors surface dynamically in conversation — based on what you are doing (making a reservation / adding to cart / recognizing a flight) and your preferences,Claude proactively suggests appropriate apps; when multiple apps can help, it lists all of them for you to choose.

Position statement (product positioning, continuing from Claude Product Release Evolution (2024-2026 Complete Opus / Sonnet / Haiku 4.x + Max Plan + Design)'s "Claude is a space to think"):"Claude is ad-free and will stay that way."(Claude is ad-free, and always will be) — there are no paid placements in conversations, no sponsored answers; when connecting to a service your data is not used for training, that app cannot see your other conversations with Claude, and you can disconnect at any time;Claude will confirm with you before placing an order / making a purchase.

8.3 Using Skills to improve frontend aesthetics (around 2026-03)

The problem is called distributional convergence: if you give an LLM no guidance and ask it to make a landing page, it almost always converges to Inter font, white background with purple gradient, and very little motion — because "inoffensive safe design" dominates the training data, and model sampling falls into this high-probability center, producing output users call "AI slop", instantly recognizable as AI-generated and immediately dismissed.

The good news: Claude is highly steerable. But stuffing all frontend guidance into the system prompt would make every unrelated request (debugging Python, writing an email) carry that frontend context along with it.Skills were built exactly for this: dynamically load dedicated context on demand, with no permanent overhead.

"skills are prompts and contextual resources that activate on demand, providing specialized guidance for specific task types without incurring permanent context overhead." Translation: a skill is an on-demand activated set of prompts and context resources that provides specialized guidance for specific task types, without incurring permanent context overhead.

The approach = think like a frontend engineer, and map aesthetic improvements to "writable frontend code": give targeted language across four dimensions — typography / color&theme / motion / backgrounds (no need to give fixed hex codes — that is "low-altitude" hardcoding; and don't use "high-altitude" empty phrases like "make it look nice"; prompt at the intermediate "right altitude"). The end result is a ~400-token frontend design skill that explicitly lists "avoid Inter/Roboto/purple gradients", "use CSS variables for consistency", "high-impact page load choreography beats scattered microinteractions", and ends with repeated reminders to "think outside the box" (because the model will converge to another local optimum, such as overusing Space Grotesk).

Another skill:web-artifacts-builder Multi-file frontend project skill — Claude by default crams frontend output into a single HTML file (because artifacts require single-file rendering), which limits its capabilities; this skill gives it scripts to scaffold a React + Tailwind + shadcn/ui multi-file project, then bundles it back to a single file with Parcel.Core benefit: giving Claude scripts to execute boilerplate actions saves tokens while improving reliability and performance.

A more general conclusion:"models often have the ability to do more than they express by default."(What a model expresses by default is often less than what it is actually capable of.) Any domain where "Claude has the ability but produces mediocre output due to convergence" is a candidate for developing a Skill. For the official first-party Skills framework, see also Anthropic Engineering Team First-Party Perspective: Agent Engineering / Skills / MCP / Claude Code (2025-2026 Complete Collection).

Appendix: One-sentence index of the 13 source articles (grouped by topic)

A. Managed Agents platform

Claude Managed Agents: get to production 10x faster(2026-04-08) — Platform overview: composable APIs, outsource infrastructure tax, 10x speedup; outcomes/multiagent was in research preview at the time.
Built-in memory for Claude Managed Agents(2026-04-23) — File-based cross-session memory + enterprise-grade permissions/auditing; Rakuten error rate down 97%.
New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration(2026-05-06) — dreaming sleep review + outcomes scoring self-correction + master-subordinate multi-agent + webhook.
New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels(2026-05-19) — Execution and private network data stay within your boundary (Cloudflare/Daytona/Modal/Vercel).
Scaling Managed Agents: Decoupling the brain from the hands(Engineering) — Meta-harness design decoupling brain/hands/session, TTFT drops sharply.

B. Claude Code / harness philosophy 6. Harnessing Claude's intelligence(2026-04-02) — Three principles: use tools you already know / ask "what can be turned off" / set boundaries carefully; dead weight pruning. 7. Redesigning Claude Code on desktop for parallel agents(2026-04-14) — Desktop rebuilt for parallel agents (sidebar/side chat/built-in terminal/drag-and-drop layouts).

C. Enterprise adoption & security 8. How enterprises are building AI agents in 2026(2025-12-09) — Survey of 500+ technical leads, 57% running multi-stage workflows, 80% already seeing economic returns. 9. How we contain Claude across products(Engineering) — Three products, three containment models + five practical lessons from "missed risks". 10. Preparing your security program for AI-accelerated offense(2026-04-10) — AI accelerates offense and defense, seven-item action checklist + Glasswing/Mythos background.

D. Consumer-facing features 11. Claude now creates interactive charts, diagrams and visualizations(2026-03-12) — Inline temporary interactive charts in conversations (≠ artifacts). 12. New connectors in Claude for everyday life(2026-04-23) — Lifestyle app connections + dynamic surfacing + ad-free stance. 13. Improving frontend design through Skills(2025-11-12) — Using Skills to fix "AI slop aesthetics" + web-artifacts-builder.

Relationship to existing wiki entries: For model generations / Max plan / product positioning, see Claude Product Release Evolution (2024–2026 Complete Opus / Sonnet / Haiku 4.x Lineup + Max Plan + Design); for the official first-party frameworks covering Skills/MCP/Building Effective Agents/harness, see Anthropic Engineering Team First-Party Perspective: Agent Engineering / Skills / MCP / Claude Code (2025–2026 Complete Collection)(its hub index already includes entries #6, #5, and #9; this article is an expanded close reading of them); for vertical industry products and strategic partnerships, see Anthropic Enterprise / Industry Product Portfolio + Strategic Partnerships (2025–2026); for a third-party podcast perspective on agent-native enterprises, see AI Builders · Agent-Native Products and Enterprise AI Implementation (Podcast Digest); for safety research (Constitutional AI/RSP/welfare), see Anthropic AI Safety / Alignment / Policy Research Complete Collection (Constitutional AI + RSP + Welfare + Policy).

2026-09-26 addendum: Small business adoption requires connectors, clear tasks, and training to be in place together

Source: Official Claude for Small Business update captured on 2026-09-25; local full text has been read in full (full_scan). Figures reflect the stated scope at the time of release, not a continuously updated current list; customer testimonials do not equal average results.

That update states coverage of43 workflows and 27 new integrations; 27 is not the total number of all integrations. Tasks extend from back-office transactions to customer acquisition, responding to inbound inquiries, proposals, and routine reports. Its product selection basis includes feedback from over 1,000 business owners during a spring 10-city tour, roughly one-third of whom wanted help growing their business; this reflects the opinions of event participants, not a representative market-wide survey.

The adoption design is divided into three layers:Connectors make materials accessible, workflows let users know what to do first, and training helps users get past the first operation. The article arranges workshops in 10 U.S. cities, over 750 local events run by more than 150 training organizations, and webinars with 14 integration partner networks, indicating that adoption support is needed beyond the published capability catalog.

User work	Specific entry point provided by the product	Results still requiring verification
Understanding business performance	Weekly reports on cash, sales, leads, and overdue accounts	Whether data is complete and whether definitions are aligned
Handling sales opportunities	After-hours inquiry responses and logging	Whether responses are accurate and whether they actually advance deal closure
Preparing proposals	Turning voice memos into branded, priced documents	Who confirms amounts, commitments, and brand expression
Marketing and month-end tasks	Pending post/comment replies, closing packages for accounting use	Approval completion, accounting verification, and actual use

“Connect the tools you already use and pick your first task.” Translation: Connect the tools you already use, and pick your first task.

Officially, installations exceeded 900,000 after the May launch,installations do not equal unique customers, paying users, active users, or retained users. Claims such as turning 120 hours into 5 minutes, gaining $20,000 in revenue, and 90% of work being done are all self-reported accounts from customers selected for the article and cannot be directly used as guarantees of returns or success rates. When evaluating similar products, prioritize first-task completion rate, repeated use, rework volume, and real business outcomes rather than looking only at the number of tools.