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
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
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_queryto an unfamiliar host, or anhttp_servicePOST to a non-allowlisted domain/path. agentsh's policy can mark theseapprove, 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)dns_query,net_connect), each with a policy decision (allow/deny/approve/audit).network_rules(e.g.domains: [...]), declaredhttp_services(per-method, per-path rules + approval gating + fail-closed host enforcement), and a PostgreSQL proxy + LLM/DLP proxy.So rule authoring lives in agentsh policy; this issue is about the human-escalation + grants side in the notifier.
Current state in this repo
Request(kind+target+fields;extra="ignore") — network kinds already flow through, just rendered generically (src/remo_cli/notifier/models.py).GrantPredicatematches onkind+targetwithany/exact/prefix(src/remo_cli/notifier/grants.py) — no domain/wildcard semantics.channels/telegram/transport.py) renders known fields generically.Scope
net_connect/dns_query/http_servicekinds, 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.GrantPredicate: match by domain suffix / wildcard (e.g.*.github.com,api.example.com) and by HTTP method/path, not just exact/prefix on a rawtarget. Enables "approve all egress to this known-good destination" without blanket-approving all network.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
kindvalues +fieldsshape for network/HTTP/DNS events (confirm against a live agentshapprovepayload).fields.Out of scope
network_rules,http_services) — upstream config.Links