What Anthropic shipped today
Today, May 5, 2026, Anthropic announced ten ready-to-run agent templates targeted directly at banks, insurers, and asset managers. Pitch builder, meeting preparer, earnings reviewer, model builder, market researcher on the coverage side. Valuation reviewer, general ledger reconciler, month-end closer, statement auditor, KYC screener on the operations side. Each one ships as a plugin in Claude Cowork and Claude Code, and as a cookbook for Claude Managed Agents on the Claude Platform.
The launch came packaged with new MCP connectors for Dun and Bradstreet, Fiscal AI, Financial Modeling Prep, Guidepoint, IBISWorld, SS&C IntraLinks, Third Bridge, and Verisk, plus a Moody's MCP server with credit ratings and data on more than 600 million public and private companies. Microsoft 365 add-ins for Excel, PowerPoint, Word, and Outlook came in the same release.
This is the first time a major model vendor has tried to put pre-built finance agents into the path of a regulated institution this directly. If you work in compliance, model risk, or AI engineering at a bank or insurer, the question landed on your desk this morning: how fast can we evaluate this, and what are the gates before any of it goes near a real deal, a real claim, or a real customer file?
Why these are not just "tools"
The trap with agentic AI in financial services is the classification problem. A workflow that ingests a counterparty file, calls an external data source, applies a heuristic, and produces an output that drives a regulated decision is a model under SR 11-7, the Federal Reserve's supervisory guidance on model risk management. It does not matter that the agent is built on a vendor template. It does not matter that no one on your team trained the underlying model. If it processes input data into a quantitative or categorical estimate that a business decision relies on, it is a model.
A pattern examiners have flagged repeatedly with first-generation ML deployments is the inventory gap: LLMs deployed in customer service, document processing, and compliance functions that were classified as "tools" rather than "models" and therefore never validated. An out-of-the-box KYC screener or a statement auditor that ships from a vendor as a plugin is exactly the kind of artifact that gets classified as a tool by the team that turned it on, then re-classified as a model by the examiner who finds it six months later. The Fed's recent SR 26-02 revision to the model risk guidance is widely read as expanding the definition of "model-like" systems to cover GenAI and agentic workflows; if you have a Managed Agent producing credit memos, you are almost certainly inside that perimeter.
The U.S. Treasury's Financial Services AI Risk Management Framework, released in February 2026, maps to the NIST AI Risk Management Framework and aligns with SR 11-7. The direction of supervisory travel is clear: AI is a model risk problem with a cybersecurity overlay, not a procurement question.
The two deployment models behave differently
The plugin form runs inside Claude Code or Claude Cowork on an analyst's machine. The agent sees what the analyst sees, uses tools the analyst is logged into, and acts under the analyst's identity. From a control standpoint this looks like an analyst with a very capable autocomplete. The validation surface is the analyst's review of every output, the same way an associate's pitch draft gets reviewed by a VP today.
The Managed Agents form is different. The agent runs on the Claude Platform inside a long-running session with its own credential vault, its own tool permissions, and its own audit log. It can run autonomously between human checkpoints. The validation surface is no longer "an analyst reviewed it." The surface is "what did the system do, what data did it touch, what decisions did it produce, and how is that auditable end to end."
If your governance posture is built around the first model, it will not stretch to cover the second without rewriting controls. Treat them as two separate deployments with two separate model risk records.
Credential vaults are the right primitive, used wrong are dangerous
The Managed Agents API exposes a vault concept that is genuinely useful for regulated deployments. Credentials are registered against a vault, the agent references them by ID at session creation, and every credential access is logged with session ID and timestamp. Secret fields are write-only and never returned in API responses. Here is the documented session-creation pattern, current as of the managed-agents-2026-04-01 beta:
# Register a per-user vault
vault = client.beta.vaults.create(
display_name="Analyst: A. Chen",
metadata={"external_user_id": "usr_abc123"},
)
# Bind a credential to a specific MCP server URL
credential = client.beta.vaults.credentials.create(
vault_id=vault.id,
display_name="Moody's MCP token",
auth={
"type": "static_bearer",
"mcp_server_url": "https://mcp.moodys.com/mcp",
"token": "moody_pat_...",
},
)
# Attach the vault at session creation
session = client.beta.sessions.create(
agent=agent.id,
environment_id=environment.id,
vault_ids=[vault.id],
title="Q2 credit memo: Acme Corp",
)
Two failure modes to design around. First, vaults and credentials are workspace-scoped, meaning anyone with API key access in the same workspace can use them to authorize an agent. The Anthropic vaults documentation flags this directly. In a regulated institution, that means workspace partitioning has to align with your existing access boundaries, not the other way around. Do not let one workspace span trading, research, and IB without explicit information barriers.
Second, the audit log gives you an immutable record of which session accessed which credential. It does not, by itself, give you the lineage from credential access to business decision. If a Managed Agent pulled a Moody's rating into a memo that an MD signed, you need a separate trace that connects the rating, the prompt, the agent's reasoning, the human review, and the signed artifact. The session log is a piece of that, not the whole thing.
KYC is the highest-stakes template in the launch
The KYC screener is the template that should get the most scrutiny. KYC sits inside the Bank Secrecy Act program, with FinCEN reporting obligations, FFIEC examination expectations, and OFAC sanctions exposure. A false negative in KYC is not "a bug to fix in the next sprint." It is potentially a Suspicious Activity Report that did not get filed.
The questions that have to be answered before this template runs against a real customer file:
- What sources of truth does the agent query, and is each one a permissible source under your KYC policy?
- Where does the agent's output enter the SAR decision pipeline, and how is the human reviewer's override captured?
- What is the model's documented false negative rate against your existing KYC test set, and who validated it?
- What logs prove that a given customer was screened, against what list, on what date, with what model version?
- If the model is changed by Anthropic without notice, does your validation still hold?
Most teams will not have answers to most of these on day one. That is the gate.
MCP connectors are now in your supply chain
Every external MCP connector the agent talks to is a third-party service in your data path. Moody's, Verisk, Dun and Bradstreet, IntraLinks, Guidepoint, and the rest are real vendors with real contracts already, so this part is familiar. Less familiar: the connector itself is software that gets between your agent and the vendor. It can change behavior, add new tool calls, adjust rate limits, or expose new data fields without a redeployment on your side.
Treat MCP servers like any other inbound third-party integration: contractually under TPRM, technically under egress allowlisting, and operationally under change monitoring. The Fraktional team wrote a longer breakdown of MCP supply chain risk last quarter; the short version is, do not let an MCP connector update silently change what data leaves your environment.
The same applies to the agent definitions themselves. A vendor-shipped agent template is code. It can be updated. Pin versions, diff updates, and review prompt changes the same way you review any production code change. The agent prompts are not configuration, even if a vendor calls them that.
A pre-rollout gate checklist
Before any Claude finance agent template runs on a real workflow:
- Model inventory entry. One per agent template, per deployment mode (plugin vs. Managed Agent). Tied to a model owner, a model risk tier, and a validation status.
- Validation against your data. Conceptual soundness, ongoing monitoring, and outcomes analysis per SR 11-7. Do not accept a vendor's benchmark as your validation.
- Workspace partitioning. Map Claude workspaces to your existing information barriers. One workspace per business unit at minimum; finer if you have Chinese-wall constraints.
- Credential scoping. Per-user vaults, not shared service vaults. Use the metadata field to tie back to your IAM user records.
- Egress controls. Allowlist the MCP server URLs that any agent in the workspace can hit. Block by default.
- Logging extensions. Every session log piped into your SIEM with retention that matches your longest applicable rule (often seven years for FINRA-regulated communications).
- Output review surface. A human-in-the-loop step on every output that becomes part of a regulated artifact. The reviewer's identity, decision, and timing all logged.
- Change monitoring. A dashboard that flags new versions of agent templates, new MCP connectors, or changes to existing ones, before they are adopted.
- Tabletop incident response. What you do when an agent makes a wrong KYC call, what you do when a credential leaks, what you do when an MCP server is compromised. Run the exercise.
This is not the full validation playbook. It is the gate before the validation playbook starts.
The bigger point
The model vendors are no longer just shipping APIs. They are shipping pre-built workflow agents that target the most regulated decisions inside the most regulated industries. The compliance lift to absorb that is real, and it falls on the engineering and risk teams at the institutions, not on the vendor. The vendor ships the template. You own the deployment, the data, the audit trail, and the regulatory exposure.
The teams that will get value out of these agents in 2026 are the ones who treat the rollout as a model risk project from day one, not a procurement decision that loops compliance in at the end.
Kai writes about secure AI adoption at Fraktional, where we help engineering and risk teams in regulated environments deploy AI without giving up control of their data or their audit trail. We believe customers should own everything that runs in their environment, and that the boring parts of AI engineering, evals, model risk records, and audit logs, are the parts that decide whether a deployment survives an examination.
