🔄 Topic

I gave Hermes access to my phone’s location so it could use it for real tasks — then treated that as a test case for the deny-first personal-data policy gate built a couple of weeks ago, instead of assuming it would just be fine.

🎯 Goal

Add a genuinely sensitive new data source without letting convenience quietly bypass the access-control work already done to protect exactly this category of information.

🛠 What I Did

I built the capability and immediately audited it against the existing policy.

Main areas covered:

  • relayed phone location from the iOS companion to the laptop so Hermes could use it in real tasks — travel-aware reminders, context-aware scheduling, that category of usefulness
  • checked the new location-relay path against the deny-first personal-data gate from a few weeks back: calendar, contacts, reminders, OAuth, email, and external-message tools all resolve to deny-or-ask, never silent allow — location needed the same treatment
  • confirmed location falls under the same personal-data classification as calendar and contacts, rather than treating it as a new, unclassified data type that could slip past the existing rule by not being named yet
  • verified the relay path itself: what triggers a location read, how often, and whether the answer is retained longer than the task that asked for it
  • documented the decision explicitly rather than assuming “it’s obviously personal data” was self-enforcing — the whole point of the deny-first gate was to stop assumptions from being the actual security boundary

🔗 Key Cybersecurity Connections

New capabilities are exactly where policy gates get quietly bypassed — not through malice, but because a new data type didn’t exist when the rule was written, and “surely this counts too” is not the same as verifying it actually does. Location is one of the most sensitive categories of personal data there is; treating its addition as routine feature work instead of a policy-gate test case would have been the mistake.

This is also a callback that matters: a control built weeks ago is only real if it gets exercised against real new cases, not just admired in the commit that introduced it.

🔍 Investigation Questions

  • Does the deny-first personal-data gate actually cover location, or only the categories it was written against?
  • How often is location read, and is the answer retained past the task that needed it?
  • Could a new capability slip past the gate simply by not being explicitly named in its rule list?
  • Is the relay path itself minimized — read what’s needed, discard the rest?
  • Would a stranger reviewing this addition recognize it as personal data requiring the same gate as calendar or email?

🚨 Detection Opportunities

Checks for a new sensitive-data capability:

  • a new data source added without being checked against existing personal-data policy
  • location (or similarly sensitive data) resolving to silent allow under any profile
  • location reads retained longer than the requesting task’s lifetime
  • a capability’s classification decided by assumption rather than an explicit policy check
  • the relay path itself lacking rate limiting or minimization

Example:

project=hermes-location-relay
signal=new_data_source_bypassing_personal_data_gate
risk_area=policy_gate_coverage_gap
triage=explicitly_classify_new_data_type_against_existing_gate_rules

🧭 MITRE ATT&CK Techniques

No direct mapping claimed. This is privacy-by-design and access-control coverage verification for a new sensitive-data source.

🗺 Visual Investigation Diagram

New capability: phone location relay
    ↓
"Is this obviously fine?" — not good enough
    ↓
Check against deny-first personal-data gate
    ↓
Classify explicitly as personal data
    ↓
Verify minimization + retention
    ↓
Documented decision, not an assumption

⚠ Challenges

The temptation was to treat this as “just a feature” since it was genuinely useful and the gate’s existing rule list didn’t literally say “location.” Explicitly stopping to check felt like overhead for something that seemed obviously fine — which is exactly the reasoning that lets obviously-fine things slip past a control.

📚 What I Learned

I learned that a policy gate’s value is proven by how it handles the case it wasn’t explicitly written for, not the cases it was. Location wasn’t named in the original rule; checking whether it should be is what makes the gate a real control instead of a static list.

➡ Next Steps

  • Add location explicitly to the personal-data gate’s documented category list
  • Confirm retention and minimization behavior with a direct test, not just a read of the code
  • Treat every future new capability as a mandatory policy-gate check, not an optional one
  • Revisit the gate’s category list periodically for other data types added since it was written

🧠 Reflection

Building the feature was the easy part. Stopping to ask “does my own policy actually cover this” before shipping it is the habit that makes the earlier weeks of security work mean something beyond the day it was written.

🧩 Lessons Learned

What worked

Treating a new capability as a mandatory test of an existing policy gate instead of an obvious exception to it.

What broke

Nothing yet — which is the point of checking before shipping rather than after an incident.

Why it mattered

Location is exactly the kind of sensitive data a deny-first gate exists to protect, and new capabilities are exactly where such gates get silently bypassed.

Fix / takeaway

Every new data source gets an explicit policy-gate check, regardless of how obviously sensitive — or obviously fine — it seems.

📈 Skill Progression Context

This supports my cybersecurity progression because verifying policy coverage against new data types, rather than assuming existing rules generalize, is core privacy-engineering and access-control discipline.

😄 TL;DR

Gave Hermes my location — and made it prove the personal-data policy gate actually covers it before trusting the feature.