Vi begrenset våre egne tjenester

Mythex sitt API tillater 300 forespørsler i minuttet fra én nettadresse. Den grensen finnes for å beskytte oss mot at én person eller ett skript hamrer på API-et. I produksjon begynte den i stedet å avvise våre egne tjenester: den delen av kanten vår som betjener publiserte apper, og tjenesten som kjører AI-agenten. Grunnen er at hver av dem kontakter API-et fra bare en håndfull adresser. Forespørsler som bærer vår interne legitimasjon, er nå unntatt, og alle andre begrenses akkurat som før.

Symptomet

API-et begynte å svare noen av våre egne interne kall med 429 Too Many Requests. Tre typer kall ble rammet, og hver av dem betyr noe for den som bruker Mythex:

• Oppslag på hvilken app som ligger på et eget domene. Når en besøkende åpner en publisert app på sitt eget domene, spør kanten vår API-et hvor den siden ligger. Et 429 der betyr en besøkende som ikke kan nå et nettsted.
• Lagring av en kjørende agenttur. Mens agenten jobber, lagres fremdriften underveis, slik at et svar overlever en oppdatering eller en brutt forbindelse. Et 429 der betyr fremdrift som ikke ble lagret.
• Sjekk av tilgang til en forhåndsvisning. Forhåndsvisningen av en app du bygger, er låst, og låsen spør API-et. Et 429 der betyr en forhåndsvisning som ikke åpnes.

Ingen av disse var folk som kalte API-et. Alle var oss.

Hvorfor det skjedde

En grense per nettadresse gjør én antakelse: én adresse er omtrent én bruker. For folk er det nær nok. For vår egen infrastruktur er det svært feil.

• Tjenesten i kanten som betjener publiserte apper og forhåndsvisninger, kontakter API-et fra noen få delte utgående adresser. Hver besøkende på hver publiserte app, og hver sjekk av en forhåndsvisning, kommer inn og ser ut som om den kom fra en av de få.
• Orkestratoren, tjenesten som kjører agentturer, kontakter API-et fra én containeradresse. Hver kjørende tur, for alle brukere, deler den.

Budsjettet som var ment for én person, ble altså delt på all trafikk fra en hel tjeneste. Tjenestene brukte det opp mellom seg, og begrenseren gjorde det den skulle: den avviste dem.

Løsningen

Våre egne tjenester beviser allerede hvem de er. Hvert internt kall bærer et internt token, og hver rute under API-ets interne del sjekker det tokenet før den gjør noe.

Begrenseren bruker nå den samme sjekken. En forespørsel med et token som stemmer med det interne, står på en tillatelsesliste og telles ikke mot budsjettet per adresse. Alt annet telles akkurat som før: 300 forespørsler i minuttet per adresse.

To detaljer gjorde at dette ikke ble et hull:

1. Et feil token gir ingen passering. Tillatelseslisten matcher bare det ekte interne tokenet. En forespørsel med et oppdiktet token telles og begrenses som alle andre, og de interne rutene avviser den med 401 Unauthorized.
2. Grensen i seg selv ble ikke endret. Vi hevet ikke tallet for å skape rom. Det ville skjult problemet til trafikken vokste igjen, og det ville svekket beskyttelsen i det tilfellet grensen finnes for.

Vi flyttet innstillingene for begrenseren inn i én liten funksjon og skrev tester mot den. Én test sender 20 forespørsler med det interne tokenet til en begrenser satt til å tillate 5, og forventer at alle 20 lykkes. En annen sender vanlige forespørsler fra én adresse og forventer at de fem første lykkes, og at de etterpå avvises. En tredje sender forespørsler med et forfalsket token og forventer at de avvises på samme måte.

Det vi tok med oss

• Grenser bærer med seg antakelser. «Én adresse, én bruker» er innebygd i en grense per adresse. Den slutter å stemme så snart dine egne tjenester sitter bak delte adresser, og mange gjør det: lastbalanserere, kantnettverk, containere, kontornettverk.
• Skill din egen trafikk fra annen trafikk etter identitet, ikke adresse. Adresser forteller hvordan trafikken kommer, ikke hvem som sendte den. Vi hadde allerede en legitimasjon som beviser at et kall er vårt. Begrenseren så bare ikke på den.
• Ikke løs det ved å heve tallet. En større grense ville fått 429-feilene til å forsvinne en stund, beskyttet mindre og feilet igjen senere.
• Se på hvem som blir begrenset. Et 429 som treffer din egen tjeneste, er en feilrapport om grensene dine, ikke et tegn på at begrenseren fungerer.

Hva det betyr hvis du bygger på Mythex

Du trenger ikke endre noe på din side. Publiserte apper på egne domener, agentturer og forhåndsvisninger er ikke lenger avhengige av hvor travelt resten av Mythex har det. Din apps egen trafikk er din apps sak: grensen som beskrives her, gjelder API-et vårt, ikke appene du publiserer.

Hvis du kjører en egen backend, gjelder samme felle for enhver rategrense du legger til. Våre guider om hva et API er og sikkerhetssjekklisten for AI-bygde apper er et godt sted å starte. Og for et annet tilfelle der vår egen infrastruktur kom i veien for seg selv, se hvordan vi fikk deploys ned til null 502-feil.