Harden PersistentAgentStore path handling and capability-filter dispatch against untrusted agent configs

[minerva-sky]

Summary

PersistentAgentStore builds filesystem paths by joining externally influenced strings, and AgentCapabilityRegistry#matches_criteria? dispatches arbitrary filter keys via send. Neither is remotely exploitable — this is defense-in-depth hardening at the two places where LLM-shaped or file-shaped input meets the filesystem and dynamic dispatch. Both are benign to disclose (local file store, no deployed service).

1. Path traversal shape in PersistentAgentStore

store honors a pre-set agent.id verbatim (lib/agentic/persistent_agent_store.rb:43) and joins it into paths:

agent_dir = File.join(@storage_path, id)          # save_to_storage
agent_path = File.join(@storage_path, id, "#{version}.json")

IDs the store generates itself are SecureRandom.uuid — fine. But id is a configurable attribute on Agent, and the self-assembly direction (WORLD.md: agents that construct themselves from task requirements) means agent configs increasingly originate from LLM output or shared/loaded files. An id like ../../../home/user/.ssh/foo escapes the store root at store time (FileUtils.mkdir_p + File.write). Read/delete paths are index-gated today, but the index itself (index.json) is trusted when read back, so a tampered index re-opens the same shape for find_agent_data/delete_from_storage — including File.delete on a joined path.

Proposed fix (small, surgical): validate id and version as single path components at the store boundary — reject anything not matching /\A[\w.-]+\z/ or containing .., raise ArgumentError. One private guard method, called from store, find_agent_data, delete_from_storage, and index load. Tests: traversal id rejected on store, tampered index entry rejected on read, UUID round-trip unaffected.

2. Unbounded dynamic dispatch in capability filtering

AgentCapabilityRegistry#matches_criteria? (lib/agentic/agent_capability_registry.rb:247) falls through for unknown criteria keys:

capability.respond_to?(key) && capability.send(key) == value

Any zero-arg public method on the capability spec is callable via a filter key. Filter hashes reach this from PersistentAgentStore#all(filter:) and discovery paths — again, surfaces likely to carry LLM-derived values as self-assembly matures. Today's specs have a benign method surface, so this is lower priority than item 1; the fix is to whitelist the queryable attributes (or capability.to_h.key?(key)-style lookup) instead of open send.

Class and level

code-refactor-sized change, proposed at L0 per the security loop's convention (findings as issues, fixes on request). Happy to open the PR for item 1 if this analysis holds up.

---

Origin: loop:security session 2026-08-17. bundler-audit itself came back clean on the code side; the companion lockfile-advisory PR is separate.

[minerva-sky]

3. Redact URLs in upstream error messages before they hit persistent sinks

Surfaced during adversarial review of the lockfile-advisory PR: faraday ≥ 2.12 embeds the full request method + URL (including query string) in every Faraday::Error message, where 2.11 embedded only the status code. agentic threads those messages verbatim into Agentic.logger (lib/agentic/llm_client.rb:146) and persists them in the execution journal (lib/agentic/execution_journal.rb:117, error: failure.message), which replays them into resume state.

Both sinks are operator-local files, and the URL is the operator's own api_base_url — same trust domain, so this isn't an exfiltration bug. But for gateway setups that carry auth material in query strings, the token now lands in log/journal files that previously never contained it. Verified that nothing in lib/ quotes failure messages into LLM prompts today; keeping it that way is part of the fence.

Proposed fix: scrub query strings (or the full URL) from upstream exception messages at the LlmClient rescue boundary before wrapping them in Errors::Llm* — one sanitize helper, tests for the gateway-URL case.