Abuse Policy
This policy defines prohibited behavior, abuse detection principles, and the response model used to protect service availability.
Prohibited activity examples
- Attempted scanning of private, loopback, link-local, or metadata endpoints.
- Credential attacks, spam tooling, or bulk enumeration behavior.
- Evasion attempts against SSRF guards, redirect limits, and validation boundaries.
Detection and controls
- Weighted rate limiting by tool risk and request cost.
- Input validation for domains, URLs, and IP targets with safety constraints.
- Network-layer controls and request throttling at application and reverse proxy levels.
Response model
- Low-severity anomalies may trigger temporary throttling.
- Repeated or high-risk abuse can trigger immediate blocking.
- Severe incidents may require retention of security evidence for investigation.
FAQ
Why are some targets rejected even when reachable?
Reachability does not override safety policy. Private and restricted ranges are blocked by design.
Can false positives happen?
Yes. If legitimate usage is blocked, provide context for review and policy tuning.
Do API keys bypass abuse controls?
No. Keys can raise limits but do not bypass SSRF or safety restrictions.
What evidence should I include in an appeal?
Include timestamp, run ID, expected behavior, and the exact target or workflow context.
Is abuse monitoring localized by language?
Policy applies globally across all localized routes.