Large language models work well with Python. They can read a detection rule, understand its logic, identify why it fires, and write a specific modification. Proprietary query languages like Splunk's SPL or CrowdStrike's CQL are not structured in ways LLMs parse reliably, which is why AI features built on top of legacy SIEMs tend to offer general recommendations rather than specific code changes. Panther's detection-as-code foundation is what makes it possible for the AI agent to propose a precise fix to a specific rule rather than generic tuning advice.

Yes, and that control is structural rather than just a setting. Nothing in Panther's detection engine deploys without human approval. AI-generated rules and AI-proposed tuning changes are both presented as reviewable code through GitHub. Detection engineers see exactly what the AI wants to change, why, and what the test coverage looks like. The role shifts from writing every rule manually to reviewing a queue of AI-proposed changes, but the approval gate stays with the engineer.

Standard detection rules fire when known patterns match. Exploratory detections work the other way: they analyze broad datasets to surface suspicious activity that no pre-written rule would have caught. Rather than waiting for a pattern to be identified and codified into a rule, exploratory detections run scheduled analyses across your data lake and return findings for review. They extend detection coverage into unknown threat territory and feed into Scheduled Prompts for continuous threat hunting.

AI-proposed detection changes appear in your existing GitHub repository as pull requests, formatted the same way a detection engineer would submit code: a diff, an explanation of what changed and why, and automated test results. Nothing deploys without a human reviewing and approving the change. For teams already using GitHub for detection management, the workflow fits into existing code review practices rather than requiring a new process.

When an analyst triages an alert as a false positive, Panther traces the outcome back to the specific Python rule that fired it and evaluates whether the detection logic can be refined. If it can, the system proposes a fix as a GitHub pull request with a plain-language explanation, a diff, and unit tests. The same false positive pattern stops recurring once the change is approved. Docker reduced false positives by 85% and Infoblox cut detection tuning time by 70% using this loop.

You describe a threat scenario or known TTP in natural language and Panther generates a complete Python detection rule with filters, dynamic severity logic, and unit tests included. The output is reviewable code, not a black-box configuration. Detection engineers can edit, extend, or reject the generated rule before it goes anywhere. Tealium reduced detection creation time from 4 to 5 hours per rule down to 10 minutes using this workflow.

Detection-as-code means writing security detection rules as version-controlled code rather than configuring them through a GUI or proprietary query interface. In Panther, detections are written in Python — stored in GitHub, reviewed through pull requests, tested via CI/CD, and deployed the same way your engineering team ships software. The practical consequence is that your detection library has history, accountability, and testability built in, and AI agents can read and modify the rules because the logic is structured and parseable, not locked in vendor infrastructure.