Outbound Safety

A resident agent runs 24/7 — without a gate, that's a liability

An agent-initiated outbound message passes through a policy gate before it goes out, enforcing three things per App: a durable rolling-hour rate limit (backed by a counter table, so it survives a restart instead of resetting with the process), quiet hours that block unsupervised sends during a configured local-time window, and a claim guard scanning the message body for patterns that should either be denied outright (blockedClaims) or held for explicit operator approval first (requireApprovalFor).

The gate is deliberately additive and fails open: an App with no outbound policy configured behaves exactly as it always did, and a read failure allows the send rather than silently eating it — a gate that can accidentally block real messages is worse than no gate at all. A human operator's own manual send is exempt from every limit (a person sending a message is not the unsupervised behavior this exists to bound) but is still recorded against the same counter, so the rolling window stays honest either way.

SSRF: checked after DNS resolves, not before

Every outbound HTTP call from an extension or an integration passes an SSRF guard that default-denies non-http(s) protocols and any destination resolving into a private, loopback, link-local, or multicast range — including the AWS metadata endpoint (169.254.169.254) specifically, a favorite SSRF target for exfiltrating cloud credentials. The check runs after DNS resolution, deliberately, because checking the hostname alone would let an attacker register a public-looking domain that resolves straight to 127.0.0.1 and sail past a pre-resolution check. An operator who genuinely needs to reach an internal service can opt out with AGENTIS_EXTENSION_HTTP_ALLOW_PRIVATE — which explicitly transfers responsibility to the operator and is logged every time it's used.

Continue