Claude Opus 4.8 ships 1,000-subagent Dynamic Workflows. Now multiply your blast radius.

Anthropic shipped Claude Opus 4.8 on May 28, 2026, 41 days after Opus 4.7 (TechCrunch). The headline most outlets ran with is the benchmark bump. The buried lede is the feature that shipped next to it: Dynamic Workflows, which lets Claude Code spawn up to 1,000 subagents per run, 16 of them concurrent, each one inheriting your tool allowlist and running in acceptEdits mode by default (Claude Code docs).

If you skipped the docs and only read the news post, you missed the sentence that should change how you think about agent credentials this quarter. We will get to it. First, the release.

What actually shipped

Same per-token price as the prior Opus tier: $5 per million input tokens, $25 per million output tokens (Anthropic, confirmed by Simon Willison). The context window stays at 1M tokens with 128K max output, and the prompt cache minimum dropped from 4,096 tokens to 1,024, which is a quiet but real win for short-context tool-loop workloads (Anthropic API docs). Knowledge cutoff is January 2026.

The new commercial wrinkle is fast mode, priced at $10 per million input / $50 per million output, running at 2.5x the speed of standard mode and described by Anthropic as "three times cheaper than it was for previous models" (Anthropic). Read that quote carefully. "Three times cheaper" is relative to previous fast modes, not relative to standard Opus 4.8. Willison adds that fast mode "is only available to organizations that are part of the research preview" (Willison).

On benchmarks, Anthropic's own callouts are Online-Mind2Web at 84% and the Legal Agent Benchmark, where Opus 4.8 is "the first model to break 10% overall on the all-pass standard" (Anthropic). The numbers being passed around in secondary coverage, SWE-bench Pro 64.3% to 69.2% and a knowledge-work Elo of 1,890 on Artificial Analysis's GDPval-AA leaderboard, are tracked at llm-stats and on the GDPval-AA leaderboard itself, which also publishes the comparator GPT-5.5 at 1,769 and Opus 4.7's prior 1,753. Treat secondary commentary as secondary, but the leaderboard numbers themselves are public.

The honesty story is the one worth quoting. Anthropic claims Opus 4.8 is "around four times less likely than its predecessor to allow flaws in code it has written to pass unremarked" (Anthropic). Willison reads this as restraint, the model abstaining rather than confabulating, and calls the whole release "a modest but tangible improvement" (Willison).

Modest is fine. The feature that ships alongside it is not.

Dynamic Workflows, mechanically

Anthropic's news post describes Dynamic Workflows in one sentence: they let Claude "run hundreds of parallel subagents in a single session" and handle "codebase-scale migrations across hundreds of thousands of lines of code" (Anthropic). The flagship case study is Jarred Sumner's Bun port from Zig to Rust. Anthropic's own framing in the Dynamic Workflows blog cites "roughly 750,000 lines of Rust," "99.8% of the existing test suite passing," and "eleven days from first commit to merge." Secondary press has reported larger numbers in shorter windows; we are using Anthropic's own figures here.

The official documentation is more useful. A dynamic workflow is, verbatim, "a JavaScript script that orchestrates subagents at scale. Claude writes the script for the task you describe, and a runtime executes it in the background while your session stays responsive" (Claude Code docs).

Three properties of that runtime are load-bearing:

The orchestrator script is sandboxed. It cannot touch the filesystem or run shell commands. Only the spawned subagents do that. Intermediate results live in script variables, not in your conversation context, which is how the runtime keeps your interactive session responsive while a long horizon job grinds in the background.

Availability: research preview, Claude Code v2.1.154 or later, on all paid plans plus Bedrock, Vertex AI, and Microsoft Foundry (docs). The bundled /deep-research slash command is the canonical example, and a new /effort ultracode setting will plan a workflow for every substantive task. MarkTechPost summarized the cap in their headline accurately: "Workflows Capped at 1,000 Subagents".

So far, so impressive. Now the line you should not skip.

The sentence the credential people should pin to the wall

Directly from the Claude Code docs:

The subagents the workflow spawns always run in acceptEdits mode and inherit your tool allowlist, regardless of your session's mode. File edits are auto-approved.

Stop and read it twice.

"Inherit your tool allowlist, regardless of your session's mode" means every subagent gets the union of permissions the lead session had. "Always run in acceptEdits mode" means file edits are not gated. "Regardless of your session's mode" means the per-session safety toggles you might have set on the interactive surface do not apply to the runtime.

In a single-agent loop, "Claude can use my GitHub token" is a manageable trust statement. You watched the screen. You hit "y" the first time it tried to push. At 16 concurrent workers feeding into a queue of up to 1,000, that statement is no longer a UX claim, it is a blast radius statement. If the lead session was trusted with a long-lived GitHub PAT scoped to your org, then so were 999 of its children, in any order, against any repo the token can reach, with no further confirmation.

This is not a security failure of Dynamic Workflows. It is the documented design. The runtime is doing exactly what the docs promise: trading interactive approval for throughput, on the assumption that the tool allowlist you set at the lead session is the right policy for the whole fanout. That assumption is convenient. It is also wrong as soon as the subagents are doing meaningfully different work.

Why this is the workload that breaks credential hygiene as currently practiced

Most credential-management advice for AI agents in 2026 is some flavor of two patterns:

1. Short-lived tokens at the boundary. Use a broker, OIDC, or STS to mint scoped tokens for the agent's session, then expire them. This is the right shape for a single-agent loop and it is what most production teams actually do today. We have walked through it in /blog/claude-code-production-ready-setup and /blog/anthropic-api-direct-keeping-the-key-safe.
2. Allow/deny at the proxy. Route the agent's outbound traffic through a proxy you control, and decide per request whether to inject a credential. This is the pattern we covered in /blog/top-agent-proxy-tools-what-to-know and the threat-model survey in /blog/ai-agent-security-in-2026-four-threat-models.

Both patterns assume the unit of policy is the run. One agent, one session, one set of allowed providers, one audit thread to follow.

Dynamic Workflows shatter that assumption in four specific ways:

Per-subagent scoping. Worker 47 is doing a Postgres migration. Worker 48 is reading email. Worker 49 is opening a PR. The policy you want is "47 can touch the database, 48 can read Gmail, 49 can push to one repo," and the lead session's allowlist almost never expresses that. Today, it is one allowlist, copied 1,000 times.

Ephemeral token issuance. If you are minting short-lived tokens, who mints them, when? At the lead session, you mint one set, and 16 concurrent workers share it. At the subagent, you would need to mint per worker, ideally per task, which is a per-subagent broker call that nothing in the public surface exposes today.

Audit blast radius. Your audit log will show 1,000 actions in roughly the same window, from the same lead session, against any provider in the allowlist. Reconstructing "which subagent did this push?" is non-trivial. Anthropic's docs say subagents are isolated from the workflow runtime, but they do not promise per-subagent identifiers in third-party provider audit trails, and your downstream services (GitHub, Linear, Stripe) will see traffic that looks like one principal acting very fast.

Revocation semantics. If a single subagent goes off the rails, the cheapest revocation primitive on most providers is "rotate the underlying token." That kills the other 999 subagents mid-run. There is no "kill subagent 47" primitive without a broker that sits between the workflow and the providers.

The honest framing is that Dynamic Workflows are a beautiful piece of engineering for the orchestration problem, and they make the policy problem strictly worse for anyone who was treating "one session, one set of creds" as a workable security posture.

What it is not (so we do not overclaim)

A few things worth flagging because the discourse will conflate them:

• Dynamic Workflows are not LangGraph and they are not CrewAI. No primary source draws that comparison. Anthropic's framing is closer to "Claude writes the orchestration script for you, then a sandboxed JS runtime executes it." If you have been hand-rolling supervisor graphs to get fanout, the differential is that the model writes the topology and you do not see it until runtime. That is a tradeoff, not a strict upgrade.
• The cap is 1,000 per run, not 1,000 concurrent. Sixteen concurrent, 1,000 total. The headline framing of "1,000 parallel subagents" is misleading even in some secondary coverage. MarkTechPost and the official docs get this right.
• The runtime sandbox is not a credential sandbox. "No direct filesystem or shell access from the workflow itself" applies to the JS orchestrator. The subagents it spawns have whatever the lead session had. The sandbox protects the runtime from the workflow script; it does not protect your providers from the subagents.

What changes for builders this quarter

If you ship anything that uses Claude Code in production, four practical adjustments:

1. Re-read your tool allowlist as if it will run 1,000 times. Anything in there that you were willing to approve interactively once is now a thing 1,000 workers can do without asking. Trim aggressively. The right default is the smallest allowlist that lets the lead session plan, plus narrower allowlists you grant per workflow.

2. Move long-lived provider tokens off the developer machine. If your GitHub or Postgres credential is sitting in ~/.config or in a shell rc, Dynamic Workflows turn that from a personal risk into an org risk. The base story for hiding long-lived keys behind a local broker is in /blog/stop-putting-api-keys-in-environment-variables and /blog/openai-api-key-hygiene-for-ai-agents.

3. Treat your supply chain as part of the blast radius. If any subagent runs pip install or npm install during a workflow, the next package you pull is now executing in a context that inherits your full tool allowlist. We laid out the threat surface in /blog/supply-chain-risks-for-ai-agents. Dynamic Workflows do not change the model, they multiply the exposure.

4. Plan for audit reconstruction. Your downstream providers will see a burst of activity from one principal. Decide now where the per-subagent attribution will live. If your broker logs every outbound call with a workflow ID and an indexable hint, you can reconstruct after the fact. If it does not, you are guessing.

Where Authsome fits, honestly

A short, honest note, because the rest of this post would be hollow without it.

Authsome is a local, open-source credential broker. The mechanic is simple: authsome login <provider> once, then authsome run -- <agent> launches your agent under a local HTTPS proxy. The agent process only ever sees a placeholder in its environment. The proxy matches outbound requests by destination and swaps in the real credential at egress. There is a global allow/deny proxy mode per run, an encrypted SQLite vault under ~/.authsome/, and an append-only JSONL audit log.

What Authsome does not ship today is the thing this article argues you need most for Dynamic Workflows: a per-subagent policy engine. The broker today decides per run, not per subagent. That is the truth, and saying otherwise would be dishonest. The 1,000-way fanout that Dynamic Workflows enable is exactly the workload that makes per-agent policy a roadmap priority, not a present capability. We would rather tell you that now, while you are deciding what to do, than overstate it.

The part of the story Authsome does solve well today is the prerequisite: get your long-lived provider keys out of agent environments, get an append-only audit log of every outbound call, and put a global allow/deny gate in front of the proxy. That is necessary. It is not yet sufficient for 1,000-way concurrency. We are working on it.

The takeaway

Opus 4.8 is a modest model release with a non-modest feature bolted on. The model is faster on hard problems and more honest about what it cannot do. The feature, Dynamic Workflows, takes the agent orchestration pattern that the open-source community has been hand-rolling for two years and ships it as a first-class primitive with sandboxed execution, JS authored by Claude, and a hard cap of 1,000 subagents per run.

The credential story has not caught up. The pattern most teams use today, single allowlist per session, single short-lived token per provider, single audit thread to follow, breaks at 16-way concurrency and shatters at 1,000-way total fanout. The right shape is per-subagent scoping, per-task ephemeral tokens, and a revocation primitive that does not take 999 healthy workers down with one bad one.

Nobody ships that today. Including us. The teams that adopt Dynamic Workflows for real production work in the next 90 days will be the ones who figure out what the missing primitive looks like. Watch the brokers, watch the gateways, and tighten your allowlists this week.

Authsome

Product & engineering

Local credential broker and vault for AI agents.