Product
A verifier between your AI and your data.
Your AI keeps doing the investigation. Verdikor checks its queries before they run, records what came back as evidence, and checks every claim in the report against that evidence. It never investigates on its own.
01 · Query check
Wrong queries are stopped before they cost you anything.
Every query the AI writes goes through the grammar of that SIEM (XQL, KQL, SPL, ES|QL), not a regex. It is checked against a snapshot of the tenant's real schema, the cost is estimated against your quota, and policy decides: allow, warn, or ask a person.
Verdikor only blocks when it has measured. If a field is only known from vendor docs, you get a warning, not a block, so the verifier does not become the bottleneck.
1 DeviceNetworkEvents 2 | where Timestamp > ago(90d) 3 | where RemoteIp == "185.220.101.7"
Blocked UNKNOWN_FIELD line 3
Column names are case-sensitive. RemoteIp does not exist; the column is RemoteIP.
Warning line 2: lookback is longer than this table's retention.
1 index=* sourcetype=pan:traffic 2 dest_ip=185.220.101.7 earliest=-30d 3 | stats count by src_ip, dest_port
Needs approval COST_HIGH line 1
index=* searches every index for 30 days. That is above the share of quota policy allows one query to use.
Suggested: index=netfw, where this sourcetype was seen in the last 7 days.
1 FROM logs-network-* 2 | WHERE destination.ip == "185.220.101.7" 3 | STATS hits = COUNT(*) BY host.name
Allowed fields exist · cost within budget · risk low
Not every query is a problem. Most pass straight through, and the run is recorded as evidence.
1 dataset = xdr_data 2 | filter dst_ip = "185.220.101.7" 3 | fields agent_hostname, dst_ip
Blocked UNKNOWN_FIELD line 2
dst_ip is not a field of xdr_data in this tenant. Schema measured 6 h ago.
Suggested: action_remote_ip
Illustrative examples
02 · Evidence ledger
Everything the AI saw becomes evidence you can point to.
Each query result is stored as an evidence item, E1, E2, E3, with its query, time range and row count. Items are canonicalised (RFC 8785) and chained with SHA-256, and the chain is checkpointed and signed every day.
Rewrite one row after the fact and every hash after it stops matching. See it on the Trust page.
03 · Claim check
Every sentence has to point at something real.
Verdikor splits the report into claims, resolves each E# it cites, and looks up every IP, hash, host, user and path in the raw rows. Hover or focus a claim to see what it rests on.
-
backup.exe on BKP-01 read 37 files in /srv/finance.
-
The host connected to 185.220.101.7.
-
Nothing in the report mentions BKP-01 connecting to 10.20.0.15:445.
- Verified The cited evidence contains it.
- Contradicted The cited evidence says otherwise or does not contain it.
- Omission In the evidence, important, and missing from the report.
- AI-generated It comes from another AI's output, not from data.
- Inference A conclusion with no single row behind it. Marked as such.
- Pending Waiting for a person.
04 · Reviewed knowledge
The AI can suggest what to remember. People decide.
Lessons are plain YAML in your git. Each one has a risk tier, a backtest, an expiry date and an owner. Revoking one shows every case it touched.
- 1
Proposed
The AI proposes a lesson from a closed case. It cannot save it.
- 2
Backtested
Run against past cases with known human outcomes before anyone approves.
- 3
Approved
By one or two people depending on risk. Suppressions need the most.
- 4
Expires or revoked
Every lesson has an end date. Revoke one and see which cases it affected.
05 · Team knowledge
The same knowledge, for the people on your team.
Security operations are specific to every organisation. The lessons, sample queries, schema and past decisions your team approves for the AI become a knowledge base any analyst can ask, from their first week.
Answers cite where they come from: an approved lesson, how analysts closed similar cases, or the measured schema. Explain mode walks a junior analyst through a sample query step by step. When nothing approved covers a question, Verdikor says so instead of guessing.
Expected. The nightly backup job reads /srv/finance between 01:00 and 02:00 on BKP-* hosts. Outside that window, or on any other host, it is not covered.
- Lesson L-112 approved by SOC lead · expires in 54 days
- 12 past cases closed as benign by analysts · all agree
- Asset owner Infra · from CMDB
Every answer points to an approved lesson, a past analyst decision or your measured schema. If nothing approved covers the question, Verdikor says so.
Expected. The nightly backup job reads /srv/finance between 01:00 and 02:00 on BKP-* hosts. Outside that window, or on any other host, it is not covered.
- Lesson L-112 approved by SOC lead · expires in 54 days
- 12 past cases closed as benign by analysts · all agree
- Asset owner Infra · from CMDB
In your network logs the remote address is remote_ip. dst_ip does not exist in this tenant, and it is the most common mistake in new queries.
- Schema measured 6 hours ago
- Sample query Q-031 reviewed by the team
- Common mistake blocked 9 times this month
Alerts from the scanner subnet during the Tuesday scan window are closed as benign, with the scan ticket linked. Alerts outside the window are investigated as normal.
- Lesson L-064 approved by 2 people · expires in 30 days
- 41 past cases closed as benign · 95% agree
- Runbook vulnerability scanning
No approved knowledge covers this. In your policy, excluding a host from a detection needs two approvers. Propose it and your SOC lead will review it.
- 0 approved lessons for this host and detection
- Policy exclusions need 2 approvers
Illustrative example
Integrations and deployment
Plugs into what you run. Stays where your data is.
AI clients
Any AI assistant or agent that speaks MCP. Each tool call carries a person, a tenant and an agent identity.
SIEMs
Each SIEM connects through a plugin: Microsoft Sentinel, Splunk, Elastic, Google SecOps, Cortex XSIAM and others.
Where it runs
In your infrastructure. An offline bundle covers networks with no internet access and self-hosted models.
Exports
Evidence and audit events in a published format. Verification reports for auditors, with mappings to ISO/IEC 42001 and SOC 2 on the roadmap.
Early access
Run Verdikor on your own cases.
We're working with 3 to 5 design partners: MSSPs running several SIEMs, and banks or insurers using AI with any SIEM.