'%3e%3crect%20x='-10'%20y='-10'%20width='120'%20height='140'%20fill='%231C1917'/%3e%3crect%20x='-10'%20y='38'%20width='120'%20height='16'%20fill='%23EA580C'/%3e%3crect%20x='-10'%20y='70'%20width='120'%20height='16'%20fill='%23EA580C'/%3e%3cpath%20d='M50%200Q30%2017.5%200.8%2018.7C-1.5%2080%2022%2097%2050%20118C78%2097%20101.5%2080%2099.2%2018.7Q70%2017.5%2050%200Z'%20fill='none'%20stroke='%23FFFFFF'%20stroke-width='18.0'/%3e%3c/g%3e%3cpath%20d='M50%200Q30%2017.5%200.8%2018.7C-1.5%2080%2022%2097%2050%20118C78%2097%20101.5%2080%2099.2%2018.7Q70%2017.5%2050%200Z'%20fill='none'%20stroke='%231C1917'%20stroke-width='7'/%3e%3c/svg%3e){kind=small}
Anomaly Detection
Finds who did something anomalous and asks them for a justification
Audit records from all three paths are gathered per person and matched against detection rules. Each flagged activity becomes a review case for that person, goes through the person's justification and the reviewer's review result, and is kept in the monthly inspection report.
What is anomaly detection?
Anomaly detection finds activity in audit records that breaks policy or departs from the usual, groups it by person and lets a reviewer reach a conclusion.
Management reads the audit store every 10 seconds and matches the records against the detection rules that are turned on. SQL statements and query results from DAC, commands and file transfers from Server Gateway and prompts from AI Gateway are all recorded under the same person's name, so you see together what one person did across all three paths.
It does not stop at detection. It continues with a justification that asks the person concerned for the reason, the reviewer's review result, exceptions for activity confirmed as normal work and a monthly inspection report that brings together the month's inspections. You do not need to connect a separate analytics product.
Flow
From records to review results
Records that match a detection rule are grouped into review cases that share the same rule, person, destination and day, and then wait for review.
Detection rules
Start with nine presets
Each rule starts as a copy of a preset. You then set its scope (destinations, people, groups), count threshold, severity and automatic justification request. Every value is selected from a list, so a single typo cannot silently disable a rule.
| Detection rule | Product | Default condition | Severity |
|---|---|---|---|
| Blocked SQL execution attempt | DAC | Each occurrence | Medium |
| Restricted server command attempt | Server Gateway | Each occurrence | Medium |
| Attempt to send sensitive data to AI | AI Gateway | Each occurrence | High |
| Denied connection attempts | DACAI GatewayServer Gateway | 3 or more within 60 minutes | Medium |
| Connection attempts blocked at the gateway | All products | 3 or more within 60 minutes | Medium |
| Frequent sensitive data reads | DAC | 100 or more within 60 minutes | Medium |
| Bulk sensitive data read | DAC | 1,000 or more rows within 60 minutes | High |
| Off-hours access | DACServer Gateway | Each occurrence | Medium |
| Connection from a new IP range | DACServer Gateway | Each occurrence (after 14 days of learning per person) | Medium |
Every preset automatically sends a justification request to the person concerned when a review case is created. Rules apply only to records created after they are turned on. Business hours, public holidays and the learning period for connection sources are set in the detection settings.
Review and justification
Record a conclusion for every detected activity
Reviewers select a person's records from the detection list and either request a justification or review them right away. Every change is kept in the history and sealed in a hash chain.
Review case
Detections with the same rule, person, destination and day are grouped into one case. The original audit content (SQL, prompts) is not copied; only a summary is kept.
Justification request
Asks the person concerned why they did it. The person sees it as a "justification request", not as "anomalous activity".
Justification
In the desktop agent, the person concerned sees the statement they ran and answers with a category (part of my work, testing, mistake, instructed or approved, I did not do this and others) and an explanation.
Justification approval
When enabled, the person's justification approver checks the justification in the agent. This check is supporting evidence; the reviewer makes the conclusion.
Review result
Select Violation, Normal work, False positive (rule issue), False positive (data issue) or Undetermined, and add a comment. For a violation, also record the action taken.
Exception
For activity confirmed as normal work, set a scope and an expiry date, and it is not detected again until then.
Monthly inspection report
On the 1st of each month, BeeHind creates a report that brings together the previous month's detections, reviews, justifications and exceptions. It serves as evidence of the monthly access-log inspection required by Article 8(2) of Korea's Standards for Ensuring the Safety of Personal Information. Reports are never edited; generating a report again creates a new one.
- Detection: number of review cases and people, counts by rule and by severity
- Review: counts by result, and the actions taken on cases reviewed as violations
- Justification: requested, submitted, submitted late, denied by the person, not submitted
- Exceptions: newly created, revoked, currently in effect
- Periods not inspected: audit records that could not be verified, and breaks in the chain
kim.dev@corp
- Activity
- Bulk sensitive data read
- Condition
- 1,000 or more rows within 60 minutes
- Destination
- orders-db (PostgreSQL)
- Time
- 22:14, outside business hours
- Rows returned
- 1,240 rows
This is an example for illustration. The name and figures are not from real records.
What it works with
As of October 2026
- Records read
- Audit records from DAC, AI Gateway and Server Gateway (OpenSearch, Elasticsearch, relational databases)
- Justification answers
- Desktop agent (macOS, Windows)
- SIEM forwarding
- Review case creation, justification submission, justification approval, review results, reopening (syslog, Splunk HEC)
- History
- Every change to rules, reviews, justifications and exceptions is sealed in a hash chain and verified once a day
- Notifications
- When the person answers "I did not do this", the reviewer is emailed right away
Known limitations
- Rules apply only to records created after they are turned on. Past records are not detected retroactively.
- For services that do not record plain-text reads, reads of sensitive fields without masking are not recorded, so they are not detected.
- Off-hours access and connections from a new IP range are checked only in the records of people who have an account.
- Records of connections made without the agent (issued connection addresses, virtual keys) do not trigger automatic justification requests. Reviewers can still send a request themselves.
- Justifications can be requested only from people who signed in to the desktop agent within the last 90 days.
See BeeHind in your own environment
Tell us which databases, servers and AI services you need to protect and how your network is laid out. We will recommend a setup and a rollout order. You can start with a single server.