2026-10-21 · CobolStack
Anthropic's modernization playbook and its zero-trust guide for agents say: understand the code first, write the tests before you change anything, run old and new side by side, and give the agent a scoped identity, an audit trail and a sandbox. Here is what that asks for, and how a team runs all of it on SteelFrame, a mainframe-compatible place where Claude can read, run, test and compare legacy COBOL, CICS, DB2 and JCL behaviour.
Anthropic has published two documents that, read together, describe how a team is expected to modernize legacy code with Claude: The Code Modernization Playbook[1] and Zero Trust for AI Agents.[2] A companion article on COBOL[3] spells out the phases. We read all of them, plus the financial-services and multi-agent material around them, and asked one practical question: when a team follows this playbook on a mainframe estate, where does the work actually run? This post says what the documents ask for, in plain words, and then shows how each step maps onto SteelFrame, our clean-room z/OS-compatible environment. SteelFrame is built for Claude-driven modernization and aligned with the practices in Anthropic's playbook; it is our product, not Anthropic's, and nothing here implies their endorsement. It is not IBM z/OS and is not affiliated with IBM.
The argument is economic. The COBOL article puts it in one line: "Cost has historically been the barrier: understanding what the code does is the most expensive step."[3] AI makes discovery cheap. Everything else in the playbook follows from that, and it is more conservative than the word "AI" suggests:
The e-book's eight-week outline makes the same point in calendar form: weeks 1–2 are "code archaeology"; weeks 3–4 produce a proof of concept "showing side-by-side execution with identical outputs"; weeks 5–8 add "parallel run capabilities where modernized code operates alongside legacy systems, comparing outputs for validation".[1] On tooling, it asks for deep codebase awareness, integration with your existing toolchain, the ability to run in a terminal, an IDE or headless, security by design with audit trails and role-based access, and connection to tools through open standards such as the Model Context Protocol.
The zero-trust guide is the other half. Its test for any control is whether it makes an attack "impossible, or just tedious", and it is blunt about the basics: every agent needs its own identity, the minimum permissions for its task, short-lived credentials, a sandbox when it handles untrusted input, a log of every tool call, and a human gate for high-risk actions.[2] For regulated industries it says explainability "is not optional". The multi-agent research post adds a pattern many teams will adopt: a lead agent that plans and delegates to parallel subagents, each with narrow instructions and its own context, which pays off for broad discovery and verification more than for writing one file.[4]
Every one of those steps assumes something the playbook does not dwell on: a legacy system the agent can
read, run, test and compare against, freely and repeatedly. "Side-by-side execution with identical outputs"
needs the old side to execute. Characterization tests need expected values that come from running the original,
not from the model's memory of what COBOL does. A production LPAR is the wrong place for an agent to learn by
submitting jobs, and a parser is not a mainframe: it cannot tell you what a COMPUTE truncates or how a
COMP-3 field rounds. SteelFrame exists for that gap. It compiles and runs COBOL, pushes JCL through a JES2-class
spool, runs CICS-compatible transactions with BMS maps, holds VSAM clusters and a DB2-compatible SQL engine, and
keeps data on disk in real EBCDIC with true record formats. An agent reaches all of it through MCP.
Below, each phase of the playbook with the MCP tools a team actually calls. Tool names are from the live
catalog at /api/mcp/tools on 21 October 2026 (99 tools on the persistent lane, 103 on the private
one).[5]
| Playbook phase | On SteelFrame | What comes back |
|---|---|---|
| 1 · Discovery | inventory_scan, analysis_model, analysis_graph (call, job and screen flows),
analysis_impact (field-level dataflow), analysis_metrics, find_program,
search_source, export_bundle, explain_program |
Programs, copybooks, JCL steps, CSD entries, mapsets and scheduler jobs as data; cyclomatic complexity and dead code; a program's transitive dependencies in one call; a bundle of source plus data for the agent to read |
| 2 · Risk | The same graphs, plus the estate assessment that names third-party technology by signature (IDMS, Adabas, CA-7, ICETOOL and the rest) | Which pieces are isolated, which are coupled through data, which depend on something you had forgotten |
| 3 · Tests first | run_batch with clock:{fixed:…}, run_capture, decode_records,
cics_run_script, cics_link, sched_demand → sched_wait_cycle,
export_state |
The joblog, every spool file, every output dataset as hex beside copybook-decoded rows with exact scaled decimals, a screen transcript one AID key at a time, a scheduler cycle in the order it ran, state dumps with checksums: the expected values for the tests |
| 4 · Incremental, validated | create_workspace for an isolated copy of the estate; your own VS Code seat with Java, Python,
C# / .NET, Node.js / TypeScript / Angular, C / C++, Go, Rust, Kotlin, PHP, Lua, PowerShell and shell, plus the seat's
own PostgreSQL; vscode_*_build / _test; vscode_db_import_vsam with a parity check |
The modern side built and tested next to the legacy side; a VSAM file landed in PostgreSQL with row counts, checksums and a byte proof that every row re-encodes to the source record |
One design rule shapes all of this: SteelFrame returns facts and never verdicts. It "never judges equivalence and never converts code", as the tool catalog's own instructions say.[5] Your harness replays the same inputs against your modernized code and compares on its side, and the engineer signs. That is exactly where the playbook puts the human. For regression on the legacy side itself, a golden capture can be re-run and diffed against its baseline (masked spool compare, byte-true dataset compare); today that compare is a REST route rather than an MCP tool, which we intend to change.
We are listing the honest state, gaps included, because the guide's "impossible, not tedious" test deserves a straight answer.[2][6]
| Control | SteelFrame today |
|---|---|
| Identity | Every call runs as the key's userid under RACF-style security; keys are self-service, shown once, stored hashed, with a name, last-used and an activity trail. Identity is the user, not yet the agent instance. |
| Least privilege | Per-tool scopes (datasets.read, jobs.write, cics.exec, …); Read-only, Developer, Full or Custom presets, always clamped to the user's own rights; administrator scopes never on a self-service key; 41 of 99 tools carry readOnlyHint, 19 carry destructiveHint so clients ask before acting. |
| Credentials | Keys expire (default 90 days), rotate and revoke immediately, take an IP allow-list, a daily spend cap and an MCP-only or REST-only surface. They are still static bearer keys; OAuth with short-lived tokens is on our list. |
| Audit | Every MCP tool call that reaches its route is logged with the user, the door, the tool and the status, free reads included, never the content; usage by key with CSV export. |
| Sandboxing | A private lane that is RAM-only with zero retention; workspaces that are a child engine on a copy of the estate, so the live estate never changes; VS Code seats in containers with a read-only root, no Linux capabilities and no internet; the AI-facing seat tools run fixed commands, never a free-form shell (the user keeps an ordinary terminal in their own seat). |
| Egress | A seat reaches only the engine's seat door. Where the operator enables Claude Code in a seat, its traffic leaves through a CONNECT path pinned to Anthropic's published hosts and address ranges; the engine never intercepts TLS. |
| Approval gates | Git pushes and writes or submits to a connected real mainframe wait for the user's click on the SteelFrame page (default on); the screen door shows a Stop button; destructive hints let the client ask per call. |
| Prompt injection | Results from the VS Code, Git, z/OS and screen doors begin with an envelope that marks them as data, never instructions, and forged markers are neutralised; the main /mcp door's text results do not yet carry it. |
Two shapes. The usual one: Claude Code on your own machine, with SteelFrame added as a remote MCP server
(claude mcp add --transport http steelframe https://steelframe.cobolstack.com/mcp --header "Authorization:
Bearer sf_…") and, if you want it, the VS Code door for your seat. The other: Anthropic's own Claude Code
extension installed by you, into your own SteelFrame seat, signed in with your own Claude account; it then reaches
the same MCP doors with your own scopes and edits the seat's workspace natively. Either way the lead agent and
its subagents call the same tools, get the same facts, and leave the same audit lines.
?lane=ephemeral to the endpoint if you want nothing to persist, or call
create_workspace first and pass workspace:<id> on every call.inventory_scan on the installed AWS CardDemo
estate, pick one batch job, capture it with run_batch and a fixed clock, and port that one job into a
seat language with tests that load the captured outputs. Or copy the playbook kit:
a project skeleton with a CLAUDE.md for Claude Code, one skill per phase, a deny list that keeps the
agent off the live estate, characterization tools, and exactly that worked example (CardDemo's POSTTRAN captured
with a pinned clock, ported to Python, seven tests that load the capture).Reads, lists and status are free; writes, compiles and SQL are $0.03 a call; a run is $0.03 plus $0.99 per core-hour after the first 10 s of CPU; failed calls are free.[5] Organisation access, on-premises or BYOC, is arranged through us.
Quotations are short excerpts from the cited documents, reproduced for commentary. Anthropic, Claude and Claude Code are trademarks of Anthropic, PBC; nothing in this post implies that Anthropic endorses, certifies or partners with CobolStack or SteelFrame. IBM, z/OS, CICS, Db2, VSAM, RACF, IBM i, AS/400 and other marks are trademarks of their respective owners. CobolStack is not affiliated with, endorsed by, or sponsored by IBM or Anthropic. SteelFrame and SteelFrame X are independent clean-room mainframe- and IBM i-compatible implementations that conform to the published specifications but are not identical to them; your licensed system remains the sole conformance authority. SteelFrame facts (tool names, counts, scopes, prices, limits) were read from the live catalog, the public documentation and the server source on 21 October 2026 and may change.