Kampala's MITM Proxy: How Agentic Reverse Engineering Turns Apps into APIs Without Browser Automation

Agents need structured APIs. Most workflows live in closed apps. Browser automation breaks when the DOM changes. Computer-use agents burn tokens on pixel diffing. Kampala (YC W26) takes a different path: intercept the network traffic, reconstruct the protocol, and let agents replay the HTTP sequences directly.

This is MITM proxy architecture for agentic workflows. You route traffic through Kampala, it captures every request and response, then exposes the underlying API calls as stable automation primitives. No Selenium. No vision models parsing screenshots. Just protocol-level interception.

Why Network Interception Beats DOM Scraping

Browser automation is brittle because it operates at the wrong layer. You write selectors against rendered HTML. The app ships a CSS refactor and your script breaks. Computer-use agents add vision models to click buttons, but they still depend on visual stability and burn inference budget on every interaction.

Network interception works one layer down. Apps communicate over HTTP, WebSocket, or gRPC. Those protocols are more stable than the UI. A button might move, but the /api/submit endpoint usually stays put. Kampala captures the raw traffic, maps authentication chains, and reconstructs the sequence of calls that make a workflow happen.

Trade-offs:

Stability: Protocol contracts change less often than DOM structure
Speed: Direct API calls skip rendering and JavaScript execution
Observability: You see exactly what data moves between client and server
Scope: Works for mobile apps and desktop clients, not just web browsers
Complexity: You need to handle TLS interception, certificate trust, and session state

Architecture: How MITM Proxies Reconstruct Workflows

Kampala sits between the application and the internet. It installs a root certificate on your machine so it can decrypt TLS traffic. Every HTTP request flows through the proxy, gets logged, and continues to the destination server.

The core challenge is state reconstruction. A workflow is not a single request. It is a sequence: login, fetch CSRF token, submit form, poll for result. Kampala traces these chains automatically by correlating cookies, authorization headers, and request dependencies.

Key components:

Component	Function	Failure Mode
Certificate authority	Generates per-session TLS certs for interception	OS trust store rejects cert, traffic fails
Traffic logger	Captures HTTP/S and WebSocket streams	High-volume apps flood logs, need sampling
Auth chain mapper	Identifies tokens, sessions, refresh flows	Multi-domain SSO breaks correlation
Replay engine	Re-executes captured sequences with new inputs	Rate limits, nonces, or timestamp checks fail
Fingerprint preserver	Maintains HTTP headers and TLS signatures	Server fingerprinting detects proxy, blocks traffic

The fingerprint preservation layer is critical. Many APIs check User-Agent, TLS cipher suites, or HTTP/2 frame order. If your replayed request looks different from the original, the server may reject it or flag the session.

Authentication and Session Handling

The hardest part of protocol replay is authentication. Tokens expire. Sessions time out. OAuth flows involve redirects and state parameters. Kampala needs to handle all of this without manual intervention.

Three patterns:

Bearer tokens: Captured from Authorization headers, replayed until expiry, then refreshed using a captured refresh token endpoint
Cookie-based sessions: Tracked across requests, replayed with the same Cookie header, refreshed when the server returns Set-Cookie
Multi-step flows: CSRF tokens, nonces, or challenge-response sequences that must execute in order

When a token expires mid-workflow, the agent needs a fallback. Kampala can either re-authenticate using stored credentials or pause and request human intervention. The choice depends on your security model.

Security Boundaries and Trust

A MITM proxy holds the keys to decrypt all your traffic. This is a privileged position. If an attacker compromises the proxy or steals the root certificate, they can intercept credentials, API keys, and sensitive data.

Mitigation strategies:

Run Kampala locally, not on a shared server
Rotate the root certificate frequently
Scope interception to specific apps or domains
Store captured traffic encrypted at rest
Audit replay logs for credential leakage

For production use, you need a credential proxy layer (similar to Agent Vault or Infisical). The agent should never see raw tokens. Instead, it calls the proxy with a workflow ID, and the proxy injects the necessary credentials at request time.

When MITM Beats Headless Browsers

Scenario	MITM Proxy	Headless Browser
Mobile app automation	Works natively	Requires emulator or device farm
Desktop app workflows	Captures all traffic	Cannot instrument native apps
API-heavy SPAs	Direct protocol access	Must wait for DOM updates
High-frequency polling	Minimal overhead	Browser process burns CPU
Multi-domain SSO	Sees all redirect hops	Complex cookie/session handling

MITM proxies win when the workflow is protocol-heavy and the UI is irrelevant. If you need to scrape rendered content or interact with JavaScript-driven widgets, you still need a browser. But if the goal is to automate a sequence of API calls, interception is faster and more reliable.

Code Example: Replaying a Captured Workflow

Kampala exposes captured workflows as replayable sequences. Here is a simplified example of what the replay engine does under the hood:

import requests
from kampala import WorkflowCapture

# Load a captured workflow
workflow = WorkflowCapture.load("login_and_submit.json")

# Replay with new inputs
session = requests.Session()
for step in workflow.steps:
    # Inject dynamic values (e.g., new form data)
    if step.name == "submit_form":
        step.body["email"] = "new_user@example.com"
    
    # Preserve original headers and cookies
    response = session.request(
        method=step.method,
        url=step.url,
        headers=step.headers,
        json=step.body,
        cookies=step.cookies
    )
    
    # Handle token refresh if auth fails
    if response.status_code == 401:
        refresh_token = workflow.get_refresh_token()
        new_token = session.post("/auth/refresh", json={"token": refresh_token}).json()
        step.headers["Authorization"] = f"Bearer {new_token['access_token']}"
        response = session.request(method=step.method, url=step.url, headers=step.headers, json=step.body)
    
    # Store response for next step
    workflow.context[step.name] = response.json()

This is pseudocode, but it shows the core loop: iterate through steps, inject new data, preserve fingerprints, handle auth failures, and pass context forward.

Observability and Debugging

When a replayed workflow fails, you need to see where it diverged from the original capture. Kampala logs every request and response, but the key is diffing the two executions.

Useful signals:

Status code mismatch: Original returned 200, replay got 403 (auth issue)
Response body diff: Server changed the API contract
Timing delta: Replay hit a rate limit the original did not
Header variance: Missing or altered headers broke fingerprint matching

A good MITM proxy includes a diff viewer that highlights these discrepancies. Without it, debugging is guesswork.

Deployment Shape

Kampala runs locally on macOS today, with Windows support coming. For production agent deployments, you need a different architecture:

Agent runtime: Runs in a container or VM, isolated from user machines
Proxy sidecar: Kampala runs as a sidecar container, intercepts traffic from the agent
Credential vault: Stores tokens and refresh logic, injects credentials at request time
Replay queue: Agents submit workflow IDs, proxy executes them asynchronously

This keeps the root certificate scoped to the sidecar and prevents agents from accessing raw credentials.

Likely Failure Modes

Certificate trust issues: OS or app refuses to trust the MITM cert, traffic bypasses the proxy
Fingerprint detection: Server identifies the proxy and blocks requests
Session expiry during replay: Token expires mid-workflow, no refresh logic in place
Rate limiting: Replayed requests hit API limits faster than the original capture
Multi-domain SSO: Auth flow spans multiple domains, correlation breaks
WebSocket state: Captured WebSocket frames replay out of order or with stale sequence numbers

Technical Verdict

Use Kampala when you need to automate workflows in closed apps (mobile, desktop, or API-heavy SPAs) and the protocol is more stable than the UI. It is faster and more reliable than browser automation for API-driven tasks.

Avoid it when you need to scrape rendered content, interact with complex JavaScript widgets, or work with apps that aggressively fingerprint traffic. Also avoid it if you cannot safely manage TLS interception certificates in your deployment environment.

For production agent deployments, pair it with a credential proxy and run it as a sidecar. Do not let agents hold root certificates or raw tokens.