AI Security: Building Threat Detection That Catches What Rules Miss

Why Rule-Based Security Falls Short

Every firewall, WAF, and intrusion detection system you run today is fundamentally rule-based: if traffic matches pattern X, block it. If login attempts exceed N in M minutes, lock the account. If a file hash matches a known malware signature, quarantine it.

Rules catch known threats. They are fast, deterministic, and essential. But they have a fundamental blind spot: they cannot detect novel behavior patterns that do not match any existing rule. The attacker who uses a legitimate admin API to exfiltrate data one record at a time over 6 weeks does not trigger any rule because no single request looks malicious.

The most dangerous threats in 2026 are not the ones your rules catch. They are the ones that look like normal business activity until you aggregate them over time and across systems. AI excels at exactly this kind of pattern recognition.

What AI Threat Detection Actually Does

AI security is not a replacement for traditional security tools. It is a layer on top that does three things your existing tools cannot:

1. Behavioral baseline modeling

The AI learns what "normal" looks like for your infrastructure. Not generic normal — your specific normal. What IPs connect to your admin panel? What time do your developers push code? What is the typical data volume flowing through your API at 3 AM on a Tuesday? How many records does your CRM export feature usually pull?

Once the baseline is established (typically 2-4 weeks of observation), any deviation triggers analysis. Not a block — analysis. The AI evaluates whether the deviation is explainable (a new employee, a marketing campaign spike, a scheduled batch job) or genuinely anomalous.

class BehaviorBaseline:
    def __init__(self, lookback_days=30):
        self.lookback = lookback_days
        self.profiles = {}  # user_id -> behavior profile

    def update_profile(self, user_id, event):
        if user_id not in self.profiles:
            self.profiles[user_id] = {
                "typical_hours": Counter(),
                "typical_ips": Counter(),
                "typical_actions": Counter(),
                "data_volume_daily": [],
                "session_durations": [],
            }
        p = self.profiles[user_id]
        p["typical_hours"][event["hour"]] += 1
        p["typical_ips"][event["ip"]] += 1
        p["typical_actions"][event["action"]] += 1

    def score_event(self, user_id, event):
        """Return anomaly score 0-1. Higher = more unusual."""
        if user_id not in self.profiles:
            return 0.5  # Unknown user, moderate suspicion
        p = self.profiles[user_id]
        scores = []
        # Time of day: is this user normally active at this hour?
        hour_pct = p["typical_hours"][event["hour"]] / sum(p["typical_hours"].values())
        scores.append(1.0 - min(hour_pct * 10, 1.0))
        # IP address: has this user connected from this IP before?
        ip_seen = event["ip"] in p["typical_ips"]
        scores.append(0.0 if ip_seen else 0.7)
        # Action frequency: is this action typical for this user?
        action_pct = p["typical_actions"][event["action"]] / sum(p["typical_actions"].values())
        scores.append(1.0 - min(action_pct * 5, 1.0))
        return sum(scores) / len(scores)

2. Cross-system correlation

A single event in isolation is almost never enough to identify a real threat. The power of AI security comes from correlating events across systems:

• Login from new IP + immediate password change + API key generation = high-confidence account takeover. Each event alone is normal; the sequence within 5 minutes is not.
• Failed SSH login from IP A + successful web login from IP B in same /24 + data export = lateral movement. The attacker failed to brute-force SSH, pivoted to a web vulnerability, and is now exfiltrating.
• Employee downloads CRM export at 11 PM + same employee submitted resignation yesterday = insider threat. The CRM export is normal; the timing and HR context make it suspicious.

An LLM is surprisingly effective at this kind of multi-factor analysis. You feed it a structured event timeline with context from multiple systems, and it produces a threat assessment that accounts for the relationships between events.

3. Natural language threat reporting

When the AI detects something suspicious, it does not send you a JSON blob or a log entry. It generates a human-readable security briefing:

"At 2:47 AM ET, user admin@company.com logged in from IP 194.62.xx.xx (first time seen, geolocated to Romania). Within 3 minutes, the user changed the account password, generated a new API key, and made 14 API calls to /api/customers/export (normal daily average: 0.3 calls). The user's typical login hours are 8 AM-6 PM ET from two US-based IPs. This pattern is consistent with credential compromise followed by data exfiltration. Recommended actions: (1) Revoke the new API key immediately, (2) Force password reset, (3) Review the 14 export API responses for data scope, (4) Check if the original credentials were exposed in any recent breach databases."

Architecture for Small Business

Enterprise security platforms (CrowdStrike, Splunk, Sentinel) cost $10,000-100,000+ per year. Small businesses need the same threat detection at a fraction of the cost. Here is what I build:

Data collection

• Web server access logs — parse nginx/Apache logs for request patterns, IP addresses, user agents, response codes
• Application audit logs — login events, permission changes, data access, API calls (most apps have audit logging, just not analysis)
• Cloud provider logs — Cloudflare security events, AWS CloudTrail, Azure Activity Log
• Email gateway logs — inbound email analysis for phishing attempts, suspicious attachments, impersonation

Processing pipeline

Logs flow through a three-stage pipeline running on a single VPS or container:

1. Normalize — convert diverse log formats into a common event schema (timestamp, source, actor, action, target, metadata)
2. Enrich — add context: GeoIP lookup, threat intelligence feed check (free feeds like AbuseIPDB), user profile lookup, time-of-day classification
3. Analyze — run behavioral scoring, cross-system correlation, and LLM-powered threat assessment for events scoring above the threshold

Alert routing

Not every anomaly deserves a 2 AM phone call. I use a tiered alert system:

• Critical (score 0.9+): immediate push notification + SMS + auto-block the suspicious IP/session. Example: confirmed credential stuffing attack
• High (score 0.7-0.9): push notification + daily summary email. Example: login from unusual location but within business hours
• Medium (score 0.5-0.7): daily summary email only. Example: slightly elevated API usage from a known user
• Low (score below 0.5): logged for trend analysis, no alert. Example: new user agent string from a known IP

Real-World Detection Examples

From systems I have deployed:

• Credential stuffing detection: A client's e-commerce site received 2,300 login attempts over 4 hours from 180 different IPs (rotating residential proxies). No individual IP triggered the rate limit (5 attempts per IP per hour). The AI detected the attack because the collective success rate (0.4%) matched credential stuffing patterns, and 60% of the attempted emails did not exist in the database.
• Insider data collection: An employee's CRM export frequency increased from 2 per month to 3 per week over a 6-week period. Each individual export was small (under 100 records). The AI flagged the trend change and noted it coincided with the employee updating their LinkedIn profile (public signal). The business investigated and found the employee was preparing to leave for a competitor.
• Supply chain package compromise: The npm audit found a dependency update that added a postinstall script downloading a remote payload. The AI's package analysis module flagged it because: (1) the package had not been updated in 14 months, then suddenly published twice in 24 hours, (2) the new maintainer email was 3 days old, (3) the postinstall script was not present in any previous version.

What AI Security Cannot Do

• Replace basic security hygiene — strong passwords, MFA, patched software, principle of least privilege. AI threat detection on top of a leaky foundation is like installing a burglar alarm with the windows open
• Prevent zero-day exploits — if the vulnerability is unknown, the exploit happens before detection. AI can detect the post-exploitation behavior, but the initial breach still occurs
• Operate without false positives — every anomaly detection system produces false alarms. The goal is a manageable false positive rate (under 5% of alerts) that does not cause alert fatigue
• Meet compliance requirements alone — SOC 2, HIPAA, PCI-DSS have specific technical controls that must be implemented regardless of your AI monitoring. AI helps you detect violations, not prevent them architecturally

Getting Started

1. Enable audit logging everywhere. Most platforms have audit logs disabled by default. Turn them on for your hosting, CRM, email, and any admin panel. This costs nothing and is the prerequisite for all security monitoring.
2. Centralize your logs. Ship logs to a single destination (even a SQLite database on a VPS). You cannot correlate across systems if the data lives in 8 different dashboards.
3. Start with login anomaly detection. This is the highest-signal, lowest-noise starting point. Flag logins from new IPs, unusual hours, or impossible travel (login from Ohio, then London 30 minutes later).
4. Add API monitoring second. Track request patterns to your most sensitive endpoints (user data exports, admin actions, payment processing). Set behavioral baselines and alert on deviations.
5. Run monthly security briefings. Even without real-time monitoring, a monthly AI analysis of your aggregated logs surfaces patterns that are invisible in daily noise.

Related Articles