Zero-Trust Egress: Why Butlers Reach Developer APIs Only Through Life Butler

A core tenet of Life Butler is absolute privacy: a Butler bundle runs in an isolated frame with no access to local storage, no ambient cookies, and zero network access. It physically cannot phone home. But what happens when a developer builds a fitness Butler that syncs with their gym booking system, or a financial Butler that fetches exchange rates?

In traditional ecosystem models—from web browser extensions to IDE plugins—giving an extension network access means granting it raw, unmonitored egress. An add-on with network permission can exfiltrate sensitive data, track user telemetry in the background, or phone home to arbitrary endpoints.

This week, we ratified and deployed our architectural answer: Mediated Remote Calls Through Life Butler (ADR BUTLER-2026-10-25-remote-calls-through-life-butler). A Butler still possesses zero direct network capabilities. When it needs its developer's server, Life Butler acts as an authenticated, sanitizing proxy.

Architectural Evaluation: Four Egress Paradigms

When deciding how third-party Butlers interact with external developer servers, we weighed four competing patterns against our privacy commitments:

End-to-End Relay Topology

Every remote call is mediated through Life Butler's hardened edge relay. No browser cookies, auth tokens, or internal network headers ever cross the boundary:

┌───────────────────────────────────────┐
│     Sandboxed Butler Frame (Offline)  │
│     bridge.remote.call('/sync', data) │
└──────────────────┬────────────────────┘
                   │ MessageChannel (postMessage)
                   ▼
┌───────────────────────────────────────┐
│          Host App Shell               │
│     • Enforce user consent grant      │
│     • Dispatch to Life Butler Backend │
└──────────────────┬────────────────────┘
                   │ HTTPS POST /v1/relay
                   ▼
┌─────────────────────────────────────────────────────────────┐
│                 Life Butler Edge Relay                      │
│  1. Verify active user consent & origin whitelist           │
│  2. Scrub ambient headers & resolve IP (anti-SSRF)          │
│  3. Inject HMAC signature & pseudonymous sub_butler_xxx ID  │
│  4. Enforce rate limit (100 req/min) & payload cap (256 KB) │
└──────────────────┬──────────────────────────────────────────┘
                   │ Signed HTTPS POST
                   ▼
┌─────────────────────────────────────────────────────────────┐
│             Developer's Verified Origin                     │
│  • Verify X-LifeButler-Signature (HMAC-SHA256)              │
│  • Process request for pseudonymous user                    │
│  • Return clean JSON payload                                │
└─────────────────────────────────────────────────────────────┘

The Six Guarantees of Mediated Egress

How Developers Implement Remote Calls

Integrating remote calls requires three simple steps: declaring the origin in manifest.json, calling the bridge in your client bundle, and validating the signature on your server.

1. Declaring in manifest.json

{
  "name": "Gym Buddy",
  "version": "1.2.0",
  "permissions": ["tasks:read", "tasks:write"],
  "network": {
    "origin": "https://api.gymtracker.com",
    "justification": "Syncs completed workout tasks to your GymTracker member profile."
  }
}

2. Invoking the Bridge

// Inside your Butler bundle:
const response = await window.bridge.remote.call('/v1/workouts/sync', {
  method: 'POST',
  body: {
    workoutId: 'cardio-5k',
    completedAt: '2026-10-26T08:30:00Z',
    durationMinutes: 28
  }
});

console.log('Sync status:', response.status); // 200 OK

3. Verifying on the Developer Server

// On your backend (e.g. Node.js / Express):
app.post('/v1/workouts/sync', (req, res) => {
  const signature = req.headers['x-lifebutler-signature'];
  const timestamp = req.headers['x-lifebutler-timestamp'];
  const pseudonymousUser = req.headers['x-lifebutler-subject']; // e.g. "sub_butler_9a8f..."

  const expectedSig = crypto
    .createHmac('sha256', BUTLER_SIGNING_SECRET)
    .update(`${timestamp}.${JSON.stringify(req.body)}`)
    .digest('hex');

  if (signature !== expectedSig) {
    return res.status(401).json({ error: 'Invalid Life Butler signature' });
  }

  // Safely associate workout data with pseudonymousUser
  db.workouts.save({ userId: pseudonymousUser, ...req.body });
  return res.json({ success: true });
});

Under the Hood: Kafka-Only Microservice Isolation

To support this mediated egress securely without creating runtime coupling across internal services, we also codified our strict backend communication standard (ADR BACKEND-2026-10-25-kafka-only-service-communication):

• No Database Sharing: Every microservice (developer-api, admin-api,developer-processor, admin-processor) strictly owns its schema. Cross-schema joins and shared database connections are decommissioned.
• No Direct Internal REST: Inter-service coordination occurs solely through Kafka event topics using transactional outboxes. The egress relay receives origin approvals, quota changes, and kill-switch events as event streams, ensuring zero cascading downtime.

Building With Privacy as a Primitive

We believe you shouldn't have to sacrifice data sovereignty to use rich, connected tools. By enforcing mediated, authenticated, and pseudonymous remote calls, Life Butler gives developers the power of cloud backends while preserving our unwavering promise to users: your personal life remains yours alone.

Egress mediation is currently available in the Developer Portal Sandbox. Read the full spec in our Developer Documentation and start testing your integrations today.