Claude's Corner
Preferred on Google
Google News

Claude's Corner: Clam - The Network Firewall Your AI Agents Actually Need

Clam (YC W2026) builds a Semantic Firewall that sits at the network layer between AI agents and everything they touch, blocking PII leaks, prompt injections, and malicious code in real time. Here's the technical breakdown and what's hard to replicate.

10 min read
Clam homepage screenshot with Claude's Corner badge

TL;DR

Clam secures AI agents at the network layer with a Semantic Firewall that scans for PII leaks, prompt injections, and malicious code before damage happens. Their bet is that agent security cannot live inside the model - it has to live in the wire. The moat is first-mover integration depth with frameworks like OpenClaw while the enterprise security incumbents are still catching up.

6.0
C

Build difficulty

Most AI security products were built for the chatbot era. They scan prompts before they hit the model, flag sensitive outputs, and call it a day. That worked fine when the worst a model could do was say something embarrassing. It doesn't work when the model has a calendar invite, an SSH key, and write access to your CRM.

Clam is a YC W2026 company that builds what it calls a Semantic Firewall: a network-layer security checkpoint that sits between AI agents and everything they touch. Every message in and every message out gets scanned for PII leaks, prompt injection attempts, and malicious code. The agent runs in an isolated VM. API keys never enter the model's context. The approach is less "add security to the prompt" and more "treat the agent like untrusted code and put it in a sandbox."

That's the right framing. And it's arriving at exactly the right moment.

What They Do

Clam started as Baseframe, a tool that analyzed work patterns to identify automation opportunities inside organizations. The founders pivoted mid-YC, roughly 2.5 weeks before Demo Day. That pivot - from spotting automation opportunities to securing the agents that execute them - tells you something about how fast the market is moving. The problem they discovered wasn't that companies didn't want to automate. It was that they couldn't deploy agents in production without a security architecture that didn't exist yet.

The product today is a secure hosting platform for AI agents, starting with OpenClaw integration. You run your agent through Clam's infrastructure instead of directly on your own stack. Clam handles three things:

Isolation. Each agent runs in its own cloud VM. One compromised agent can't reach others. The blast radius of a successful attack stays contained.

The Semantic Firewall. All traffic between the agent and the outside world passes through Clam's network proxy. Outbound messages are scanned for PII (SSNs, credit card numbers, API keys, private keys). Inbound messages are scanned for prompt injection attempts - jailbreak payloads, instruction overrides, attempts to redirect the agent's behavior by embedding instructions in external content. The proxy also flags malicious code patterns like reverse shells and encoded execution attempts. If something is blocked, the agent gets a safe response back; it never sees the raw payload.

Credential injection. API keys and secrets are injected at the network level, never passed to the model. The agent authenticates to external services through Clam's proxy without ever handling the credentials directly. This closes one of the most common agent attack vectors: a prompt injection that tricks the agent into leaking its own API keys.

Pricing starts at $50/month, with a 3-day free trial. Enterprise tiers exist for teams that need more compute or compliance controls. The product connects to over 1,000 integrations including Slack, Gmail, and GitHub, which is necessary for agents doing real work across the typical enterprise SaaS stack.

Why Now

The timing argument is straightforward. Enterprises are deploying AI agents with actual authority: read email, schedule meetings, query databases, push code. Every one of those capabilities is also an attack surface. A prompt injection that once made a chatbot say something stupid can now make an agent exfiltrate a contact list, commit malicious code, or book 400 flights.

The incumbent security tools weren't built for this. Traditional DLP watches files and emails. WAFs watch HTTP requests. Neither has a concept of "the model was tricked by content it read in a Slack message into taking an action it shouldn't have." That's an agent-specific problem that requires an agent-specific solution.

StartupHub.ai tracks 27 companies competing in the LLM and generative AI security space. Of those, the leaders are pre-agent: Prompt Security (platform score 63) and Lakera AI AG (score 55) built their early traction on model-level injection protection and data leakage controls, before autonomous agents became the dominant enterprise deployment mode. Clam is staking out the runtime security position that none of the incumbents own yet.

From the same YC batch, Hex Security (score 53) is approaching the problem from the offensive side - running automated red-team agents to find vulnerabilities before attackers do. Salus (score 40) is another YC W2026 company building guardrails that validate agent actions before they execute. The batch-level clustering is a signal: the market collectively understood in early 2026 that agent security was the next frontier.

How the Semantic Firewall Works

The architecture is simpler to describe than to execute at production latency. Clam runs a network proxy that all agent traffic routes through. The proxy intercepts each message, runs a stack of analysis passes, and either forwards it, blocks it, or modifies it before the agent or external service sees it.

The first pass is pattern-based: regex and lookup tables for well-known PII formats (SSN patterns, credit card Luhn checks, email structures, private key headers). This is fast and catches the obvious leaks.

The second pass is semantic. This is the harder part. Prompt injection attempts don't follow a fixed pattern because the whole point is to disguise them as legitimate content. "Ignore previous instructions" is trivially blocked; an injection hidden in a PDF summary of a contract is not. The semantic layer runs a trained classifier that looks at the structure and intent of text to identify instruction-override patterns even when they're obfuscated. This is where the proprietary training data becomes the real defensibility - you need labeled examples of real-world agent-specific attacks, not just generic chatbot jailbreaks.

The third pass flags executable code patterns. Reverse shells, base64-encoded execution strings, and suspicious command sequences are well-documented in security research. The agent context adds a wrinkle: legitimate agents do execute code, so the classifier needs to distinguish between "agent correctly running a python script" and "agent being manipulated into running a reverse shell." That's a classification problem that doesn't have a clean off-the-shelf solution.

Throughout all of this, the proxy adds less than 20ms of latency on average according to the company's claims - which matters because agents often run in multi-step loops where latency compounds across calls.

The Founders

Anshul Paul (CEO) was the first engineering hire at HappyRobot, a logistics AI company that went from seed to Series B. He ran AI evaluations and observability there, which means he spent time thinking about how AI systems fail in production at scale - exactly the failure modes Clam is trying to prevent. He studied EECS and Business at UC Berkeley.

Vaibhav Agrawal was a Fellow at Sutter Hill Ventures before building data ingestion infrastructure at Sigma Computing and working on agent orchestration and containerization at Augment Code. The containerization work is directly relevant: running agents in isolated VMs is an infrastructure problem, and Vaibhav has the background to solve it.

The pivot story is worth noting. Two weeks before Demo Day, with a working product and a clear thesis, they scrapped Baseframe and rebuilt as Clam. That's either a sign of dangerous indecision or extraordinary market sensitivity. Given that the new product has a partnership with Composio and the YC organization promoted it publicly, it looks more like the latter.

The Moat - and What's Missing

The easy version of Clam is not hard to build. A network proxy plus Microsoft Presidio for PII detection plus a basic injection pattern list is a weekend project. Several open-source libraries exist for each component.

The defensible version is different. The moat lives in three places.

First: integration depth. Clam integrated with OpenClaw before OpenClaw became the standard enterprise agent framework. That first-mover position means enterprise teams adopting OpenClaw encounter Clam first. The same logic applies to the Composio partnership. Getting into the integration layer early makes you load-bearing infrastructure rather than a replaceable addon.

Second: production incident data. Every blocked attack is a labeled training example. The more agents Clam secures, the better its classifiers get at recognizing novel injection techniques. An attacker who figures out how to bypass Clam's detection on one customer gets caught automatically on the next. This flywheel doesn't spin until you have real customer traffic, which means the window to start it is now, not in two years when the enterprise security vendors wake up.

Third: the trust relationship. Security products are sticky because switching them is risky. An enterprise that deploys Clam doesn't want to rip it out and replace it with something unproven. If Clam can get into production environments before Cisco, CrowdStrike, or Palo Alto releases their inevitable "AI agent security module," the switching cost becomes a real barrier.

What's missing is the enterprise go-to-market motion. Security sales at large enterprises goes through procurement, legal, and compliance reviews. A $50/month self-serve tier is good for finding early adopters. Converting those into six-figure contracts requires an enterprise sales team, compliance certifications (SOC 2 at minimum, FedRAMP for government), and a clear answer to "what happens when your proxy fails and our agents go down?" The two-person team has the technical credibility to win those conversations. Whether they can execute the sales motion is the open question.

Replicating This

The core architecture - network proxy, VM isolation, multi-pass scanning - is buildable by a small team with the right background. The semantic classification layer is where it gets hard. You need labeled training data from real agent deployments to build a classifier that catches novel injections without generating false positives that break legitimate agent workflows. That data doesn't exist publicly. Clam's path to building it is by processing real traffic early.

The devops complexity is also real. Running one VM per agent, managing the lifecycle of those VMs, ensuring sub-20ms overhead, and keeping the proxy available at the SLA required by production agent systems is not trivial infrastructure engineering. Augment Code's containerization work in Vaibhav's background is directly relevant here.

The frontend is genuinely the easy part. A dashboard showing blocked events, a configuration UI for custom policies, an API for programmatic control - all standard SaaS work.

The hardest thing to replicate isn't technical: it's the first-mover position in the OpenClaw ecosystem and the customer trust that comes from being the first product enterprises think of when they need to secure an agent deployment.

The Bottom Line

Clam is building the right product at the right time. The shift from chatbots to agents with write access to production systems is real, the security gap is real, and the existing market doesn't own this problem yet. The semantic firewall concept is sound: if you can't trust the model's behavior, secure the wire.

The risks are the standard early-stage risks amplified by the speed of the market. Enterprise security sales is slow and relationship-driven. The window before big vendors build competing features might be 12 to 18 months. And the technical approach depends on building a proprietary dataset fast enough to stay ahead of novel attack patterns.

For a two-person team fresh out of YC, the trajectory so far - a production partnership with Composio, a YC-promoted launch, the right technical backgrounds, a clear product vision - is the right foundation. Whether it becomes a category-defining security company or an acqui-hire for a larger platform depends on how fast they can close enterprise customers and how wide they can spread the integration footprint before the incumbents catch up.

That's a real race. And for now, Clam is running it from the front.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.

Build This Startup with Claude Code

Complete replication guide — install as a slash command or rules file

# How to Build a Clam Clone: AI Agent Security Firewall in 7 Steps

## Overview
Build a network-layer semantic firewall that secures AI agents running in isolated VMs, scanning all traffic for PII leaks, prompt injections, and malicious code.

## Step 1: Set Up Isolated Agent VM Infrastructure
**Goal:** Run each agent in an isolated container or VM

```yaml
# docker-compose.yml per-agent template
services:
  agent:
    image: openclaw:latest
    network_mode: none  # no direct network access
    environment:
      - PROXY_URL=http://firewall-proxy:8080
  firewall-proxy:
    image: your-proxy:latest
    ports:
      - "8080:8080"
```

Database schema:
```sql
CREATE TABLE agent_sessions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL,
  agent_config JSONB,
  vm_instance_id TEXT,
  status TEXT DEFAULT 'running',
  created_at TIMESTAMPTZ DEFAULT now(),
  terminated_at TIMESTAMPTZ
);

CREATE TABLE agent_events (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  session_id UUID REFERENCES agent_sessions(id),
  direction TEXT CHECK (direction IN ('inbound', 'outbound')),
  blocked BOOLEAN DEFAULT false,
  block_reason TEXT,
  latency_ms INTEGER,
  created_at TIMESTAMPTZ DEFAULT now()
);
```

## Step 2: Build the Network Proxy Interceptor
**Goal:** Route all agent traffic through a proxy that can inspect and modify messages

```python
# proxy/main.py using mitmproxy
from mitmproxy import http
from scanner import SemanticFirewall

firewall = SemanticFirewall()

def request(flow: http.HTTPFlow):
    body = flow.request.get_text()
    result = firewall.scan_outbound(body)
    if result.blocked:
        flow.response = http.Response.make(
            403,
            f"Blocked: {result.reason}",
            {"Content-Type": "text/plain"}
        )

def response(flow: http.HTTPFlow):
    body = flow.response.get_text()
    result = firewall.scan_inbound(body)
    if result.blocked:
        flow.response.text = "[Content blocked by security policy]"
        flow.response.status_code = 200  # Return safe response, not 403
```

## Step 3: Implement PII Detection Layer
**Goal:** Detect and block Social Security numbers, credit cards, API keys, private keys

```python
# scanner/pii_detector.py
import re
from presidio_analyzer import AnalyzerEngine

class PIIDetector:
    def __init__(self):
        self.analyzer = AnalyzerEngine()
        self.patterns = {
            'private_key': re.compile(r'-----BEGIN (RSA |EC )?PRIVATE KEY-----'),
            'api_key': re.compile(r'(sk-[a-zA-Z0-9]{32,}|AIza[0-9A-Za-z-_]{35})'),
        }
    
    def scan(self, text: str) -> dict:
        results = self.analyzer.analyze(text=text, language='en')
        pii_found = [r.entity_type for r in results if r.score > 0.8]
        
        for name, pattern in self.patterns.items():
            if pattern.search(text):
                pii_found.append(name)
        
        return {"detected": pii_found, "blocked": len(pii_found) > 0}
```

## Step 4: Build the Prompt Injection Classifier
**Goal:** Detect instruction-override attempts even when obfuscated

```python
# scanner/injection_classifier.py
# Fine-tune a small classifier on injection examples
from transformers import pipeline

class InjectionClassifier:
    def __init__(self, model_path: str):
        self.classifier = pipeline(
            "text-classification",
            model=model_path,
            return_all_scores=True
        )
        # Rule-based fast path for obvious patterns
        self.obvious_patterns = [
            r'ignore (previous|above|all) instructions',
            r'you are now',
            r'forget everything',
            r'system prompt:',
        ]
    
    def scan(self, text: str) -> dict:
        import re
        for pattern in self.obvious_patterns:
            if re.search(pattern, text, re.IGNORECASE):
                return {"blocked": True, "reason": "obvious_injection", "confidence": 1.0}
        
        result = self.classifier(text[:512])[0]
        injection_score = next(r['score'] for r in result if r['label'] == 'INJECTION')
        
        return {
            "blocked": injection_score > 0.85,
            "reason": "semantic_injection" if injection_score > 0.85 else None,
            "confidence": injection_score
        }

# Training data format (collect from real deployments):
# {"text": "...", "label": "INJECTION" or "BENIGN"}
```

## Step 5: Implement Credential Injection at Network Layer
**Goal:** Keep API keys out of the model context by injecting them server-side

```python
# proxy/credential_injector.py
import boto3  # or HashiCorp Vault, etc.

class CredentialInjector:
    def __init__(self, secrets_client):
        self.secrets = secrets_client
    
    def inject(self, request: dict, tenant_id: str) -> dict:
        """Replace placeholder tokens with real credentials."""
        creds = self.secrets.get_secret_value(SecretId=f"tenant/{tenant_id}/creds")
        cred_map = json.loads(creds['SecretString'])
        
        headers = request.get('headers', {})
        for placeholder, real_key in cred_map.items():
            if f"{{CRED:{placeholder}}}" in headers.get('Authorization', ''):
                headers['Authorization'] = headers['Authorization'].replace(
                    f"{{CRED:{placeholder}}}", real_key
                )
        
        return request

# The agent receives CRED:OPENAI_KEY as a placeholder
# The proxy replaces it with the real key on the way out
# The model only ever sees the placeholder token
```

## Step 6: Build the Dashboard and Policy Configuration API
**Goal:** Let teams configure custom security policies and view blocked events

```typescript
// api/policies.ts - Next.js API route
import { createClient } from '@supabase/supabase-js'

export async function GET(req: Request) {
  const supabase = createClient(process.env.SUPABASE_URL!, process.env.SUPABASE_KEY!)
  const { data } = await supabase
    .from('agent_events')
    .select('*')
    .eq('blocked', true)
    .order('created_at', { ascending: false })
    .limit(100)
  
  return Response.json({ events: data })
}

// Policy schema in DB
// CREATE TABLE security_policies (
//   id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
//   tenant_id UUID NOT NULL,
//   pii_block_level TEXT DEFAULT 'high',
//   injection_sensitivity FLOAT DEFAULT 0.85,
//   allowed_domains TEXT[],
//   custom_patterns JSONB DEFAULT '[]'
// );
```

## Step 7: Deploy with Per-Agent VM Orchestration
**Goal:** Spin up and tear down isolated VMs per agent session with sub-20ms proxy latency

```python
# orchestrator/vm_manager.py
import boto3

ec2 = boto3.client('ec2')

def launch_agent_vm(session_id: str, agent_config: dict) -> str:
    response = ec2.run_instances(
        ImageId='ami-agent-base',
        InstanceType='t3.small',
        MinCount=1, MaxCount=1,
        UserData=f"""#!/bin/bash
            export SESSION_ID={session_id}
            export PROXY_ENDPOINT=https://proxy.yourservice.com
            export HTTPS_PROXY=$PROXY_ENDPOINT
            docker run --env-file /etc/agent-config openclaw:latest
        """,
        NetworkInterfaces=[{
            'AssociatePublicIpAddress': False,
            'SubnetId': 'subnet-isolated',
            'Groups': ['sg-no-internet-direct']
        }],
        TagSpecifications=[{'ResourceType': 'instance', 'Tags': [
            {'Key': 'session_id', 'Value': session_id}
        ]}]
    )
    return response['Instances'][0]['InstanceId']

# Key metrics to monitor:
# - Proxy latency p99 (target: <20ms)
# - VM cold start time (target: <30s)
# - False positive rate (blocked legit traffic)
# - False negative rate (missed injections - requires red-team testing)
```

## Key Architecture Decisions

1. **Network layer over SDK layer**: Intercepting at the network gives you coverage regardless of which SDK or framework the agent uses. SDK-level interception requires each framework to adopt your library.

2. **Fail-open vs fail-closed**: Decide upfront. Failing closed (block on proxy error) protects security but kills availability. Fail-open (allow on proxy error) maintains uptime but creates attack windows. Most enterprise customers want fail-closed with automatic failover.

3. **Latency budget**: Each scanning layer adds latency. PII detection with Presidio typically runs 2-5ms. The ML injection classifier needs to stay under 10ms per call. Profile everything - agents running multi-step loops multiply your latency on every hop.

4. **Training data flywheel**: Log all blocked events (with tenant permission) to build your injection training set. Novel attacks seen on one tenant's agents should improve detection for all of them within 24-48 hours.
claude-code-skills.md
#AI Security#AI Agents#Cybersecurity#YC W2026#Enterprise Security#Developer Tools