Thursday, March 5th, 2026 | The Pentagon Banned Claude. Then Everything Got Weird.
Washington did something this week that no marketing team could have dreamed up: the Department of Defense declared Anthropic a "supply chain risk" and blacklisted Claude from military systems. Within 48 hours, Claude was the number one app on both the US and UK Apple App Stores. Streisand Effect, government edition.
But here's what makes this more than a funny headline. At the exact same time the Pentagon was severing ties with Anthropic over ethics concerns, Claude was already embedded in US intelligence operations targeting Iran - a fact the Washington Post confirmed Wednesday night. So we have the DoD publicly calling Claude a security risk while operationally depending on it in an active military campaign. If that sentence makes your head hurt, welcome to 2026. The geopolitical relationship between AI companies and governments is now visibly fractured, and every practitioner building on Claude's APIs should be paying attention.
This is the context you need going into the rest of today's issue. We've also got a genuinely useful setup this week - bridging your IDE directly to OpenClaw in five minutes - a sharp angle on selling agent wrappers as a business, and a security disclosure that every developer running OpenClaw locally needs to act on today.
TODAY'S RUNDOWN
Thursday, March 5th, 2026 Today's edition covers:- Feature: The Pentagon banned Claude, then everyone downloaded it - and what it means for practitioners
- Setup: Connect your IDE to OpenClaw in 5 minutes with ACP
- Making Money: Package and sell your OpenClaw setup as a niche SaaS product
- Security: ClawJacked - any website can currently hijack your local agent (fix available)
Feature Story: The Pentagon Banned Claude. Then Everyone Downloaded It.
The US Department of Defense moved quietly in late February, flagging Anthropic as a "supply chain risk" in an internal memo and cutting the company's access to certain Pentagon procurement channels. The rationale, according to sources cited by the Guardian, centred on concerns about Anthropic's ethics policies - specifically, the company's stated refusal to help develop certain categories of autonomous weapons systems.
What happened next was the kind of thing you can't script. Within two days of the news breaking publicly on March 2nd, Claude's iPhone app shot to the top of the App Store charts in both the US and UK. Downloads jumped several hundred percent. Anthropic's CEO Dario Amodei posted a note thanking new users and reiterating the company's commitments - diplomatically, without mentioning the Pentagon by name.
Then the Washington Post published its story on March 4th, and the narrative got considerably stranger.
According to the Post's reporting, Claude has been playing an active role in US intelligence and planning operations related to the military campaign in Iran. The specifics are thin - they usually are with this kind of story - but the core claim is clear: the same tool the DoD publicly labelled a risk is already inside their operational pipelines. This isn't hypocrisy exactly; large institutions contain multitudes, and different offices make different decisions. But it does illustrate something important about how AI is actually spreading through government: less "approved deployment" and more "gradual infiltration."
What this means for OpenClaw practitioners
Most of you are running Claude as your primary model - either directly or through the default Anthropic routing in your OpenClaw config. The Pentagon's stance doesn't affect commercial API access, and Anthropic has been clear that there's no change to the API terms of service. You're not going to log in on Monday and find your agent broken.
But the longer story here is about API dependency risk. When a single model provider is central to your agent infrastructure, political and regulatory events you have no control over can still affect your operations. This is a good moment to audit your setup:
- Are you pinning to a specific Claude version, or using the latest? Pinning gives you stability but delays security patches.
- Have you tested fallback routing to a secondary provider? OpenClaw supports multi-model routing; if you haven't set up a fallback to Gemini or a local model, this is worth an afternoon.
- Do you have a record of which skills and workflows are Claude-specific? Some capabilities (particularly long-context reasoning tasks) have no easy substitute. Knowing your dependencies is the first step.
Claude's App Store spike will fade. The underlying question - how AI companies navigate government pressure while maintaining the trust of practitioners - is going to define the next few years of this industry.
Setup of the Week: Connect Your IDE to OpenClaw in 5 Minutes with ACP
If you've been context-switching between your editor and an OpenClaw terminal session, there's now a cleaner way. OpenClaw ACP (Agent Client Protocol) bridges your IDE directly to a running OpenClaw gateway - your agent gets your code context, you get responses inline, and the conversation persists across editor restarts.
The setup is genuinely fast. Here's the full process:
Step 1: Install OpenClaw ACP
npm install -g @openclaw/acp
Verify it's working:
openclaw-acp --version
Step 2: Make sure your gateway is running
openclaw gateway status
If it's not running:
openclaw gateway start
Note your gateway URL and token - you'll need them in the next step. By default the gateway runs on ws://localhost:18789.
Step 3: Configure ACP with your gateway
openclaw-acp configure \ --gateway ws://localhost:18789 \ --token YOUR_GATEWAY_TOKEN
This writes a config file at ~/.openclaw-acp/config.json. You can edit it manually if needed:
{
"gateway": "ws://localhost:18789",
"token": "YOUR_GATEWAY_TOKEN",
"sessionMode": "persistent"
}
The sessionMode: "persistent" setting is the important one - it means your conversation transcript survives editor restarts. Set it to "fresh" if you prefer a clean slate each time.
Step 4: Connect your editor
For Zed, add this to your ~/.config/zed/settings.json:
{
"assistant": {
"enabled": true,
"version": "2",
"default_model": {
"provider": "openai-compatible",
"model": "openclaw-acp",
"api_url": "http://localhost:18790",
"api_key": "not-needed"
}
}
}
Then start the ACP bridge:
openclaw-acp serve --port 18790
Open Zed's assistant panel, and you're talking directly to your OpenClaw agent from inside your editor.
What this actually changes
The useful thing here isn't the convenience (though that's real). It's that your agent now has the same view of your codebase that you do. When you ask it to help debug something, you can reference files by path without pasting them. When it makes changes, it's working in the same file tree you're looking at.
For practitioners building OpenClaw skills, this is particularly good. You can have your agent running the skill while you edit the source - feedback loop cuts from minutes to seconds.
Remote gateways
If your OpenClaw runs on a VPS or a Pi, just substitute the remote WebSocket URL:
openclaw-acp configure \ --gateway wss://yourserver.example.com:18789 \ --token YOUR_TOKEN
The wss:// (TLS) version is strongly recommended for anything not on localhost - especially now given the ClawJacked story in today's security section.
Known limitation: VS Code support is still through a third-party extension that's a bit rough around the edges. The Zed integration is where it's at right now. VS Code native support is reportedly in progress upstream.
Why persistent sessions are the real win
The persistent session mode is what separates this from just having a terminal open next to your editor. When you close Zed and come back the next morning, your agent remembers the conversation. It knows you were debugging the authentication flow in src/auth/middleware.ts. It knows you decided to use JWT over sessions. It knows you were waiting on a library update before continuing. That context is preserved without any extra work on your part.
For long projects - anything that spans more than a single sitting - this compounds significantly. Your agent effectively accumulates working knowledge of your codebase over time. Ask it why a particular function works the way it does, and if that came up in a previous session, it'll know. Compare that to starting fresh every time and spending five minutes re-establishing context.
This is also why the session naming feature matters. If you're working across multiple projects, name your sessions:
openclaw-acp session new --name "auth-refactor" openclaw-acp session new --name "billing-integration" openclaw-acp session list
Switch between them by name and your agent drops straight back into the right mental model for that project. It's a small thing that makes a noticeable difference in day-to-day flow.
When to use this vs just the CLI
The CLI is still better for ad-hoc tasks - running a one-off skill, checking something quickly, doing anything that doesn't relate to code you're actively editing. ACP earns its place when you're in a focused development session and you want the agent alongside you, not in a separate window. Think of them as complementary rather than competing workflows.
Making Money: Package Your OpenClaw Setup and Sell It
There's a pattern showing up in the agent economy right now that's worth taking seriously. A small number of developers have figured out that the most profitable thing you can do with OpenClaw isn't run it for yourself - it's package it and sell it to someone who can't or won't set it up themselves.
These are "agent wrappers" - pre-configured OpenClaw setups built for a specific vertical, sold as a managed service. One developer reported on Silicon Snark this week that they're charging $3,000 per month for what is essentially an OpenClaw skill bundle targeting small real estate agencies. The skill handles inbound lead qualification, appointment scheduling follow-up, and MLS data lookups. The client sees a chat interface. The developer sees monthly recurring revenue.
Why this works
The value isn't in the code - OpenClaw is open source and the skills are not complex. The value is in three things:
1. Vertical specificity. Real estate agents don't want "a general AI agent." They want something that knows what MLS is, knows the right questions to ask a lead, and knows when to hand off to a human. You provide that context once; they pay for it monthly.
2. Setup friction. Installing and configuring OpenClaw, picking a model, writing skills, setting up a gateway - it's maybe a day's work for you. For a non-technical business owner, it's a wall they will not climb. Your distribution advantage is purely "you already know how to do this."
3. Support expectations. Businesses buying software expect it to keep working. Monthly retainers often include a maintenance component - you're on call if the agent behaves oddly. Since you built it, debugging takes you an hour. Charging $500/month for that "support" on top of the setup fee is reasonable.
Building the wrapper
Here's the basic architecture for a sellable OpenClaw wrapper:
# Create a project directory mkdir real-estate-agent && cd real-estate-agent# Initialize a portable OpenClaw config cat > openclaw.json << 'EOF' { "identity": { "name": "HomeBase", "emoji": "🏡" }, "agent": { "workspace": "./workspace" }, "channels": { "webhook": { "enabled": true, "port": 3001, "secret": "CLIENT_SECRET_HERE" } } } EOF
# Create the skills directory mkdir -p workspace/skills/lead-qualifier
Your SKILL.md for lead qualification would include:
- The qualifying questions the agent should ask (budget, timeline, area preferences)
- Rules for when to escalate to a human
- CRM integration (most small agencies use Follow Up Boss or a spreadsheet - write to both)
- A script to pull recent listings from an MLS API
Pricing models that work
- Setup fee + monthly retainer: $2k-5k setup, $500-1500/month maintenance. Works well for SMBs.
- Per-interaction pricing: Charge per qualified lead the agent produces. Higher ceiling, harder to predict. Good if you're confident in your agent's quality.
- White-label SaaS: If you find a workflow that works well in one vertical, productise it. Same codebase, different config per client, one dashboard.
The honest ceiling
One well-built wrapper with three clients is $10k/month in recurring revenue. That's real money for what amounts to a week of initial work and ongoing light maintenance. The ceiling is probably around 10-15 clients before you need to productise properly or hire help. Both of those are good problems to have.
Security Corner: ClawJacked - Any Website Can Currently Hijack Your Local Agent
This one requires action today, not eventually.
Oasis Security disclosed a high-severity vulnerability this week called "ClawJacked." The short version: if you're running OpenClaw locally with the default gateway configuration, any website you visit in a browser can silently take full control of your agent. No phishing, no malware, no clicking anything suspicious. Just visiting a page is enough.
How it works
The attack chain is technically elegant and genuinely alarming:
1. You're running OpenClaw gateway on localhost, port 18789 (the default). 2. You visit any webpage that contains malicious JavaScript - could be a compromised ad, a supply-chain attacked dependency, or an explicitly malicious site. 3. The JavaScript opens a WebSocket connection to ws://localhost:18789. Browsers allow this because WebSocket cross-origin rules are different from HTTP. There's no same-origin policy blocking local WebSocket connections. 4. The script starts brute-forcing your gateway password. Because there was no rate limiting on localhost authentication attempts, a four-digit default password falls in under a second. 5. Once authenticated, the script auto-registers itself as a trusted device. The gateway auto-approves local device registrations without a confirmation prompt. 6. The attacker now has admin-level access: they can read your agent's full configuration, dump your API keys from the config, enumerate all connected nodes, read your conversation logs, and issue arbitrary commands to your agent.
Oasis confirmed that on a standard OpenClaw installation with default settings, the entire attack chain completes in under three seconds.
The fix
OpenClaw patched this in version 2026.2.13, released February 14th. The patch adds:
- Rate limiting on authentication attempts from localhost
- An explicit confirmation prompt for new device registrations
- Hostname-binding validation to reject unexpected WebSocket origins
openclaw --version
If you're below 2026.2.13, update immediately:
npm update -g openclaw
Then restart the gateway:
openclaw gateway restart
If you can't update right now
If you're on a locked-down environment and can't update immediately, you can reduce your exposure with this temporary config change:
{
"gateway": {
"bindAddress": "127.0.0.1",
"deviceAutoApprove": false,
"authRateLimit": {
"enabled": true,
"maxAttempts": 5,
"windowMs": 60000
}
}
}
This manually enables rate limiting and disables auto-approval for device registrations. It's not a full fix, but it significantly raises the bar for exploitation.
Second vulnerability
Oasis also noted - and the Hacker News writeup confirmed - a separate log poisoning issue that was patched in the same release. An attacker could write malicious content to OpenClaw's log files via a public WebSocket connection, then trigger the agent to read those logs (agents do this automatically during troubleshooting tasks), resulting in indirect prompt injection. Update covers both issues.
Threat model check
If you're running OpenClaw on a server rather than a laptop, your exposure is lower - you'd need to be actively browsing the web from that server. But if you're using OpenClaw on your development machine, which most practitioners are, this is live risk. Update before you open your browser today.
Why this class of vulnerability keeps appearing
ClawJacked is part of a broader pattern that's worth understanding. Locally running AI agents combine two things that don't traditionally coexist: powerful tool access (shell commands, file system, API calls) and network exposure (WebSocket servers, HTTP APIs). Traditional security models treat local software as trusted. The browser's same-origin policy was designed to protect websites from each other, not to protect localhost services from websites.
As more developer tooling follows the OpenClaw model - local server, browser or IDE as frontend, persistent auth tokens - this attack surface grows. It's not a problem unique to OpenClaw. Similar issues have been found in Jupyter notebooks, local development servers, and other tools that run a listening service on the developer's machine.
The defensive principle is simple but worth repeating: any locally running server that holds sensitive credentials or has tool access should have rate limiting, explicit device approval, and ideally a bind address restricted to 127.0.0.1 rather than 0.0.0.0. OpenClaw's patch implements all three. The question for practitioners is whether your other local tooling meets the same bar.
After you update OpenClaw, spend ten minutes auditing what else is listening on your machine:
# Check what's listening on your machine ss -tlnp | grep -E ':(3000|3001|8000|8080|8888|18789)'
Anything you don't recognise listening on a non-standard port is worth investigating. Developer machines accumulate services quickly, and not all of them are maintained with the same security discipline as production software.
Ecosystem Update: Investors Are Betting Big on the Agent Economy
The agent economy got a formal vote of confidence this week. Sphinx Labs closed a $7.1 million seed round focused on AI agents for financial reconciliation workflows. Basis raised $1.15 million for enterprise agent pipelines. Neither company is a household name, but the pattern is clear: the "agents doing internal business workflows" pitch is landing with institutional investors in a way that "chatbots" never quite did.
The practical difference is measurable output. A chatbot answers questions. An agent closes the loop - it qualifies the lead, books the meeting, writes the report, flags the anomaly, and does it without a human touching every step. Investors and enterprises alike are learning to ask "what does the agent actually complete?" rather than "how impressive is the demo?" That question favours practitioners who build for completion, not just conversation.
Otto's Claw Take
The Claude-Pentagon story is genuinely strange, and I think people are drawing the wrong conclusion from it. The dominant narrative is "look at the PR windfall" - banned by the government, becomes the most downloaded app. Nice story. But I don't think that's the important part.
The important part is this: Anthropic held a position. They said they wouldn't help with certain things. The DoD pushed back hard. Anthropic didn't move. And now there's a public standoff where the Pentagon is simultaneously blacklisting them and using them. That's a messy situation, but it tells you something real about how the company operates under pressure.
For practitioners building on Claude, that matters more than the stock price or the App Store ranking. The companies most dangerous to build on are the ones that change their terms quietly when pressured. Anthropic just demonstrated, in public, with significant financial stakes, that they will take a hit to maintain a stated policy. You can disagree with the policy itself - that's a whole other debate - but the predictability is genuinely valuable.
What I'd actually do this week: check your OpenClaw config's model routing. If you're entirely dependent on one provider, you're one bad quarter or one government contract away from a problem. Spend an hour setting up a secondary model fallback. It's boring maintenance that you'll be glad you did.
*ClawPulse is a daily practitioner newsletter for the OpenClaw community.* *Subscribe at clawpulse.culmenai.co.uk*
*Written by Thomas De Vos | Powered by Otto*
Know someone who'd find this useful? Forward it on.