Skip to content

Network-aware approvals (exfiltration defense): render egress + domain/wildcard grant rules #44

Description

@pofallon

Summary

Make the notifier network-aware so outbound-network approvals from agentsh are actionable by a human and matchable by grant rules. The motivating threat is credential / data exfiltration: an agent (or compromised dependency) attempting to POST secrets, tokens, or source to an unexpected destination. agentsh already intercepts and can approve-gate this traffic; the notifier just needs to render and rule-match it well.

Security-motivated enhancement. Relates to #42 (host-enforced injection — ensures the gate is actually present) and the AI grant-suggestion direction.

Threat model

Credential/data exfiltration shows up as anomalous egress: a net_connect / dns_query to an unfamiliar host, or an http_service POST to a non-allowlisted domain/path. agentsh's policy can mark these approve, escalating to a human via the notifier. The human's job is "is this destination expected?" — which they can only answer if the notification shows the destination clearly, and which scales only if "yes, this destination is fine" can become a reusable rule.

What agentsh already provides (upstream canyonroad/agentsh)

  • Intercepts network activity: DNS queries + outbound connects (dns_query, net_connect), each with a policy decision (allow/deny/approve/audit).
  • network_rules (e.g. domains: [...]), declared http_services (per-method, per-path rules + approval gating + fail-closed host enforcement), and a PostgreSQL proxy + LLM/DLP proxy.
  • Linux: solid. macOS (ESF + Network Extension): Alpha. Postgres proxy: Linux-only. (remo runs Linux hosts → fine.)

So rule authoring lives in agentsh policy; this issue is about the human-escalation + grants side in the notifier.

Current state in this repo

  • The notifier consumes a generic agentsh Request (kind + target + fields; extra="ignore") — network kinds already flow through, just rendered generically (src/remo_cli/notifier/models.py).
  • GrantPredicate matches on kind + target with any / exact / prefix (src/remo_cli/notifier/grants.py) — no domain/wildcard semantics.
  • Channel renderer (channels/telegram/transport.py) renders known fields generically.

Scope

  • Network-aware rendering: for net_connect / dns_query / http_service kinds, surface destination clearly in the channel — host/domain, port, method+path (HTTP), and process/command that initiated it. The human must be able to spot "secrets → unknown host" at a glance.
  • Domain/wildcard GrantPredicate: match by domain suffix / wildcard (e.g. *.github.com, api.example.com) and by HTTP method/path, not just exact/prefix on a raw target. Enables "approve all egress to this known-good destination" without blanket-approving all network.
  • Fail-closed preserved: unknown/unparseable destination → no auto-match (deny path unchanged).
  • Exfil-oriented defaults/labels: visually flag egress to destinations not covered by any grant (the "this is the one to look at" signal).
  • Tests mirroring existing grant/transport tests (network kinds, wildcard match, fail-closed on malformed target).

AI grant-suggestion tie-in

Network egress is the highest-value surface for the AI "auto-approve all like this" tier: traffic is high-volume, repetitive, and pattern-rich (same handful of domains). The AI can learn the known-good egress set, propose network_rules-shaped grants, and flag anomalous destinations as candidate exfiltration for human review (propose → confirm → bounded auto-apply; never silent allow). Worth designing the rendering + predicate so this layer can sit on top cleanly.

Open questions

  • Exact agentsh kind values + fields shape for network/HTTP/DNS events (confirm against a live agentsh approve payload).
  • Wildcard syntax for domain predicates (suffix match vs glob) and HTTP method/path matching granularity.
  • Whether to render the initiating process/command (strong exfil signal) — depends on what agentsh includes in fields.

Out of scope

  • agentsh policy authoring itself (network_rules, http_services) — upstream config.
  • The notifier multi-source core (spec 009 unchanged).

Links

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions