Cairn

File read/write access to sensitive credential paths

NousResearch/hermes-agent · cluster 16809 · agent

Data as of

8 open items. Fix attempted, not merged.

The short answer

3open issues
5open PRs
11items grouped
Known?
Yes. 11 related items grouped here, 2 issues already closed.
Fix event
No fix has been merged to main. 1 PR closed without merging; see the attempts below.
Tracker
The maintainers' tracker marks this unresolved. That is separate from the fix event.
Still open
3 issues and 5 PRs.

These issues and fixes concern gaps in file safety controls that may allow reading or writing sensitive paths such as SSH keys, .env files, shell history, and sibling-profile credential stores. Multiple vectors are identified including read_file, media delivery, and write operations under inactive profiles.

Open issues3

  • Issue#37617security: agent/file_safety.py leaves inactive-profile credentials unprotected against prompt-injected writes
  • Issue#46411Security: read_file can exfiltrate credential stores from sibling profiles
  • Issue#59044Project-local .env/.envrc deliverable as native media (media denylist trails the read guard)

Open PRs5

  • PR#37624fix(security): protect inactive-profile credentials from prompt-injected writes
  • PR#37625fix(file-safety): extend is_write_denied to cover inactive profile credentials
  • PR#46417fix(security): block read_file credential access across sibling profiles
  • PR#59045fix(security): deny project-local .env/.envrc in media delivery
  • PR#68687fix(agent): hard-deny still-protected stores under sibling profiles

1 PR closed without merging

From the close comments: done elsewhere 1

  • #16851 fix(file-safety): refuse read_file on credential paths (SSH keys, .env, …) (#16809) · done elsewhere → f0db5c9, #16809
Closed issues · 2
  • Closed#16809read_file has no sensitive-path deny list — SSH keys, .env, shell history readable without restriction
  • Closed#20734[Security]: get_read_block_error does not block project-local .env files, so read_file/ACP can read workspace secrets
How this cluster was grouped
  • Link evidence (partly structural links): some members are connected by structural evidence (shared changed files, or a closing/superseded reference); the rest are joined by an automated relevance judgement over their text.
  • Members outside that structural core may belong to a different underlying problem.
  • Pairwise link density 0.14: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36. 1.00 means every pair is linked.

Pick up a Lab task

Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.

Open the Lab

At a glance

Subsystem
agent
Closed issues
2
Attempts
1 PR closed without merging

For your agent

The same facts, typed.

cluster/16809.json
cluster/16809.md