# General Threat Detection

For APIs and endpoints that don't fit a specific use case — internal tools, webhooks, backend services — Sentinel can still be applied for broad-spectrum abuse and bot mitigation, without building a use-case-specific flow around it.

## What you're defending against

- **Brute-force attempts and vulnerability scanning** — probing for weak credentials or exposed paths.
- **High-frequency malicious requests** — scripted abuse rather than a specific attack pattern.
- **Bots and scrapers** — automated clients that don't identify as such.
- **Credential stuffing** — reused leaked credentials tested at volume.

## Recommended configuration

1. **Enable [Threat Intelligence](/docs/sentinel/features/threat-intelligence/)** — real-time IP blocklisting from open-source feeds plus Sentinel's own detection of brute-force attempts, vulnerability scans, and other abuse patterns. This is the broadest, lowest-effort layer: known-bad IPs get blocked or penalized before anything else runs.
2. **Enable [Adaptive Captcha](/docs/sentinel/features/adaptive-captcha/)** so blocklisted or otherwise risky requests get an escalated challenge automatically, rather than a flat allow/deny.
3. **Rely on [Detection Signals](/docs/sentinel/features/detection-signals/)** — Header Entropy flags non-standard clients rotating headers to look like different devices, which is a strong bot signal on its own.
4. **Use [Classifier](/docs/sentinel/features/classifier/#using-the-api)** where you have content or metadata to evaluate — it isn't just for text; IP, device, and location classification apply generally.
5. **Keep [Autopilot](/docs/sentinel/features/autopilot/) on** — for a general-purpose endpoint without a specific traffic profile to tune against, automatic adjustment is usually a better starting point than guessing at manual thresholds.

## Working with the Threats API directly

Beyond passive protection, you can query and manage IP reputation programmatically:

- `POST /v1/threat` — check an IP's current status before deciding how to handle a request yourself.
- `POST /v1/threat/report` — report abuse you've detected elsewhere in your stack, contributing toward Sentinel's own rate-limit-based blocking.
- `POST /v1/threat-list` — immediately block (or allow) a specific IP, overriding the threshold-based flow.

See [Threat Intelligence](/docs/sentinel/features/threat-intelligence/#threats-api) for the full request/response details.

## Integration path

1. Finish installing Sentinel.
2. Configure [Threat Intelligence](/docs/sentinel/features/threat-intelligence/) — the data sources and thresholds you need.
3. Add [Classifier](/docs/sentinel/features/classifier/) calls anywhere you have content, IP, or device data worth scoring.

## Related

- [Threat Intelligence](/docs/sentinel/features/threat-intelligence/)
- [Adaptive Captcha](/docs/sentinel/features/adaptive-captcha/)
- [Detection Signals](/docs/sentinel/features/detection-signals/)
- [Rate Limiters](/docs/sentinel/features/rate-limiters/)
- [Classifier](/docs/sentinel/features/classifier/)