🔄 Topic

Building an iOS companion app to control the laptop’s local agent remotely, without exposing anything to the public internet.

🎯 Goal

Get a phone-to-laptop control channel that works over a private network, and polish the app into something worth showing.

🛠 What I Did

I worked on an iOS companion app (SwiftUI) that talks to the local agent daemon on the laptop. The connection runs over Tailscale, so the agent endpoint is a private HTTPS service on the tailnet instead of a port on the public internet. I made provider handling daemon-driven, improved the command center, task list, and new-task flow, and even ran an autonomous coding agent in a persistent session to do polish passes on the app itself. Along the way I checked honestly whether marketing phrases like “works with private HTTPS endpoints” were actually true of the code or still aspirational.

Main areas covered:

  • SwiftUI companion app architecture
  • daemon-driven provider handling
  • Tailscale private HTTPS endpoints
  • command center and task flow polish
  • autonomous agent doing supervised UI passes
  • honest capability claims vs aspirations

🔗 Key Cybersecurity Connections

Remote control of a machine that runs an agent with tool access is a high-value target. Keeping the channel on a private overlay network instead of the public internet is a deliberate attack-surface decision, and verifying claimed capabilities is basic security honesty.

🔍 Investigation Questions

  • Is the agent endpoint reachable only on the tailnet?
  • How does the app authenticate to the daemon?
  • What could a stolen phone do to the laptop?
  • Are agent commands from the phone logged?
  • Do the marketing claims match the implemented code?

🚨 Detection Opportunities

Potential monitoring ideas:

  • connections to the daemon from unknown devices
  • commands issued outside normal hours
  • tailnet device list changes
  • failed authentication attempts against the daemon
  • agent tasks started remotely without a matching session

Example:

project=ios-agent-companion
change_type=remote_control_channel
risk_area=private_endpoint_exposure
triage=verify_endpoint_not_publicly_reachable

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

  • T1021 — Remote Services
  • T1133 — External Remote Services
  • T1078 — Valid Accounts

🗺 Visual Investigation Diagram

iPhone app
    ↓ Tailscale tailnet
    ↓ Private HTTPS endpoint
    ↓ Agent daemon
    ↓ Laptop actions

⚠ Challenges

The challenge was the gap between “it demos well” and “the claim is true.” One sentence about supporting private HTTPS endpoints turned into real work to make the code actually deserve the sentence.

📚 What I Learned

I learned that remote access design is mostly about what you refuse to expose. Starting from a private overlay network made every later decision safer by default.

➡ Next Steps

  • Tighten authentication between app and daemon
  • Add logging for remotely issued commands
  • Keep productizing the companion as a remote agent hub
  • Re-test claims after every capability change

🧠 Reflection

This was useful because it combined building with threat thinking: every convenience feature for me is also a convenience feature for whoever steals my phone.

🧩 Lessons Learned

What worked

Private-by-design networking from the first commit.

What broke

A capability claim that the code did not yet support.

Why it broke

Positioning text was written before the implementation existed.

Fix / takeaway

Verify every security-relevant claim against the code before repeating it.

📈 Skill Progression Context

This supports my cybersecurity progression because secure remote access, endpoint exposure decisions, and honest capability assessment are daily concerns in real security engineering.

😄 TL;DR

Phone controls laptop; internet not invited.