The Architecture Is the Regulatory Question
On April 8, 2026, Anthropic shipped Claude Managed Agents — a cloud-hosted runtime where AI agents persist across sessions, execute bash commands inside managed containers, connect to third-party tool servers via MCP, and accumulate context over days at $0.08 per session-hour.1 Notion, Rakuten, and Asana are building on it.2 The infrastructure for autonomous agents that hold wallets and handle regulated data is now production-grade.
The regulatory analysis most deployers will reach for is the wrong one. The question is not “do regulations apply to AI agents?” They do. We have mapped that terrain — seven direct-liability doctrines that already hold deployers accountable for their tools’ conduct3, and the full financial regulatory overlay for agents operating in digital asset markets.4 That analysis applies to any AI agent, on any infrastructure.
This article asks the harder question: what is it about this infrastructure — persistent sessions, cloud-hosted containers, MCP connectors, bash execution — that creates regulatory triggers a self-hosted agent does not? The answer is in the architecture. And the deployer’s first compliance artifact is not a legal memo. It is Anthropic’s documentation.
Key Takeaways
- Persistent sessions change the advisory relationship calculus. A Claude Managed Agent that accumulates client context across days satisfies elements of an advisory relationship under Section 202(a)(11) of the Investment Advisers Act that a stateless API call does not.
- MCP connectors introduce a new party into the money transmission chain. When your agent calls a third-party wallet API through MCP, the question of who is the “money transmitter” gains a party that self-hosted architectures do not have — and no state regulator has addressed the three-party question.
- Bash access is a meta-permission that exceeds the documented tool list. The deployer’s actual permission surface is the container environment, not the four named tool categories, creating an OWASP excessive-agency gap between documented and real authority boundaries.
- Beta features are “generally not covered under” Anthropic’s BAA, and code execution and MCP connectors — two of four built-in tool categories — are marked HIPAA-ineligible in the feature eligibility table.5
- The KYA Five Pillars framework maps each architectural feature to the deployer’s existing legal obligations, providing the structured governance layer that NIST’s 11-page February 2026 concept paper on agent identity and authorization poses as open questions but does not answer.6
What Regulatory Triggers Does Claude Managed Agents’ Architecture Create?
Six architectural features of Managed Agents create regulatory triggers that self-hosted agents do not face. The prior articles in this series establish that AI systems are tools, not agents, and deployers bear direct liability for what their tools do.3 This table maps the specific architectural choices Anthropic made to the specific compliance questions those choices create.
| Managed Agents Feature | Regulatory Trigger | Why Self-Hosted Agents Don’t Face This |
|---|---|---|
| Persistent sessions accumulating client context | Investment adviser registration analysis under Section 202(a)(11) | Stateless API calls reset context; no ongoing relationship to evaluate |
| MCP connectors to third-party wallet APIs | Three-party money transmitter classification question | Self-hosted agents call internal tools; no third-party intermediary in the transaction chain |
| Bash execution in managed containers | Actual permission surface exceeds the documented tool list | Self-hosted agents with defined tool interfaces have bounded, auditable permissions |
| Beta status with feature-level BAA exclusions | Two of four built-in tool categories are HIPAA-ineligible | Self-hosted agents run on the deployer’s own BAA-covered infrastructure |
| US-only workspace geography | GDPR cross-border transfer obligation for any EU data subjects | Self-hosted agents can be deployed in any jurisdiction the deployer controls |
| 2-year data retention for policy violations | Deployer data assumed ephemeral may persist on Anthropic’s infrastructure for 24 months | Self-hosted agents’ retention is entirely deployer-controlled |
The courts are already applying existing statutes to AI agent conduct. In Amazon.com Services LLC v. Perplexity AI, Inc., No. 25-cv-09514-MMC (N.D. Cal. March 9, 2026), Judge Chesney granted a preliminary injunction after finding that “Perplexity, through its Comet browser, accesses with the Amazon user’s permission but without authorization by Amazon, the user’s password-protected account.”7 The court applied Ninth Circuit precedent from Facebook, Inc. v. Power Ventures, Inc., holding that user permission “was not sufficient to grant continuing authorization” after the website operator revoked access.8 The technology was new. The statute was not. The liability ran to the deployer.
The architecture your agent runs on determines which regulatory triggers it faces. The analysis below maps the three highest-impact triggers to the deployer’s existing obligations.
Do Claude Managed Agents’ Persistent Sessions Create an Advisory Relationship?
It depends on the use case — but a Managed Agent session that accumulates client risk preferences, portfolio history, and prior recommendations across days starts to satisfy the three statutory prongs of an advisory relationship under Section 202(a)(11) of the Investment Advisers Act.9
What triggers investment adviser registration?
Section 202(a)(11) requires registration for any person who, for compensation, engages in the business of advising others on securities. A one-shot API call that answers a question about market conditions is closer to “information” — a publisher’s exemption may apply. A Managed Agent session that remembers a client’s risk tolerance from last Tuesday, tracks portfolio allocations across interactions, and generates recommendations referencing prior conversations starts to look like what the statute was written for: an ongoing advisory relationship.
How does Managed Agents’ session pricing incentivize the advisory relationship question?
The pricing architecture points toward persistence. Runtime accrues only while the session status is “running,” measured to the millisecond, and “time spent idle (waiting for your next message or a tool confirmation), rescheduling, or terminated does not count toward runtime.”10 Idle time is free. The economic logic incentivizes persistent sessions that stay open and accumulate context continuously — exactly the session design that strengthens the advisory relationship analysis.
The SEC’s FY 2026 Examination Priorities flag AI usage policies and supervision for registered investment advisers as an examination focus.11 The examination staff will not ask whether the technology is novel. They will ask whether the activity — accumulating client preferences, generating personalized recommendations, maintaining a continuous relationship — satisfies the statutory elements. The persistence of the session is the feature that makes the relationship continuous.
No court has ruled that a persistent AI session constitutes an advisory relationship. The doctrinal extension is natural, and the question is when — not whether — a plaintiff’s counsel or an SEC examiner raises it.
If your Managed Agent accumulates client context across sessions and generates recommendations based on that history, evaluate investment adviser registration before deployment. The session architecture is part of the analysis.
Who Is the Money Transmitter When a Managed Agent Moves Stablecoins Through a Third-Party Connector?
That depends on who controls the funds at each hop — and Managed Agents’ MCP architecture introduces a third party into the transaction chain that self-hosted agents do not have, creating a money transmitter classification question no state regulator has addressed.
How does MCP create a three-party transaction chain?
Managed Agents connects to external tool providers via the Model Context Protocol.1 This is not an internal function call. It is a connection to a third-party server that provides capabilities the agent does not natively have. If that capability is wallet access, the agent’s transaction flows through three infrastructure layers: Anthropic’s container (where the agent runs), the MCP server (which provides the wallet tool), and the wallet provider (which holds or transmits funds).
State money transmitter statutes turn on who “controls” funds in transit. The CSBS Money Transmission Modernization Act, adopted in whole or part by 31 states, is technology-neutral12 — but technology-neutral does not mean architecture-neutral. The three-party chain that MCP creates does not map cleanly onto the two-party analysis (deployer and user) that existing guidance contemplates. Is the MCP server operator a money transmitter? Is the deployer transmitting “through” the MCP server, or is the MCP server an independent actor?
No state regulator has addressed this. The NYDFS October 2024 industry letter on AI addresses it solely as a cybersecurity threat and “does not impose any new requirements beyond obligations that are in DFS’s cybersecurity regulation codified at 23 NYCRR Part 500.”13 No DFPI, Texas DOB, or CSBS guidance reaches the three-party MCP-connector question.
Does Amazon v. Perplexity apply to MCP-mediated transactions?
Amazon v. Perplexity underscores the stakes. The court held that Perplexity — the deployer — was the entity “accessing” Amazon’s systems through its agent, not the user who directed the agent to act.7 A court applying the same logic to a Managed Agent using an MCP wallet connector would ask who built the transaction chain. The answer is the deployer. The CFTC’s December 2024 staff advisory confirms that “CFTC-regulated entities must maintain compliance with applicable requirements whether they choose to deploy AI or any other technology, either directly or by a third-party service provider”14 — but neither the advisory nor any state regulator has addressed which party in a multi-layer architecture bears the obligation.
If your agent moves value through an MCP connector to a wallet API, map every party in the transaction chain against your state money transmitter obligations before the first transaction. The three-party architecture is yours to explain to the examiner.
Are Managed Agents’ Tool Permissions as Bounded as They Look?
No — because bash can execute arbitrary shell commands within the container environment, and the deployer’s actual permission surface is the container, not the four named tool categories in the documentation.
Managed Agents provides four built-in tool categories: bash execution, file operations, web search and fetch, and MCP connectors.1 Three of those categories have defined, bounded functions. Bash does not. Bash is a meta-tool. It can install packages, write scripts, call APIs, manipulate files in ways the other tools do not expose, and chain operations in sequences the deployer did not specifically configure. An agent with bash access to a container that also has network access and wallet credentials through MCP has permissions that exceed what any specific task requires.
The standard of care is informed by the OWASP Top 10 for Agentic Applications, which identifies excessive agency — granting AI systems unchecked autonomy, tool access, and credential scope — as a critical vulnerability.15 A deployer who grants bash access to a container with both network connectivity and sensitive integrations has granted permissions that the industry’s own published standards identify as excessive. The negligent enablement analysis from our prior work applies directly: deploying with capabilities that exceed governance controls’ ability to constrain them is a breach of the standard of care, informed by the frameworks the deployer chose not to follow.3
A court evaluating whether the deployer took “reasonable steps” will look at the tool configuration and ask a simple question: why did an agent tasked with generating reports have bash access to a container with wallet connectivity?
Your agent’s permissions are not what the tool list says. They are what bash can do inside the container. Design authority boundaries around the actual permission surface, not the documented one.
What Compliance Framework Applies to Claude Managed Agents?
Each of the five KYA pillars — Identity, Authority, Monitoring, Incident Response, and Compliance Readiness — maps to a specific Managed Agents architectural feature and the specific regulatory obligation the deployer already has, providing the structured governance layer that NIST’s February 2026 concept paper poses as open questions but does not answer.6
| KYA Pillar | The Deployer Question | What to Build for Managed Agents |
|---|---|---|
| KYA-ID | Which Agent version, with which tool config, ran this session? | Agent versioning discipline; configuration snapshots at session creation; traceable link from any transaction to the agent state that produced it |
| KYA-AUTH | What can this agent actually do — the tool list, or the container? | Tool permissions AND container-level constraints; MCP connector scoping; bash restrictions; human-in-the-loop gates before high-consequence actions |
| KYA-MON | Can you produce a reviewable log of every action, including bash commands and MCP calls? | Session event stream capture; MCP call logging; bash command audit trail — built before the first production session, not after the first audit |
| KYA-IR | Who holds the kill switch for a persistent session with wallet access? | Session termination protocol; escalation path; response timeline; tested before deployment, not after the first incident |
| KYA-COMP | Can you map agent actions to authorizations to policies for a regulator? | Feature eligibility table cross-referenced against deployer obligations; GDPR Article 30 records; CPPA ADMT readiness (January 1, 2027)16; EU AI Act Article 50 transparency (August 2, 2026)17 |
The NIST NCCoE’s 11-page concept paper — “Accelerating the Adoption of Software and AI Agent Identity and Authorization,” published February 2026 with a comment period that closed April 2, 2026 — poses five open questions about agent identification, authorization, delegation, logging, and data flow tracking.6 The paper explicitly names the Model Context Protocol among the standards under consideration, alongside OAuth 2.0, SPIFFE/SPIRE, and Zero Trust Architecture. It does not propose a governance framework. It asks for one.
KYA provides the legal governance layer. Where NIST asks “how should agent actions be linked to the identity of the non-human entity?”, KYA-ID answers: through versioned, traceable agent configurations, because the deployer bears direct liability for the agent’s actions and must reconstruct the decision chain in litigation. Where NIST asks about “dynamic policies” and “least privilege for unpredictable agents,” KYA-AUTH answers: the authority boundary for a Managed Agent with bash access is the container, not the tool list, and the deployer must configure both because negligent enablement liability turns on what the agent could do, not what the deployer intended.
Anthropic’s documentation provides the compliance inputs. The API and Data Retention page states: “Beta features: Features in beta are generally not covered under the BAA unless explicitly listed as eligible in the feature eligibility table.”5 Code execution and MCP connectors are marked HIPAA-ineligible. The data residency page states: “Workspace geo is set when you create a workspace and can’t be changed afterwards. Currently, ‘us’ is the only available workspace geo.”18 And the retention policy provides: “Even with ZDR or HIPAA arrangements in place, Anthropic may retain data where required by law or to combat Usage Policy violations… Anthropic may retain inputs and outputs for up to 2 years.”5
The feature eligibility table is your compliance map. The certifications page is not. Start there.
How Should a Crypto Treasury Platform Evaluate Managed Agents Deployment?
A venture-backed fintech platform evaluating Managed Agents for stablecoin payment orchestration, cross-session portfolio reporting, and investment-recommendation drafts faces all three architectural triggers in a single deployment.
The persistent-session trigger. The platform’s reporting workflow accumulates client portfolio data, risk preferences, and prior recommendations across sessions. Under the advisory relationship analysis above, this session architecture strengthens the case that the platform is “engag[ing] in the business of advising” under the Advisers Act. The platform’s counsel must evaluate registration status based on the session design, not just the agent’s nominal function.
The MCP connector trigger. The payment orchestration workflow routes stablecoin transfers through an MCP connector to a third-party wallet API. Three parties touch the transaction. The platform must map each party’s role against its state money transmitter obligations — and determine whether the MCP server operator’s involvement changes the classification analysis.
The bash-and-container trigger. The agent has bash access for generating custom reports. That same bash access, in a container with network connectivity and MCP wallet access, means the agent can theoretically initiate transactions the deployer did not intend. KYA-AUTH requires the platform to constrain the container, not rely on the tool list.
The output is a deployment decision tree: the reporting workflow goes live with human-in-the-loop gates and an Advisers Act opinion from counsel. The payment workflow gets re-scoped to isolate wallet access from the agent’s general-purpose container. The recommendation workflow proceeds only after the session architecture has been reviewed against the feature eligibility table and the platform’s BAA scope.
The framework does not tell a deployer “yes” or “no.” It tells them which architectural decisions are legal decisions — and where to get the answer before the examiner asks the question.
What Should Deployers Do in the Next 90 Days?
This week. Read Anthropic’s API and Data Retention page — including the feature eligibility table — the data residency page, and the Managed Agents overview.1518 Confirm your DPA status.19 These three documents are your first compliance artifacts.
Next 30 days. Map your planned Managed Agent configuration — which tools, which MCP connectors, what session persistence model — against your existing regulatory obligations. If your agent uses MCP for wallet access, start the state money transmitter analysis now. If your agent accumulates client context across sessions, evaluate the advisory relationship question before the first session runs. Run the feature eligibility table against your BAA if you handle protected health information.
Next 60 days. Build KYA-MON (session event logging, MCP call logging, bash command audit trail) and KYA-IR (incident response and session termination protocol) before the first production session. Configure container-level constraints for KYA-AUTH — not just tool-level permissions. For deployers in digital assets, cross-reference against the compliance roadmap in our prior analysis of AI agent liability in DeFi.4
Next 90 days. CPPA ADMT readiness — consumer-rights obligations for significant decisions in finance, housing, education, employment, and health care begin January 1, 2027.16 EU AI Act Article 50 transparency compliance — obligations take effect August 2, 2026.17 These dates are closer than your deployment timeline.
The runway between “interesting beta product” and “live production workflow with regulatory exposure” is measured in weeks. The legal architecture should be built before the technical architecture is deployed.
The Law Does Not Wait for the Beta to Ship
Managed Agents is a cloud-hosted runtime. The compliance obligations it triggers are not cloud-hosted — they are the same obligations that apply to any deployer of autonomous systems, sharpened by an architecture that makes sessions persistent, connections external, and permissions broader than the tool list suggests.
The prior articles in this series established the legal foundation: AI systems are tools, not agents, and deployers bear direct liability for their tools’ conduct.3 That analysis is architecture-agnostic. This article is not. The specific choices Anthropic made — session persistence, MCP connectivity, bash execution, container-based isolation, US-only data residency, beta-status BAA exclusions — create specific regulatory questions that self-hosted agents do not face.
The deployer who maps those architectural choices against their obligations, pillar by pillar, feature by feature, will know where Managed Agents fits in their compliance stack and where it does not. The deployer who does not will discover the answer in an examination or a courtroom.
The KYA framework provides the structure for that mapping. The documentation provides the inputs. The rest is judgment — and judgment is what counsel is for.
Disclaimer: This article provides general information for educational purposes only and does not constitute legal advice. AI, digital assets, and data privacy regulation is evolving rapidly. Consult qualified legal counsel for advice on your specific situation.
Footnotes
-
Anthropic, “Claude Managed Agents Overview,” Anthropic Platform Documentation (2026), available at https://platform.claude.com/docs/en/managed-agents/overview. ↩ ↩2 ↩3 ↩4
-
Duncan Riley, “Anthropic launches Claude Managed Agents to speed AI agent development,” SiliconANGLE (April 8, 2026), available at https://siliconangle.com/2026/04/08/anthropic-launches-claude-managed-agents-speed-ai-agent-development/. ↩
-
Chante Eliaszadeh, “Not an Agent. Not a Defense: Seven Doctrines That Already Hold AI Deployers Liable,” Astraea Counsel (March 2026). ↩ ↩2 ↩3 ↩4
-
Chante Eliaszadeh, “AI Agent Liability in DeFi: Who’s Responsible When the Bot Trades?,” Astraea Counsel (April 2026). ↩ ↩2
-
Anthropic, “API and Data Retention,” Anthropic Platform Documentation (2026), available at https://platform.claude.com/docs/en/build-with-claude/api-and-data-retention. ↩ ↩2 ↩3 ↩4
-
National Cybersecurity Center of Excellence, “Accelerating the Adoption of Software and AI Agent Identity and Authorization” (Concept Paper, Feb. 2026), available at https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization. Public comment period closed April 2, 2026. Authors: Harold Booth, Bill Fisher, Ryan Galluzzo, Joshua Roberts (NIST). ↩ ↩2 ↩3
-
Amazon.com Services LLC v. Perplexity AI, Inc., No. 25-cv-09514-MMC, Doc. 81 at 2-3 (N.D. Cal. March 9, 2026) (Chesney, J.) (order granting preliminary injunction). This is a summary order; the court noted that the written reasoning “is in no manner intended to replicate the entirety of the Court’s factual findings and legal conclusions as explained at the hearing.” Perplexity appealed to the Ninth Circuit on March 10, 2026. ↩ ↩2
-
Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058, 1068 (9th Cir. 2016) (holding “consent that [defendant] had received from [plaintiff’s] users was not sufficient to grant continuing authorization to access [plaintiff’s] computers after [plaintiff’s] express revocation of permission”). ↩
-
15 U.S.C. Section 80b-2(a)(11) (Investment Advisers Act of 1940, Section 202(a)(11)). ↩
-
Anthropic, “Pricing,” Anthropic Platform Documentation (2026), available at https://platform.claude.com/docs/en/about-claude/pricing. ↩
-
Securities and Exchange Commission, “2026 Examination Priorities,” Division of Examinations (2026), available at https://www.sec.gov/files/2026-exam-priorities.pdf. ↩
-
Conference of State Bank Supervisors, “Money Transmission Modernization Act,” available at https://www.csbs.org/csbs-money-transmission-modernization-act-mtma. ↩
-
New York Department of Financial Services, “Cybersecurity Risks Arising from Artificial Intelligence and Strategies to Combat Related Risks,” Industry Letter (Oct. 16, 2024), available at https://www.dfs.ny.gov/industry-guidance/industry-letters/il20241016-cyber-risks-ai-and-strategies-combat-related-risks. ↩
-
Commodity Futures Trading Commission, “CFTC Staff Issues Advisory Related to the Use of Artificial Intelligence by CFTC-Registered Entities and Registrants,” Staff Letter No. 24-17, Press Release 9013-24 (Dec. 5, 2024), available at https://www.cftc.gov/PressRoom/PressReleases/9013-24. ↩
-
OWASP, “Top 10 for Agentic Applications,” OWASP Foundation, available at https://owasp.org/www-project-top-10-for-large-language-model-applications/. ↩
-
California Privacy Protection Agency, “Board Announces Approval of CCPA Regulations by the Office of Administrative Law,” CPPA Announcement (Sept. 23, 2025), available at https://cppa.ca.gov/announcements/2025/20250923.html. ADMT consumer-rights obligations for significant decisions effective January 1, 2027. ↩ ↩2
-
European Parliament and Council Regulation (EU) 2024/1689 on Artificial Intelligence, Article 50 (Transparency obligations for providers and deployers of certain AI systems), available at https://artificialintelligenceact.eu/article/50/. Transparency obligations take effect August 2, 2026. ↩ ↩2
-
Anthropic, “Data Residency,” Anthropic Platform Documentation (2026), available at https://platform.claude.com/docs/en/build-with-claude/data-residency. ↩ ↩2
-
Anthropic, “How do I view and sign your Data Processing Addendum (DPA)?” Anthropic Privacy Center, available at https://privacy.claude.com/en/articles/7996862-how-do-i-view-and-sign-your-data-processing-addendum-dpa. DPA with Standard Contractual Clauses (SCCs) is automatically incorporated into Anthropic’s Commercial Terms of Service. ↩