Limitations & Caveats
The English user guide is currently in beta preview. Most of the documents have been automatically translated from the Japanese version. Should you find any inaccuracies, please reach out to Flatt Security.
This page does not exhaustively cover all limitations and caveats of Takumi Guard. Detailed disclosure of the boundaries of defense mechanisms could be exploited to circumvent them, so the content here is intentionally limited.
Blocking Coverage
The Takumi Guard blocklist is continuously updated through an automated analysis pipeline and research by the GMO Flatt Security team, but it cannot detect and block every malicious package before installation. New attack techniques and zero-day malware may not be identified at the time of analysis.
For this reason, Takumi Guard provides breach notifications alongside blocking. If a package that was considered safe at install time is later found to be malicious, users who downloaded it are notified. The combination of pre-install blocking and post-install notification reduces overall risk.
Rate Limits
Takumi Guard applies the following rate limits based on access method:
| Access Method | Rate Limit |
|---|---|
| Anonymous | 2,000 req/min per IP |
| Email-verified token | 10,000 req/min per token |
| Org user token | 10,000 req/10s per token |
| Bot token | 10,000 req/10s per token |
Requests exceeding the rate limit are rejected with 429 Too Many Requests.
The rate limit unit is HTTP requests, not "install commands" or "packages".
As a rough rule of thumb, downloading one package produces around 2 requests (one metadata lookup + one tarball fetch). The exact behavior varies by package manager and cache state — some clients issue additional requests for search, integrity checks, or parallel prefetching.
A single npm install or pip install run can therefore produce tens to hundreds of HTTP requests depending on the size of the dependency tree. When sizing your usage, estimate in terms of request counts derived from your project's dependency graph and CI parallelism, not just the number of install invocations.
The GitHub Actions/Bot rate limit window was reduced from 60 seconds to 10 seconds in April 2026, effectively raising the allowed throughput from ~10,000 req/min to ~60,000 req/min per token. This accommodates large-scale environments with many concurrent GitHub Actions jobs sharing a single token.