QuotaGuard gives your agent two fixed outbound IPs, so you can add them to a Composio API key's allowlist and keep every key locked to your own infrastructure.
Composio allowlists each API key by IP. A tool-call to backend.composio.dev from any other address returns a 403, even when the key is valid. Dynamic cloud egress and VPN exits trip that gate constantly.
Set one environment variable, route your Composio calls through QuotaGuard, and register the two IPs once. They stay fixed through deploys, restarts, and plan changes.
You control which IPs are allowed to use each Composio API key, and QuotaGuard supplies the fixed addresses that make the allowlist enforceable. Composio applies the restriction per key, not per organization, so the two IPs your agent leaves from are what every call has to match.
The allowlist is checked against the source IP of the request. That is why a rotating egress breaks it: the key is fine, but the address is one Composio has not seen before.
You configure allowed IPs on each key at dashboard.composio.dev/~/settings/ip-allowlist. Because it is per key, one leaked or over-scoped key does not have to open every origin. Composio recommends configuring this restriction on the keys your agents use.
Composio checks the caller's source IP before the key does its work, so a request from an off-list address is refused with a 403 while the credential itself is still correct. Teams hit this most often behind a VPN or on dynamic, non-static egress.
Your subscription includes two static IPs behind a load balancer. Add both to the key's allowlist so a request served by either one passes. No tool-call to backend.composio.dev leaves from an address the key has not been told to trust.
You get to keep the security control you set up, because a fixed egress removes the reason people give it up. When a 403 blocks a call, Composio's fallback guidance is to add your current IP to the key's allowlist, or, if your app has no static IP, to create a new API key with no IP restrictions at all.
That second path clears the error by removing the protection. A static IP clears it by satisfying the allowlist. Only one of those keeps the key locked down.
Creating a key with no IP restrictions makes the 403 disappear, but it also removes the one control that limits the blast radius if that key ever leaks. You trade a maintenance annoyance for a key that works from anywhere on earth.
When your agent always exits from the same two addresses, you never need the unrestricted fallback. Every key your agents use can carry an IP allowlist, and the allowlist stays two entries long through every deploy and restart.
Composio disclosed a security incident on May 21, 2026 in which a batch of API keys and GitHub OAuth tokens were exfiltrated. Part of the remediation was restricting keys to the IPs an org had recently used, then shipping dashboard IP allowlisting. A stable origin is what makes that kind of restriction practical to keep on.
QuotaGuard Static satisfies the Composio API key allowlist for most agent workloads. When the data your agent moves through Composio's toolkits is regulated, Shield keeps it encrypted end to end. The reliability underneath is the same on both.
Each subscription runs a load-balanced pair with health checks and automatic failover. Register both on the Composio key once, and traffic routes through whichever IP responds, so a single-node issue never turns into a 403 mid-run.
When an agent moves PII or data under SOC 2, PCI-DSS, or HIPAA review through a Composio toolkit, QuotaGuard Shield uses SSL passthrough and does not decrypt the payload in ordinary operation. Static stays the right choice for standard tool-calling and MCP traffic.
Proxies run in eleven AWS regions, selected at sign-up so your calls reach Composio with low latency. Your two IPs stay the same when you upgrade or downgrade, so a key allowlist you set once keeps working.
Common questions about Composio static IPs and QuotaGuard.
Does my Composio integration need a static IP?
You need one whenever you want to keep an IP allowlist on the API keys your agents use, which Composio recommends. The allowlist is enforced against your caller's source IP, so it only holds if your app leaves from a fixed address. If you run entirely without key IP restrictions you can skip it, but then a leaked key works from anywhere. The moment you turn the restriction on, dynamic cloud egress makes it impossible to maintain.
Why am I getting a 403 from Composio with a valid API key?
The key is authorized but the request came from an IP that is not on that key's allowlist, so Composio refuses it with a 403 before the key does anything. The source-IP check runs first, which is why a correct credential still fails from a VPN exit or a dynamic cloud address. Route the call through two fixed QuotaGuard IPs and add both to the key, and the same credential passes every time.
Should I just create a new Composio key with no IP restrictions?
That is Composio's fallback when your app has no static IP, and it does clear the 403, but it removes the protection instead of satisfying it. An unrestricted key works from any address on earth, so a leak has no network boundary to contain it. A static IP is the other fallback in their guidance: keep the allowlist on, register your two fixed IPs, and the key stays locked to your infrastructure.
Where do I set the IP allowlist for a Composio API key?
In the dashboard at dashboard.composio.dev/~/settings/ip-allowlist, per API key. Add your two QuotaGuard IPs there as the allowed entries for each key your agents use. Because the restriction is scoped to the individual key, you can keep a tighter allowlist on high-privilege keys without changing every key in the org at once.
How fast can I set up QuotaGuard for Composio?
About 2 minutes on the QuotaGuard side. Add one environment variable and point your HTTP client at QuotaGuard as the proxy for outbound calls to backend.composio.dev. Then paste your two static IPs into the key's allowlist in the Composio dashboard. There is no migration and no change to how you call the toolkits.
Should I use QuotaGuard Static or Shield for Composio?
Static is sufficient for standard tool-calling and MCP traffic, and it satisfies the API key allowlist. Use Shield when an agent moves regulated PII or your architecture is under SOC 2, PCI-DSS, or HIPAA review, because Shield uses SSL passthrough and does not decrypt the payload in ordinary operation. Some teams run Static for routine automations and Shield for the toolkits that touch regulated data.
Can I get a dedicated IP for Composio?
Yes. Dedicated IPs are included on QuotaGuard Enterprise plans, at $219/month for Static and $269/month for Shield on direct billing. A dedicated pair fits when your Composio key allowlist must not share an origin with any other organization's traffic. Contact QuotaGuard support after signup with your username and preferred region.
What about inbound traffic and webhooks, and does this cover my other AI services?
The allowlist gate is on the outbound path, from your agent to Composio, which is what QuotaGuard fixes. If you also need a fixed inbound endpoint for a callback receiver, QuotaGuard Static includes inbound proxy capability on direct plans starting at $19/month. The same pattern is a static outbound IP for AI agents across the stack, so the two IPs that clear Composio also clear allowlist checks on services like OpenRouter and Datadog.
For over a decade, QuotaGuard has provided reliable, high-performance static IP and proxy solutions for cloud environments like Heroku, Kubernetes, and AWS.
Get the fixed identity and security your application needs today.