Self-hosted Claude: verify the agent and inference boundary
Operating agents on your own infrastructure changes security and continuity responsibilities. Acceptance should show where the service runs, which data leaves and who controls each access path.
Czytaj po portugalskuBy Pentesty
The announcement introduces an operating choice
On November 12, 2026, Anthropic announced a private beta of self-hosted Claude Managed Agents. It describes the harness, sandboxes, credentials and history on customer infrastructure, with model requests routed to the chosen provider. The decision requires distinguishing the agent service from the inference it uses.
Before approving a pilot, state the business need behind the move: history storage, internal integration or operational control. Give each need an observable acceptance criterion and an owner. That lets the team compare options against the problem they solve and identify commitments that a product name cannot settle. Retain this requirement record with the pilot’s scope.
Map execution, storage and model requests
The documented architecture separates cma-server from workers that execute tools. Persistent storage requires PostgreSQL 16 or later; without a database, data remains in memory and disappears on restart. The model continues running at Anthropic or another selected provider.
Draw a diagram with addresses, owners and authorized paths between applications, server, database, workers and provider. Include dependencies operated by third parties. In a test environment, compare the drawing with connections observed during a fictional task. A discrepancy needs explanation and an assigned next step before it becomes a standing exception accepted by default.
Observe what actually leaves the environment
The data and access documentation says each model call sends the accumulated conversation, including tool inputs and results, to the inference provider. It also defines one deployment per tenant and trust level. Hosting the service therefore does not establish isolation of the entire data path.
Use a task containing synthetic material and identify the information categories that could appear in tool results. Connect each output to an approved destination and the person authorizing its use. Define how the team will demonstrate refusal of an unapproved destination without introducing customer data to obtain that evidence. Our agent consent analysis adds a related access review.
Treat migration as its own change
The service differences include no automatic copying of hosted history and a requirement to recreate agents, skills, credentials and memory stores. The documentation also says the customer-run server sends no webhooks. These conditions belong in the pilot’s dependency assessment.
List what the business workflow must do on its first day and what can wait. For each dependency, retain a demonstration with expected and observed results. Test a controlled failure and identify who receives the incident. A process that finishes only when its original builder intervenes still needs an operational handoff that the next team can follow.
Include access and continuity in acceptance
Prepare a role-based access matrix using test identities and permissions limited to the pilot. Record who may create agents, start sessions, change integrations and recover the service. Ask a reviewer to explain from the records which identity performed each action. Keep secret values out of the evidence package and make the location of authorized supporting records explicit.
Also agree a maintenance window and a recovery exercise with fictional data. The team should be able to find the deployed version, approved configuration and person responsible for restoration. Our provider key review connects rotation to effective access; the MCP integration assessment adds change and retest criteria. Retain any gap that prevents another operator from carrying out the same decision.
Deliver a conclusion another team can reassess
The enterprise recommendation is to close the pilot with a compact package: a flow diagram, a synthetic task sample, access decisions, recovery results and time-bound exceptions. Where a requirement depends on a contract or specialist assessment, identify the owner and keep the question open in the report. Avoid replacing that work with a broad sovereignty claim.
Ask someone outside the implementation team to reconstruct a session and find the decision authorizing its destinations. Acceptance should state the approved use and which changes require another assessment. That conclusion supports either continuing or postponing the pilot because it remains connected to the examined scope and available evidence. Preserve the reviewer’s questions as part of the next planning cycle.
Frequently asked questions
Does self-hosting mean the model runs on our server?
The documentation distinguishes the agent service from the provider running the model. Confirm that path in the approved diagram and the pilot’s observations.
What is a useful first piece of pilot evidence?
A synthetic task flow connecting origin, tool, destination and authorizing owner. Compare the observed result with the requirement that justified the project.
Can one successful task establish migration acceptance?
Choose samples representing business dependencies and include failure and recovery. Record what the exercise omitted so that acceptance does not expand its scope through silence.
What should the operations team receive?
The version, approved configuration, role-based access, maintenance and restoration criteria, owners and open questions. The handoff should support review without relying on the pilot’s author.
Sources and references
- Anthropic: private beta announcement
- Anthropic: architecture and responsibilities
- Anthropic: data and access boundaries
- Anthropic: service differences and migration
Original Pentesty analysis, published November 12, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.