> ## Documentation Index > Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt > Use this file to discover all available pages before exploring further. # Security events > Detection rules over your telemetry, runtime threats, exposed secrets and vulnerabilities — what aiAxonIQ detects and what it deliberately does not. Security events are detections raised from your telemetry: authentication failures, suspicious access patterns, exposed credentials and runtime behaviour that matches a rule. **Security is a plan feature.** A request when it is not enabled returns an explicit upgrade error rather than an empty view. Managing rules requires the **Editor** role or above. ## What is here Individual detections, with a status you move as you triage them. What raises an event. Enable, disable, edit, or start from the shipped set. The identities appearing across events — the fastest way to see whether one account is behind several. Behaviour observed at runtime that matches a threat pattern. Credentials detected in telemetry — the ones you accidentally logged. Known vulnerabilities surfaced against what is running. A **summary** and a **timeline** aggregate all of it, which is where to start during an investigation. ## Getting started Rather than writing rules from nothing, seed the shipped detection set and work from there. The starting set covers common patterns; tuning it to your environment is the real work, and it is much smaller than starting empty. **Detections are computed from the telemetry you already send.** There is no separate security agent to install for this and no second data pipeline — which also means detection quality is bounded by what your instrumentation captures. ## Triage Each event carries a status you move as you work it. This is what stops two people investigating the same event and what makes "what did we do about this" answerable a month later. **Detections need tuning or they will be ignored.** A rule producing hundreds of events a day trains everyone to dismiss the whole feed, including the one that mattered. Tune or disable a noisy rule the same day you notice it. An alert nobody reads is worse than no alert, because it looks like coverage. ## Exposed secrets The secrets view finds credentials that appear in telemetry — an API key logged in a request body, a token in an error message. **A detected secret must be treated as compromised, and rotating it is only half the job.** The value is in your telemetry for its full 30-day retention, and there is no surgical delete. So: rotate the credential, then fix the code that logged it, then add redaction at the Collector so the next one never arrives. See [Collector configuration](/send-data/otel/collector-config). Rotating without fixing the logging means the replacement is logged too. ## Alerting on security events Security rules can notify a channel directly, using the same channels as ordinary alerting — Slack, PagerDuty, Teams, OpsGenie and email. Channel credentials are encrypted at rest and decrypted only at delivery. See [Alerting](/guides/alerts/overview) for the channel details, including the one channel that does not work out of the box. ## What this is not **This is detection over observability data, not a security product substitute.** It does not replace endpoint protection, a vulnerability scanner in your build pipeline, a WAF, or an intrusion detection system with network-level visibility. What it does well is catch what is *visible in your telemetry* — which is a genuinely useful surface, and one most teams never look at, but it is a surface rather than a perimeter. ## The audit log is separate Security events are detections about your *systems*. The [audit log](/guides/audit) records changes to your *aiAxonIQ organization* — who invited whom, who created a key, who changed a role. During an investigation you usually want both. ## Next Who changed what in your organization. Least privilege inside aiAxonIQ itself. Governance over what AI agents do.