SalienceNotes.dev
Writing / Article

Threat Model Your Life

A compact framework for mapping trust boundaries across identity, devices, cloud services, and automation.

Solly · 5 min read · Updated
Contents

Category

Article

Tags

cybersecuritythreat modelingidentitycloud

Contents

When a personal stack gets large enough, it starts to behave like a small enterprise environment: one identity provider, a few critical devices, several third-party SaaS accounts, and at least one automation layer that can modify everything if it is misconfigured.

That is the point where casual “best practices” stop being useful. The better move is to write the stack down as a system and identify the trust boundaries, similar to how I mapped out my personal technical stack architecture for this blog.

Personal stack as connected boundaries

Identity

Assets
Primary email, MFA / passkeys, recovery channel
Connects to
Device, Cloud

Device

Assets
Laptop, phone, browser sessions
Connects to
Identity, Cloud

Cloud

Assets
GitHub, DNS / registrar, blog hosting
Connects to
Identity, Automation

Automation

Assets
CI / CD, scripts, API tokens
Connects to
Cloud, Identity
Personal stack as a small system with separate trust boundaries. The useful question is which asset sits behind which control.

Start with assets

The useful assets are rarely just files or code. For a personal tech stack, the real assets are:

  • primary identity and recovery channels
  • password manager vaults and backup exports
  • laptop, phone, and browser session state
  • cloud provider credentials and API keys
  • published content and DNS ownership

Once those are listed, the attack paths become clearer. A browser compromise is different from an account takeover. A lost phone is different from a leaked GitHub token. That distinction matters when deciding where to spend time.

Draw the boundaries

I keep the model simple:

  1. Identity boundary
  2. Device boundary
  3. Cloud boundary
  4. Automation boundary

Each boundary needs a different control story. Identity needs strong recovery and phishing resistance, which is best achieved by securing central identity providers using modern authentication protocols. Devices need patching, encryption, and account separation. Cloud services need least privilege and explicit ownership. Automation needs narrow scopes and a revocation path.

Boundary controls by failure mode

Identity

Threat
Phishing or takeover
Control
Passkeys and MFA
Recovery
Revoke sessions

Device

Threat
Lost laptop or stolen session
Control
Encryption and screen lock
Recovery
Remote wipe

Cloud

Threat
Public exposure or token leak
Control
Least privilege and secret scan
Recovery
Rotate secrets

Automation

Threat
Prompt injection or token misuse
Control
Read-only tools and approvals
Recovery
Pause write access
Each boundary needs a different control pattern. The recovery step matters as much as the preventative control.

Write down the failure modes

The useful question is not “what if everything fails?” It is “what is the most likely failure at each boundary?”

  • Password manager breach
  • OAuth token leakage
  • Public config file exposure
  • Lost device with active sessions
  • Prompt injection into an AI tool with write access

Each failure mode should map to one mitigation and one recovery step. If a control cannot be reversed, it is probably too blunt. For logging systems, this means setting structured logs and retention policies that let you audit session compromise without creating new data leaks.

Failure modes mapped to response

Password manager breach

Impact
Vault exposed
Mitigation
Unique vault password
Recovery
Reset credentials

OAuth token leakage

Impact
SaaS or API abuse
Mitigation
Short-lived scopes
Recovery
Revoke tokens

Public config file exposure

Impact
Secrets or endpoints exposed
Mitigation
Secret scanning
Recovery
Rotate and remove

Lost device with sessions

Impact
Authenticated access open
Mitigation
Disk encryption
Recovery
Revoke sessions

AI tool write access abused

Impact
Unsafe writes or exfiltration
Mitigation
Read-only tools
Recovery
Pause write access
Failure modes become easier to handle once each one has a mapped impact, mitigation, and recovery step.

Outcome

The practical result is less complexity, not more. Threat modeling a personal stack should produce a short list of controls that are worth maintaining every month. If the list is long, the architecture is too noisy.

The goal is not perfect safety. The goal is a stack that can survive routine mistakes without turning them into incidents.