Dralvia Labs

Dralvia Labs is the research layer of the Dralvia blog. The daily digest shows what Dralvia sees across freshly analysed activity. Labs explains what we investigate: the threat model, the test we ran, what worked, what did not, and the product change that came out of it.

Labs notes publish on a steady cadence, alongside the daily digest at blog.dralvia.tech, which carries the live research feed between notes.

Where to find it

The Labs hub lives inside the existing blog at blog.dralvia.tech/labs. Every Labs note is a post on the same blog, tagged so you can tell research notes apart from the daily digest.

There are three ways in, and they answer different questions:

You want	Go to
The newest research notes	blog.dralvia.tech/labs. The hub lists the most recent notes first.
Notes on one subject	The category pages, for example Web phishing. The hub links all five.
Only research, no digests	The blog archive at blog.dralvia.tech, then pick Lab notes (research) in the report type filter.

That last one is the filter next to the archive search box. It is a direct link too, so you can bookmark or share it: https://blog.dralvia.tech/?summary_kind=labs.

If the hub says there are no research notes yet, that is literal. We publish on cadence rather than to a quota, so a quiet window means no note rather than filler.

What a Labs note is for

Use Labs to understand, in plain language and with evidence:

• how a class of risky action actually happens (a phishing click, a wallet signature, code execution from a repository, an AI agent tool call), and
• what Dralvia checks to catch it before it turns into a compromise, including what that check does not cover.

Each note is written so a non-expert can act on it. It is not a feed of exploit instructions.

Research categories

Every note belongs to one of five categories, matched to where risky actions happen:

Category	What it covers
Agent security	AI agents steered by prompt injection, tool calls, and connected services, and what stops a risky action before it runs.
Web phishing	Phishing pages, fake-update and paste lures, credential drops, and the hosting and redirect reuse that ties campaigns together.
Repositories and AI coding	Risky execution in repositories and AI-generated code, and what a scan catches before you run it.
Web3 safety	Wallet signatures, token approvals, and contract traps, plus the checks that show the real intent behind a request.
Usable security	Making the safe choice the easy choice, so you can act on a verdict without reading a manual.

Each category has its own page. It opens with the category summary, then states how many research notes it holds, then lists them newest first, each note showing its research level and the date it was published.

A category with no notes yet says so plainly, points you at this methodology page, and links to the other categories, so an empty category is never a dead end.

Research levels

Each note carries a research level so you know how strong the claim is before you read it:

• Observation: something we saw, with the evidence behind it.
• Experiment: a test we ran, with the setup written down.
• Benchmark: reproducible numbers from a fixed set of cases.
• Methodology: how we test, so you can check our work.

Controlled scenario tests

Labs can also use controlled phishing-like scenarios to test Dralvia's own detectors. These are local, non-deployed pages or browser observations designed to answer a narrow question, such as whether a scanner catches a fake login form, a risky download, a redirect into a brand lookalike, or a page that calls a known brand's browser APIs from the wrong host.

These scenarios are not attacker instructions and are not published as reusable payloads. They exist to compare expected evidence with what the product actually reports. If Dralvia misses a scenario, the miss becomes research evidence and can turn into a product improvement before any public claim is made.

AI-assisted lab research

Dralvia Labs may use a local model to propose controlled scenario ideas, but the model does not change scanner logic, publish public claims, or deploy anything. Its job is to suggest sandbox-only tests, explain why each test is worth running, and summarize the completed evidence for internal review.

Every model proposal is checked before it runs. Unsupported actions, credential collection, public phishing pages, exploit payloads, and instructions that would contact real victims are rejected. Approved scenarios run only in the controlled lab harness, and the result is judged by deterministic evidence: expected flags, actual flags, score, verdict, and missing evidence.

If the model is unavailable, the run must say so clearly. Fallback scenarios can keep the lab moving, but they are not counted as AI-generated research.

The quality bar

Every Labs note passes an 11-point quality gate before it publishes. The gate covers, among other checks:

1. The full ten-section structure, with no empty sections: summary, threat model, why it matters, test setup, what we observed, what worked, what did not work, product improvements, defender recommendations, and limitations.
2. A substantive limitations section. No note ships without stating what it does not cover.
3. A substantive product-improvements section, tied to exactly one tracked product task. Research that does not change the product is not a Labs note.
4. A documented threat model, and for experiment and benchmark notes, a documented test setup.
5. No total-detection or absolute-certainty claims.
6. No named-company accusations and no copy-paste exploit payloads.
7. No unearned compliance or certification claims.
8. A content-safety review that keeps the language neutral and evidence-backed.
9. A sign-off that the numbers are real, reproducible, and honestly framed. A note published automatically meets this by clearing a high evidence bar (every claim sourced, fresh, and grounded in the data, scored at or above a set floor). A note whose evidence falls below that floor is held for a person to review and approve instead.

We publish on cadence, not on a quota. A quiet window means no post rather than filler.

Digest and benchmark cadence

The daily digest and detection-quality benchmark are separate public research outputs. The digest publishes from observed threat activity when the blog channel is healthy. Benchmark measurement may take longer because it checks live samples before any number can be trusted.

A delayed benchmark does not hold the daily digest. If a benchmark run times out, the digest can still publish from the current threat window, and the benchmark result stays unpublished until a complete run is available.

Digest leads may use the same guarded local model workflow as Labs notes, but the model does not invent the digest. The threat facts, examples, evidence sections, and numbers come from the verified digest bundle. The model can only help choose the narrative angle for the lead, and the final wording is checked so sourced numbers stay unchanged. If that check fails, the digest uses deterministic wording.

How Labs notes are written

Labs notes start from our own data, never from a guess. The facts in a note (the figures, the dates, the checks we ran) are assembled by fixed software that reads the real results, so the substance is correct and reproducible by construction.

To make notes read naturally rather than formulaically, a small language model that runs on our own servers may rewrite the wording. It only rephrases. It never invents a number, a name, or a claim. Every figure from the source draft is checked to survive the rewrite unchanged, and if anything is dropped, altered, or added, the rewrite is discarded and the original wording is used instead. Nothing leaves our servers in this step. A note publishes on its own only after it clears the full quality gate and a high evidence bar, where every claim is sourced, fresh, and grounded in the data. When a draft is strong enough on the evidence, it goes live without waiting on a person. When the evidence is thinner, the same draft is held for a person to review and approve before it publishes. Either way, the full quality gate must pass first, and no note ships on weaker evidence than a published one.

In short: the facts are owned by software you can audit, the phrasing may be polished by a model that cannot change a fact, and a note goes live only when the evidence clears the bar or a person approves it.

The local model does not change Dralvia product code or scanner logic. For lab research, it may help draft controlled scenario ideas and summarize completed lab artifacts for internal review. The scanner behavior, expected evidence, pass or fail result, and any product change stay deterministic and human-reviewed.

Provenance and freshness

Every claim in a Labs note carries a provenance record: what it came from (a scan result, a benchmark run, or a dataset) and when that evidence was observed. Before a note can be published, the quality gate refuses any claim that is not tied to a source, and it flags any claim whose evidence has gone stale beyond a set window. The reviewer sees this provenance next to each draft, so a note can prove not only what it says but where each number came from and how current it is.

The gate also grounds the numbers: every figure printed in a note must be one of the sourced facts. A number that has no backing fact (an invented figure) or a sourced figure that goes missing from the text both block publication, so a note can never quietly add or drop a number.

Evidence scoring and proven topics

Beyond the pass or fail check, each claim's evidence is also scored. Freshness is graded on a sliding scale, so a result observed today scores higher than one near the edge of its window, and the source matters too: a direct scan result counts for more than a benchmark run, which counts for more than a dataset reference. A note's evidence score combines the two, so the strength of what backs a note is measurable, not just present or absent.

The research hub groups notes into topics (phishing and URL safety, Web3 and wallet safety, repository and AI coding security, AI agent security, usable security, and recurring threat digests). A topic is marked proven when it is backed by enough fact-backed notes whose evidence clears a quality bar, so the hub highlights the surfaces Dralvia can actually demonstrate rather than thin or unevidenced pages.

Limitations and ethics

• We describe attacker patterns and defender guidance. We do not publish copy-paste exploit payloads.
• We report on behavior. We do not accuse a named company whose brand an attacker copied.
• We do not claim total detection. Every note states what it does not cover.
• Numbers come from fixed, reproducible sets of cases and the same checks we run in the live service.
• When a note draws on aggregated customer signals (for example, where confirmed false positives concentrate by severity), it is anonymized before it is written. Severity groups smaller than a fixed threshold are dropped, the whole aggregate is withheld unless it clears an evidence floor, and only coarse category labels and counts are ever used. No domain, workspace, or reporter appears in a note, and a code guard blocks any identifying label from leaving the aggregation.

How to follow it

Read the daily digest at blog.dralvia.tech to catch the first Labs note when it lands, and visit blog.dralvia.tech/labs for the Labs hub.

To skip the digests entirely, use the archive filter link https://blog.dralvia.tech/?summary_kind=labs, which shows research notes only.