…v, …)

`read_file_tool` had no sensitive-path deny list. SSH private keys,
`~/.hermes/.env`, ~/.aws credentials, ~/.gnupg secrings, ~/.kube/config,
and shell history were all freely readable, leaving content-redaction
(off by default since 7375341) as the only line of defense — and
pattern-based redaction is best-effort by design.

Add a read-side deny list as the access-control floor:

* `agent/file_safety.py` gains `build_read_denied_paths()`,
  `build_read_denied_prefixes()`, and `is_read_denied()` mirroring the
  write-side helpers. The path set covers credential files (SSH keys,
  `.netrc`, `.pgpass`, `.npmrc`, `.pypirc`, the active HERMES_HOME
  `.env`) and shell history (`.bash_history`, `.zsh_history`,
  `.psql_history`); the prefix list covers `.ssh`, `.aws`, `.gnupg`,
  `.kube`, `.docker`, `.azure`, and `.config/gh`.

* `read_file_tool` calls `is_read_denied()` after the existing device
  / binary / Hermes-internal guards and returns a structured error
  pointing the model at the `terminal` tool (which gates on user
  approval) when a credential read is genuinely intentional.

Scope notes:

* `/etc/passwd` is intentionally not blocked — it's world-readable
  user metadata, not a secret, and `/etc/shadow` is already
  unreadable to non-root callers.
* Shell config files (`.bashrc`, `.zshrc`, …) are write-denied but
  *read*-allowed: legitimate debugging cases (PATH issues, alias
  setup) outweigh the risk, and inline `export FOO=key` strings
  remain covered by `redact_sensitive_text` when the user opts in.
* Symlink shims are caught: `is_read_denied` resolves the input via
  `os.path.realpath` before checking, matching the write-side
  behavior.

Refs NousResearch#16809.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ring

Address Copilot review on PR NousResearch#16851:

**Finding 1 (`tools/file_tools.py:490` — task-relative path bypass):**
``read_file_tool`` previously called ``is_read_denied(path)`` with the
*raw* string. ``is_read_denied`` resolves relative paths against the
Python process cwd via ``os.path.realpath``, NOT the terminal cwd that
``_resolve_path_for_task`` uses. So an agent whose terminal cwd was
``$HOME`` could pass ``".ssh/id_ed25519"``, hit the resolver, get
back ``$HOME/.ssh/id_ed25519`` — but ``is_read_denied`` would resolve
the same string against, say, ``/tmp/runner``, miss the deny list, and
let the read through.

Pass the already-resolved path (``str(_resolved)``) to ``is_read_denied``
so the security check sees the same path the file system sees. New
``test_task_relative_ssh_key_path_does_not_bypass_guard`` covers the
bypass; without the fix the test reads back the SSH key contents,
with the fix it returns the credential-deny error.

**Finding 2 (`tools/file_tools.py:21` — duplicate file_safety import):**
Folded ``is_read_denied`` into the existing
``from agent.file_safety import get_read_block_error`` line.

**Finding 3 (`agent/file_safety.py:99` — misleading "mirrors" docstring):**
Replaced the "Mirrors build_write_denied_paths" claim with a precise
list of the asymmetries: read-deny adds shell-history files and older
SSH key types (``id_ecdsa`` / ``id_dsa``) that the write list omits,
and intentionally drops ``/etc/*`` paths (those are useful to read for
debugging; the truly sensitive ones are already root-only).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…orkers

The ``test_task_relative_ssh_key_path_does_not_bypass_guard`` regression
test passed locally and on a fresh CI runner but failed on Linux CI when
the same xdist worker had previously run a terminal-tool test:

    AssertionError: 'sensitive credential path' in 'File not found: .ssh/id_ed25519'

Root cause: ``_resolve_path_for_task`` prefers the live tracking cwd
(``_file_ops_cache`` / ``_active_environments`` lookups via
``_resolve_container_task_id``) over the ``TERMINAL_CWD`` env var.  A
warm worker carries those caches across tests; my ``test_relative_ssh``
task_id was being resolved against a stale ``"default"`` entry pointing
at the runner workspace, so the resolved path landed at
``/home/runner/.ssh/id_ed25519`` (no such file) instead of the
test-tmp ``$HOME/.ssh/id_ed25519`` we created.

Fix: monkeypatch ``_get_live_tracking_cwd`` to return ``None`` for the
duration of the test, forcing the predictable ``TERMINAL_CWD`` branch.
Also use a unique task_id so we don't share state with sibling tests.

This is purely a test-stability fix — the production guard added in
a1d0427 is unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>