docs(security): publish production egress IP allowlist

[composio-zen]

Description

Adds a Network access section to /docs/security listing four Composio production egress addresses (TCP 443), so customers who firewall a service Composio connects to can allowlist us:

34.233.50.61/32
54.224.131.195/32
54.243.138.89/32
52.72.72.59/32

Source: the Keyring deployment docs (composio-keyring.mintlify.app/deployment/overview#network-access), requested for the public docs in Slack.

Also regenerates docs/kb/semantic-index.json — the KB artifact pins a content hash over docs pages, so CI's Check KB semantic artifact fails without it.

Open question — please resolve before merging

Is this list Composio's full production egress, or only the Keyring path? The source establishes these addresses for Keyring specifically. Codex review flagged the same overgeneralization three times, and it is a real gap that no amount of rewording closes. The section is currently worded conservatively: the scope is in the lead sentence and an explicit non-guarantee precedes the allowlisting instruction.

Related: /docs/setting-up-triggers/subscribing-to-events tells customers "Composio's outbound IPs are dynamic, so IP allowlists and VPN-only endpoints won't work." The new section explicitly excludes webhook delivery so the two pages agree. If webhooks in fact egress from these same four addresses, that line is stale and both pages should be fixed together.

How did I test this PR

Docs-only change — prose plus a regenerated artifact. No API surface or runtime behavior changed, so there is no unit test to add and no Apollo/Thermos endpoint to exercise. The repo's real guards for this path are the link validator, the KB semantic check, and the site build.

Run from docs/:

• bun run lint:links — exit 0, 0 errored file, 0 errors. Confirms the new /docs/setting-up-triggers/subscribing-to-events#verifying-signatures anchor resolves.
• bun run check:kb-semantic — exit 0, KB semantic artifact is current: 889 records.
• bun run types:check — exit 0.
• bun run lint — exit 0 (warnings are pre-existing, in files this PR does not touch).
• bun run build — exit 0.
• bun run test — exit 1: 508 pass, 2 fail, 1 error. Pre-existing; re-ran with the change stashed on clean next and got the identical 508/2/1. The error is SyntaxError: Export named 'triggerFromApi' not found in module lib/toolkit-schema.ts, unrelated to this diff. CI's test job passes on 2db137e.
• Grype on the changed path: grype dir:docs/content/docs/security --only-fixed --fail-on medium — no vulnerabilities found.

Security

Markdown plus one generated JSON file; no code and no dependency manifests. Socket Security: Pull Request Alerts and Socket Security: Project Report both pass in CI. Grype reports no vulnerabilities on the changed path.

Publishing egress IPs is intentional and standard practice, but the upstream Keyring page carries a caveat that customers should confirm the list with support before changing a production firewall — that caveat is carried into the new section.

Triggered by: abhishek@composio.dev | Source: slack
Session: https://zen.corp.composio.io/dashboard/#/chat/zen-a03dde53b660

[vercel]

You must have Developer access to commit code to Composio on Vercel. If you contact an administrator and receive Developer access, commit again to see your changes.

Learn more: https://vercel.com/docs/accounts/team-members-and-roles/access-roles#team-level-roles

[composio-zen]

Status

CI: green except two failures that are not caused by this diff.

• test initially failed on Check KB semantic artifact — "Semantic artifact docs content hash mismatch". That was real: editing security/overview.mdx invalidates the pinned content hash in docs/kb/semantic-index.json. Fixed by running bun run build:kb-semantic and committing the regenerated artifact (one-line diff, 889 records; the builder reuses the previous artifact so only the changed page was re-embedded). bun run check:kb-semantic now reports "KB semantic artifact is current", and CI test passes on 6d59773.
• claude-review fails with Workflow initiated by non-human actor: composio-zen (type: Bot). Add bot to allowed_bots list or use '*' to allow all bots. Structural to bot-authored PRs in this repo, nothing to fix here.
• Vercel reports "Deployment failed" with no viewable log (the target URL is Vercel's team access-roles page). bun run build for the docs site passes locally with exit 0, and PR fix(providers/anthropic): re-export AnthropicTool, InputSchema, and CacheControlEphemeral types (#4286) #4295 merged with the same Vercel failure, so this looks non-blocking rather than caused by this change.

Passing: check-links (0 errors), test, typescript-check, Detect Secrets, Cursor Bugbot, Socket Security: Pull Request Alerts, Socket Security: Project Report, CodeQL Analyze (actions|python|javascript-typescript).

Open question for review: whether trigger webhook deliveries egress from these same four addresses. /docs/setting-up-triggers/subscribing-to-events currently states the opposite ("Composio's outbound IPs are dynamic, so IP allowlists and VPN-only endpoints won't work"). The new section is scoped so the two pages agree, but if that webhook line is stale it should be corrected in a follow-up.

[composio-zen]

Post-PR status

Codex review: 3 iterations, one finding, not fully resolved — needs a human decision.

Codex flagged the same issue every round: the section generalizes a Keyring-scoped source into a broader claim about Composio egress. Two rewrites landed in response:

• fa66c12 — dropped the unconditional "If Composio calls a service you host behind a firewall, allow..." framing and added an explicit non-guarantee.
• 2db137e — moved the scope into the lead sentence ("If Composio connects to a service you host") so the qualification precedes the instruction rather than trailing it.

Codex still objects, and it is right about the underlying gap: nobody has confirmed whether these four addresses are Composio's entire production egress or only the Keyring path. The only wording Codex would accept scopes the list to Keyring by name, which is not publishable — Keyring has no public docs page. Rewriting further cannot close a provenance gap, so I stopped at 3 iterations rather than keep tuning prose.

Abhishek (@abhishek) / abir — the blocking question is one line: is this list Composio's full production egress, or Keyring-only? If it is Keyring-only, this section should probably wait. If it is platform-wide, the wording can be made more confident and /docs/setting-up-triggers/subscribing-to-events needs its "outbound IPs are dynamic" line corrected in the same pass.

CI on 2db137e: test, typescript-check, check-links, Detect Secrets, Cursor Bugbot, Socket Security (PR Alerts + Project Report), CodeQL Analyze (actions|python|javascript-typescript) all pass.

Two failures, neither from this diff:

• claude-review — Workflow initiated by non-human actor: composio-zen (type: Bot). Add bot to allowed_bots list. Structural for bot-authored PRs.
• Vercel — the vercel bot commented the cause above: "You must have Developer access to commit code to Composio on Vercel." Permissions, not a build failure. bun run build passes locally (exit 0), and PR fix(providers/anthropic): re-export AnthropicTool, InputSchema, and CacheControlEphemeral types (#4286) #4295 merged with the same status.

Local checks (docs/): types:check 0, lint 0, lint:links 0 (0 errors), check:kb-semantic 0 (artifact current, 889 records), build 0. bun run test exits 1 on 2 pre-existing failures + 1 error (SyntaxError: Export named 'triggerFromApi' not found in lib/toolkit-schema.ts) — identical on a stashed clean next, and CI's test job passes.

Testing scope: docs-only diff — prose plus a regenerated kb/semantic-index.json. No API surface or runtime behavior changed, so there is nothing to unit-test and no Apollo/Thermos endpoint to exercise. The repo's actual guards for this path are the link validator, the KB semantic artifact check, and the site build; all three were run and pass.

PR comments: 0 review comments outstanding.