Claude gets a safer path into private systems

Today's Claude signal is not a new button. It is more useful than that: Anthropic is showing how Claude agents can work when the systems they need should not be open to the internet. For practical teams that want to connect AI to tickets, databases, documents or internal tools, this is often the missing step between a demo and real operations.

The latest: private connections without open doors

On May 19, Anthropic added two important platform updates to Claude Platform: MCP tunnels in research preview and self-hosted sandboxes for Claude Managed Agents. Claude Managed Agents is Anthropic's platform for running agentic workflows, meaning AI workflows where the model plans, uses tools and continues across several steps. A sandbox is a bounded execution environment where tools and code can run without getting free access to the rest of the organization's systems.

The point is simple: the agent can still be orchestrated through the Claude platform, while tool execution and private systems can stay closer to your own infrastructure. MCP, Model Context Protocol, is the open standard that lets AI apps connect to data sources, tools, and workflows. An MCP tunnel is a protected path from Claude to private MCP servers without making that server public.

Source: Claude Platform API release notes and Model Context Protocol introduction.

Claude Code also had a new version, 2.1.150, but it was explicitly internal infrastructure with no user-facing changes. That makes today's practical signal broader than the terminal: how Claude connects to real systems in a way security and operations people can actually live with.

Source: Claude Code v2.1.150 release.

Why this matters for practical teams

Many AI pilots get stuck in copy-paste mode. Someone exports context, pastes it into chat, asks Claude to write a reply, then moves the result back by hand. That is fine for learning. It scales badly.

With MCP and sandboxes, the question gets more concrete: which systems may Claude read, which actions may it suggest, which actions may it execute, and where should a person approve the work? A service company might let Claude read tickets and draft replies, but require approval before anything reaches a customer. A finance team might let Claude compare invoice lines with contracts, while logging decisions and blocking anything that changes payments.

That is the kind of map we build in Tool Forge: not just "connect AI", but decide which connections are worth having, what permissions they need, and how review, logging and stop buttons should work.

How to test the signal this week

Pick one workflow where Claude already helps, but people still move data manually between two systems. Good candidates are customer tickets, proposal material, internal knowledge articles or report drafts.

Then sketch the integration before you build anything:

• Which systems does Claude need to read?
• Which tools does Claude need to use?
• Put secrets in environment variables or a secret manager, not in chat.
• Narrow permissions with scoped API keys or a dedicated service user where possible.
• Mark the steps that require human approval.
• Save logs as metadata without storing customer text, passwords, or full prompts.

This is an integration question, not a sermon about "do not share data". Done well, Claude can get more useful context with less mess: narrow permissions, redacted excerpts, approval gates and audit logs instead of free-form text dumps.

Try this prompt this week

Use it in Claude chat if you want to plan the workflow, or in Claude Code if you want to move toward a technical sketch. Start with a process you understand well and where you can review the result before anything affects a customer.

You are my integration architect for a Claude workflow.

Workflow: [describe the process, for example "handle incoming service tickets and draft replies"]
Systems that may be relevant: [ticketing system, CRM, documents, database, email, GitHub, Notion or something else]

Create a practical map with:
1. What information Claude needs to read and why.
2. Which actions Claude may only suggest, and which actions it may perform after approval.
3. If MCP fits: which MCP servers or internal APIs are needed, and should they be local, private through a tunnel or public?
4. Where a sandbox is needed for code, files or tool execution.
5. How secrets are handled: environment variables, secret manager, scoped API keys and least privilege.
6. Which fields should be redacted before text is sent to Claude.
7. Which audit logs we need: time, system, action, decision, human approval and errors.
8. A first dry run with no external side effects.

End with a simple risk list and a recommended first version that can be tested in an afternoon.

A good result looks like this:

• Claude separates read access, write access and approvals.
• Secrets end up in env vars or a secret manager, not in the prompt.
• MCP is used for real system connections, not as a buzzword.
• There is a dry run where nothing is sent, changed or published.
• A person has a clear point where the work can be approved, changed or stopped.

What we are watching next

MCP tunnels are still in research preview and self-hosted sandboxes are a platform capability to evaluate, not something every small team needs tomorrow. But the direction is clear. Claude is moving from "smart chat" toward a work environment where the agent can reach the right systems, use the right tools and still stay inside clear boundaries.

For Hammer readers, the next step is not to chase every release. It is to choose one real workflow and draw the boundaries properly: data in, tools out, human control in the right place.