Work

Erik Horváth, DevOps Engineer, Nitra, Slovakia, remote, contract or B2B, full-time from 2027

My background, master’s thesis, job and projects, how I work with AI and what I do not claim; figures from measurements and repositories carry numbered sources, listed at the end of the page.

Experience and education

Most recent first.

Employment

02/2026 – present
DevOps Engineer
Marketeam, s. r. o., Nitra
Details below
06/2025 – 01/2026
AI Engineer Intern
HOFITECH s. r. o.
Details under NDA.
02/2024 – 09/2024
Frontend Developer (Angular)
freelance
02/2024 – 06/2024
Programming Instructor for Children
EDU PLAY s. r. o., Nitra

Education

09/2025 – present
Applied Informatics, Master’s programme (in progress)
Constantine the Philosopher University in Nitra (UKF)
Thesis: agentless introspection of a running KVM virtual machine.
2023 – 2025
BSc in Applied Informatics
UKF Nitra
Bachelor’s thesis: GraphVisualization, a tool that shows graph algorithms step by step (Python, Tkinter).
2022 – 2023
Software Engineering
Tomas Bata University in Zlín, Czech Republic
Not completed.

Stack

Infrastructure: Docker/Compose, GitHub Actions, GHCR, Nginx, Linux
Languages: Python, PHP, C, SQL, Bash
Backend: Django/DRF, Symfony, PostgreSQL, Redis
Systems: eBPF, KVM

Only what code or work shows. Tools I have used only in projects where an AI agent wrote the code (e.g. FastAPI, cosign) are left out.

Master’s thesis

My main project, AI-assisted. Solo; the Master’s programme is in progress. Private repository hyptcn3, 09/2026.

I read the memory of a running virtual machine from the outside.

A tool that runs inside a virtual machine can be switched off or fooled by an attacker in that same machine. So I look from the outside: from the memory of a running KVM guest I rebuild its processes, kernel modules and network sockets. No collection agent runs inside it during capture and the machine is not paused.

I compared the result with what ps, lsmod and ss reported when run inside the guest.¹ The eBPF collector is an existing one that I adapted and fixed.²

Prerequisite: a kernel profile (kallsyms + BTF) from the same boot of the guest, taken from it beforehand.³

81 of 81

processes stable during the snapshot — the reconstruction from memory found every one of them: none missing, none extra.¹ Plus 51/51 kernel modules and 10/10 listening sockets (+2 explained extras). One validation session, compared with ps, lsmod and ss in the guest.

Code: 5 excerpts

Fig. 1How v3 fits together: block diagram

Fig. 1How v3 fits together, from guest memory to the model. The box style separates adopted code from code written for v3. All of v3 was built with AI assistance; the box style does not say who wrote the code, only whether it was adopted.

Key to figure 1

code written for v3 (AI-assisted)
adopted code that I fixed
implemented, untrained
validation path: checked against the guest’s own view
data and files

The diagram as text

Guest: Debian 12 on KVM, 2 GiB RAM. No collection agent runs in it while a snapshot is taken, and the VM keeps running. Its memory holds the page tables, processes, kernel modules and sockets that are read.
The eBPF program vmic_kvm.bpf.c in the host kernel reads guest memory through the KVM memslots. The program is adopted; mine are the four fixes without which it would not load on kernel 7.1.Code: eBPF: bpf_loop() instead of a loop the verifier rejected
The vmicollect collector in C is adopted (~83% of its C lines, author unknown). For v3 it gained the per-bin feature module and a streaming hash with a SHA-NI path; an AI agent wrote the hashing change under my direction, and its intrinsic ordering follows the Intel/noloader reference.²Code: SHA-NI with CPUID runtime dispatch
The output is full and delta .vmicd snapshots plus a sidecar with the per-bin features.
The custom guestparse reconstruction (Python, AI-assisted) uses the kernel profile taken from the guest for that boot, finds the kernel-image shift (KASLR), walks the page tables (with a known PAT mask bug for huge pages) and rebuilds processes, modules and sockets. Cross-view checks compare independent kernel structures (rootkit invariants).^3,4,5Code: Finding the kernel’s KASLR shift in a snapshot · x86-64 4-level page-table walk · Cross-view process check (rootkit invariant)
Validation: the result is compared with ps, lsmod and ss run inside the guest over SSH. One validation session, still with the binary from before the hashing change: 81/81 processes stable during the snapshot, 51/51 kernel modules, 10/10 listening sockets (+2 explained extras).¹
The per-bin features feed a TCN model. It is implemented and tested but deliberately untrained, so I claim no detection accuracy.⁶

Table 1. v3 measurements and their conditionsSetup: host i7-12650H, Fedora 43, kernel 7.1 · guest Debian 12, kernel 6.1, 2 vCPU, 2 GiB RAM · validation session 18 Sep 2026.
Parameter	Conditions	Value	n	Source
Memory capture
Full RAM snapshot, 2.02 GiB	checksum off; the VM is not paused	~0.39 s (median 393.9 ms; 5,240 MiB/s)	3	⁷
Snapshot cycle with SHA-256	checksum on; before and after the change (streaming hash in `feed()` + a SHA-NI path); measured on uncommitted changes	13.4 s → 2.5 s (5.4×)	3 + 3	⁸
Cost of the faster cycle	same measurement, checksum on	memory read window 388 → 2,288 ms; recorded in the measurement log as a trade-off	3 + 3	⁸
eBPF program on kernel 7.1	the adopted program would not load; 4 separate causes	4 fixes: 1 via an opaque struct definition (kfunc BTF FWD/STRUCT mismatch), 3 via `bpf_loop()` (8193 jumps, the 1M-instruction limit twice)	–	⁹code
Reconstruction and validation
Validation against the guest	against `ps`, `lsmod` and `ss -tulpn` in the guest (over SSH); one validation session; binary from before the hashing change	81/81 processes stable during the snapshot (0 missing, 0 false positives) · 51/51 kernel modules · 10/10 listening sockets; +2 extra: an unbound UDP socket and a DNS query that `ss -tulpn` does not list	1	¹

More measurements (8): SHA-NI, the slowdown cause, periodic capture, KASLR, features and tests

Table 1, continued: more measurements
Parameter	Conditions	Value	n	Source
Memory capture
SHA-NI vs scalar SHA-256	hashing alone; the path is picked by CPUID at run time	357 → 2,151 MiB/s (6.0×); bit-exact vs `sha256sum` on 223 files; UBSan clean	3	¹⁰code
Cause of a 56× slowdown	SHA-256 was computed over the whole 4 GiB sparse file, holes included; compared with a run without the hash; not a clean A/B (different times, different amounts written)	42.2 s → 0.75 s	1 + 1	¹¹
Periodic capture
Periodic delta capture	5 s period, 12 cycles (1 full + 11 delta snapshots)	0 missed slots	12	¹²
Pages changed between snapshots	idle guest, delta, 5 s period	~0.046% (median 245 of 528,417 pages)	7	¹³
Snapshot → feature vector latency	2 s period, delta, features on	median 604 ms, p95 613 ms	12	¹⁴
Reconstruction and validation
Kernel-image VA→PA offset (phys_base, includes KASLR)	found in the validation snapshot	−2 MiB	1	¹⁵code
Features and tests
C per-bin feature module vs Python	independent Python reference over the same snapshots	exact match on 6 snapshots × 131 bins	6	¹⁶
Tests (pytest)	clean clone; the skipped ones need local snapshots	213: 185 pass, 28 skip	–	¹⁷

Each figure holds only under the conditions in its own row.

Three iterations

v1 hypTcn (02–03/2026) → v2 hypTcn002 (03–08/2026) → v3 hyptcn3 (09/2026)

v1hypTcn
02–03/2026 · now a private repository
The first code iteration: a C wrapper over libvmi → CGO → Go orchestrator → binary protocol over a Unix socket → a TCN in Python. Synthetic data only; the live-VM Go binary was never tested against a real VM.
AI-assisted. 5 of 37 commits carry an AI co-author trailer. The missing trailer on the C and Go core does not show that AI did not write it.¹⁸
Code: CGO bridge from Go to C/libvmi (v1)
v2hypTcn002
03–08/2026 · second GitHub account (avUnitfan)
C/libvmi → CGO → Go → binary frames → a PyTorch TCN. It added an eBPF agent inside the guest, so v2 as a whole is not agentless; a KVM dirty ring is implemented but was blocked in practice (the probe ran in 200 ms polling mode). I retracted its metrics.
Code written by an AI agent. 81% of 408 commits on develop carry an AI co-author trailer — AI agents wrote the code under my direction. The count includes 37 commits imported from v1.^19,20
Code: Custom V2P walk over libvmi (v2) · KVM dirty-ring consumer (v2)
v3hyptcn3
09/2026 · private repository
An adopted and fixed eBPF collector over KVM memslots and a custom reconstruction in Python, validated against what the guest itself reports. No Go, CGO or libvmi.
v3 was built with AI assistance (~24 h of history, large commits, review documents written by AI; an AI agent wrote the SHA-NI hashing change); my part: design, directing and checking the measurements, debugging, checking the validation, retracting wrong results.²¹
Code: x86-64 4-level page-table walk · Cross-view process check (rootkit invariant)

I found a flaw in my own results and withdrew them

Invalid, retracted: F1 ~~99.70~~ AUC ~~99.98~~

The second version (v2) had these detection metrics. On review I found that the way I measured distorted the result, so these numbers are invalid. There were two flaws in the method: labels belonged to whole sessions rather than to individual windows (a session-level confound), and windows from the same session ended up in both the training and the test set (leakage). I therefore do not present them as a result anywhere.²²

What I built afterwards

scripts/check_claims.sh — a claims linter: it flags retracted numbers from a blacklist and checks {{res:…}} provenance tags against the result JSON files. No CI job or hook runs it, and it still reports findings at the current commit (see Limitations).²³
A test: a signal that carries only the session identity must not beat chance. If the split ever let the same session into both training and test again, the test would fail.²⁴

Step through the page-table walk (Fig. 2) interactive, with the code

Fig. 2

How an address in the machine’s memory becomes one specific byte of RAM

A piece of the thesis: one step the tool repeats over and over during reconstruction — finding where in physical memory a given address lives. Step through it, with the code.

Without JavaScript all steps of the first example are shown at once.

Addressstep 1 of 7
The guest kernel remembers where each module lives as a virtual address. From the outside we only see physical memory, so the address has to be translated the way the CPU does it: through four page tables.
va = 0xffffffffc0a3f040 · the module area (from 0xffffffffc0000000) is not linearly mapped, hence the walk · root: table = self._pgt_root() = 0x280a000
PML4Linux: PGDstep 2 of 7
Bits 47 to 39 pick one of the 512 rows of the top-level table. The row holds no data, only the physical address of the next table.
idx = (va >> 39) & 0x1FF = 511 · entry 0x000000000280d067 · P=1 RW=1 NX=0 → next table 0x280d000
PDPTLinux: PUDstep 3 of 7
The next 9 bits pick a row in the second table. Modules sit at the very top of the address space, so the index is 511 here too.
idx = (va >> 30) & 0x1FF = 511 · entry 0x000000000280f067 · P=1 RW=1 PSE=0 NX=0 → 0x280f000
PDLinux: PMDstep 4 of 7
Third table. If the row had the PSE bit set, the walk would end here in a 2 MiB page; it is not set.
idx = (va >> 21) & 0x1FF = 5 · entry 0x0000000004a1e067 · P=1 RW=1 PSE=0 NX=0 → 0x4a1e000
PTLinux: PTEstep 5 of 7
The last table points at one specific 4 KiB page of physical memory.
idx = (va >> 12) & 0x1FF = 63 · entry 0x8000000007b3c163 · P=1 RW=1 PAT=0 NX=1 · the mask 0x000FFFFFFFFFF000 also drops the NX bit → 0x7b3c000
Pagestep 6 of 7
The remaining 12 bits are the offset inside the page. Now we know exactly which byte of memory to read.
pa = table + (va & 0xFFF) = 0x7b3c000 + 0x040 = 0x7b3c040
Resultstep 7 of 7
At this physical address lies the module’s structure, name included. This is how the reconstruction walks the whole module list; in one validation session all 51 matched lsmod in the guest.¹
modules(): mpa = self.walk_pa(nxt - o_list) → name = self.cstr(mpa + o_name, 56) · view.py:415, 419
Addressstep 1 of 6
The address of a symbol in the kernel image, where the kernel’s own code and data live. The kernel maps it with 2 MiB pages, so the walk ends one level early and the offset inside the page is 21 bits.
va = 0xffffffff82613940 (linux_banner) · kernel image from __START_KERNEL_map = 0xffffffff80000000 · root: table = 0x280a000
PML4Linux: PGDstep 2 of 6
Bits 47 to 39 pick a row of the top-level table, the same one as for modules.
idx = (va >> 39) & 0x1FF = 511 · entry 0x000000000280d067 · P=1 RW=1 NX=0 → next table 0x280d000
PDPTLinux: PUDstep 3 of 6
Second table, index 510: the kernel image sits just below the module area.
idx = (va >> 30) & 0x1FF = 510 · entry 0x000000000280e063 · P=1 RW=1 PSE=0 NX=0 → 0x280e000
PDLinux: PMDstep 4 of 6
This row has the PSE bit set: it points not to another table but straight to a 2 MiB page. The walk ends here and the PT table is not used.⁴
idx = (va >> 21) & 0x1FF = 19 · entry 0x80000000024001e1 · P=1 RW=0 PSE=1 NX=1 → 2 MiB page at 0x2400000 · known bug: for a huge page the mask 0x000FFFFFFFFFF000 keeps bit 12 (PAT); PAT = 0 here, so the result is right
Pagestep 5 of 6
The offset inside a 2 MiB page has 21 bits (20 to 0), so bits 20 to 12 are not an index. The physical address is done.
size = 1 << 21 · pa = phys + (va & (size - 1)) = 0x2400000 + 0x013940 = 0x2413940
Resultstep 6 of 6
The linear formula for the kernel image gives the same address: PA = VA − __START_KERNEL_map + the kernel-image offset (phys_base in Linux, which includes KASLR). In the validation snapshot the offset came out as −2 MiB.¹⁵
ktext_pa(va) = va − 0xffffffff80000000 + (−0x200000) = 0x2413940 = result of the walk 0x2413940
Addressstep 1 of 5
The same symbol, but its address comes from a kernel profile taken in a different boot. KASLR moves the whole kernel on every boot; here (an illustrative 256 MiB) the old address points outside it. With a smaller difference it could land inside the kernel image, and the walk would succeed — at a different address.
va = 0xffffffff92613940 = 0xffffffff82613940 + 0x10000000 · root: table = 0x280a000
PML4Linux: PGDstep 2 of 5
Top-level table: row 511 is present, as for every kernel address.
idx = (va >> 39) & 0x1FF = 511 · entry 0x000000000280d067 · P=1 RW=1 NX=0 → next table 0x280d000
PDPTLinux: PUDstep 3 of 5
Second table, index 510: still the kernel-image area.
idx = (va >> 30) & 0x1FF = 510 · entry 0x000000000280e063 · P=1 RW=1 PSE=0 NX=0 → 0x280e000
PDLinux: PMDstep 4 of 5
The PD table is in the snapshot, but row 147 is empty (P bit = 0): in this boot the kernel has nothing at this address. The walk stops here.
idx = (va >> 21) & 0x1FF = 147 · entry 0x0000000000000000 · P=0 RW=0 PSE=0 NX=0 → reason_code = "chyba_polozka"
Resultstep 5 of 5
Instead of a bare None the code returns the level, the index and the reason, so “the kernel does not map this address” is never confused with “we did not collect this page”. The stale-profile diagnosis builds on that. Such a profile cannot be used: the reconstruction needs a profile from the same boot of the guest.⁴
{'pa': None, 'level': 'PMD', 'index': 147, 'reason': 'polozka PMD[147] nie je pritomna', 'reason_code': 'chyba_polozka'}

guestparse/view.pyhyptcn3 · private repo · excerpt · lines 204–252 · ref 97b0c43 · AI-assisted

204 def walk_pa_detail(self, va):

222 out = {"pa": None, "level": None, "index": None,

223 "reason": None, "reason_code": None}

224 table = self._pgt_root()

225 if table is None:

226 out["reason_code"] = "bez_korena"

227 out["reason"] = ("neznamy posun jadra alebo profil nema "

228 "init_top_pgt")

229 return out

230 # bity 47:39 / 38:30 / 29:21 / 20:12

231 for level, shift in enumerate((39, 30, 21, 12)):

232 idx = (va >> shift) & 0x1FF

233 name = self.PGT_LEVELS[level]

234 ent = self.u64(table + idx * 8) if self._page_present(table) else None

235 if ent is None:

236 out.update(level=name, index=idx, reason_code="chyba_tabulka",

237 reason="tabulka %s na 0x%x nie je v snimke"

238 % (name, table))

239 return out

240 if not (ent & self.PTE_PRESENT):

241 out.update(level=name, index=idx, reason_code="chyba_polozka",

242 reason="polozka %s[%d] nie je pritomna"

243 % (name, idx))

244 return out

245 phys = ent & 0x000FFFFFFFFFF000

246 if level in (1, 2) and (ent & self.PTE_PSE):

247 size = 1 << shift

248 out["pa"] = phys + (va & (size - 1))

249 return out

250 table = phys

251 out["pa"] = table + (va & 0xFFF)

252 return out

More excerpts in the code browser

NoteVirtual-to-physical translation through the four x86-64 page-table levels, as done by the custom walk_pa_detail function (no libvmi).⁴ Addresses and entry values are illustrative, because the memory snapshot is not part of the repository. The bit fields, the flow and the code are real. Code comments and messages are in Slovak: chyba_polozka = entry not present, chyba_tabulka = table not in the snapshot, bez_korena = page-table root unknown.

Job and projects

Employment and projects besides the thesis. For each project I say how it was built and link to code excerpts. The thesis is described above.

Employment · since 02/2026

Marketeam: Symfony 3.4 → 6.4, staging and Pretix memory

I migrated the company’s Symfony application across three major versions, from 3.4 to 6.4, including the changes for new APIs, dependencies and configuration.²⁵
I built a staging environment and am building the deployment infrastructure (Docker, CI/CD).²⁵
Pretix, a ticketing system, ran in a container that used 6.7 GB of memory. I limited the Celery worker concurrency to two and memory dropped to ~0.9 GB (measured at work).²⁶ In code, it is a one-line change to the supervisord configuration.²⁷

Public change:PR #1 in Marketeam-SK/pretix commit 3e0dc2f07

The PR title says “Increase concurrency”; the change actually adds a fixed --concurrency 2 limit where none was set before.

Team project · 3 people · 10/2025 – 01/2026 · SIprojekt (team repo)

Internship management system: backend and custom OAuth 2.0 server

The Django/DRF backend is mine: 98.75% of the Python lines by git blame, 96.4% with move/copy detection. My teammates built the frontend and the SQL schema.²⁸

A custom OAuth 2.0 authorization server with no OAuth server library (SimpleJWT mints the tokens, PyJWT checks the assertions): 4 grant types, PKCE S256 and private_key_jwt client authentication per RFC 7523.²⁹

AI in the git history: 0 commits with an AI co-author

Among the known gaps: PKCE still accepts the plain method, and it is the default; a private_key_jwt assertion need not carry exp, and jti is not checked against replay.^30,29

SIprojekt: Code: 5 excerpts

Details and stack: SIprojekt

An end-to-end test generates an RSA key pair, signs a JWT assertion and calls a protected API with the token it receives.³¹
An 11-step GitHub Actions release pipeline builds the backend and frontend images to GHCR; it ran successfully on 13 January 2026.³²
Redis caching with signal-based invalidation, and a refactor from fat views to a service layer.

Why it matters: I implemented OAuth 2.0 at the protocol level rather than configuring a library — and I know which gaps it still has.

Stack: Python · Django · DRF · SimpleJWT · PyJWT · PostgreSQL · Redis · Docker Compose · Nginx · GitHub Actions · GHCR

Excerpts in the code browser

Client authentication via private_key_jwt (RFC 7523) token_flow.py:20–71
PKCE: code_verifier check (S256 and plain) pkce.py:1–20
Authorization-code exchange authorization.py:73–107
End-to-end test: a client with a signed JWT assertion test_external_integration.py:232–265
Cache keys and pattern invalidation cache.py:23–63

Solo prototype · 01/2026 · ~10 days, 14 PRs · scanforeshop (private repo)

scanforeshop: scripts injected into e-shops at runtime

In Magecart-style attacks, a foreign script gets into an e-shop page and skims payment details. scanforeshop opens the page in a browser (Playwright) and, before the page’s own JavaScript runs, wraps two of the DOM functions that insert scripts (appendChild, insertBefore). That lets it separate external scripts the server sent in the HTML from those added at runtime.³³

How it was built: AI-assisted (Codex); the evidence in the code is identifiers named after Codex.³⁴

Status: prototype. It wraps only appendChild and insertBefore, so other insertion methods are missed; downstream only scripts with a src are kept, so an inline injection never counts as dynamic. Scoring still ignores the dynamic flag.^33,35

scanforeshop: Code: 4 excerpts

Details and stack: scanforeshop

Every script gets a SHA‑256 identity. A deterministic diff of two scans feeds alerts, a timeline and an HTML or PDF report.³⁶
Risk is weighted by page type (landing, shop, checkout), with tests that calibrate false positives.

Why it matters: a script injected in the browser is not in the server’s HTML, so it has to be caught at the moment it is inserted.

Stack: Python · Django · DRF · Playwright · SQLite · Next.js (frontend prototype) · TypeScript · Docker Compose

Excerpts in the code browser

Init script: hooking script insertion into the DOM __init__.py:9–45
Scan: server HTML vs. runtime-injected scripts __init__.py:88–145
SHA-256 script identity and the “dynamic” flag __init__.py:45–78
Deterministic diff of two scans engine.py:6–30

AI-directed work: supply chain PoC and dolt code written by AI agents under my direction · 2 projects

Solo proof of concept · 06/2026 · sovereign-ai-poc (private repo)

Signed supply chain and egress monitor (PoC)

A proof of concept of an EU-sovereign MLOps setup on docker-compose: Forgejo, MinIO, PostgreSQL, MLflow, a Zot registry and DVC data versioning.

How it was built: code written by an AI agent — Claude, acceptance scripts included, under my direction; the specification and architecture are mine.

Status: PoC. Phase 6 is unfinished, the model is a toy (iris), and phases 2, 4 and 5 cannot run from a clean clone because the dataset is not in the repo.³⁷

sovereign-ai-poc: Code: 4 excerpts

Details and stack: sovereign-ai-poc

An image has to pass a Trivy gate (no CRITICAL vulnerabilities); cosign then signs it by digest with an offline key and an SPDX SBOM attestation is attached.³⁸
Negative tests check that an unsigned or vulnerable image is rejected.³⁹
A bpftrace monitor scoped to one container’s cgroup tells ordinary outbound connections from a deliberate exfiltration test.⁴⁰

Why it matters: the negative tests are written to fail unless the gate rejects a bad image — not only to check that a good one passes.

Stack: Docker Compose · Forgejo · MinIO · PostgreSQL · MLflow · Zot · DVC · cosign · Trivy · SPDX SBOM · bpftrace · Bash

Excerpts in the code browser

Supply chain: Trivy gate → cosign signature → SBOM supply_chain.sh:54–92
Supply-chain negative tests verify_phase3.sh:53–80
bpftrace egress monitor scoped to one cgroup egress_monitor.bt:1–28
Legitimate egress vs. deliberate exfiltration verify_phase5.sh:123–172

Solo MVP · 07/2026 · dolt-platform (private repo)

dolt: assessing DevOps skills from work traces

An MVP that assesses junior DevOps engineers by how they actually work. A stdlib-only Go CLI keeps a SHA‑256 hash-chained JSONL work log with an ed25519 device key; a FastAPI server re-verifies the chain and a deterministic scorer rates the log.

How it was built: code written by an AI agent — mine are the product idea, the architecture decision log D‑001 to D‑015 and a 27-check acceptance harness that I specified and froze; the agent placed it in the repo.

Limits: the freeze was by instruction only, not enforced technically — in one commit the agent changed the file mode of eval/eval.sh. The server does not yet verify the ed25519 signature.^41,42

dolt-platform: Code: 3 excerpts

Details and stack: dolt-platform

I reproduced the result: 27 of 27 checks pass.⁴³

Why it matters: when an agent writes the code, the acceptance harness is the contract — the agent is meant to change the code, not the yardstick. Here that rule was enforced by instruction only.

Stack: Go (stdlib) · Python · FastAPI · Bash · ed25519 · SHA-256 hash chain · Docker Compose (test scenario)

Excerpts in the code browser

Acceptance harness: hash chain and tamper detection eval.sh:68–100
Ratchet: the pass count may never drop eval.sh:187–212
Hash-chain verification in the Go CLI trace.go:88–122

How I work with AI

What I do, what the agent does, and where the history shows it.

I start with the design and a written spec with acceptance criteria. AI agents then write much of the code. I read it, test it and, where I can, verify it with measurements on the real system. When a result does not hold up, I retract it — as I did with my own figures from the second version of my thesis.

For every repository I say how it was built, with its commit and AI co-author trailer counts: Table 1 on the Code page.

Limitations

The main limits of my claims in one place, each with its reason. Other known bugs are described next to the code excerpts.

Table 2. Limits of the claims
Area	Limit	Why
Master’s thesis
Detection accuracy	None claimed. The TCN model is untrained.	The model is implemented and tested (causality, receptive field) but deliberately untrained, so no accuracy figure exists. The retracted v2 metrics are invalid.^6,22
Validation scope	One validation session on one Debian 12 guest (18 Sep 2026).	The validation results in Table 1 hold for that session. I do not generalise them to other kernels or to a guest under load.¹
Validation and the faster snapshot cycle	The 81/81 result (processes stable during the snapshot) holds for the binary from before the hashing change.	After the change, with the checksum on, the memory read window grew from 388 to 2,288 ms. How the longer window affects reconstruction accuracy has not been measured; the measurement log lists it as an open item.^8,1
Knowledge of the guest	The reconstruction needs a kernel profile (kallsyms + BTF) taken from the guest for each boot.	“Agentless” means that no part of the tool and no collection or security agent runs in the guest during capture. The guest itself keeps running normally. In the validation session the ground truth (`ps`, `lsmod`, `ss`) was collected in the guest over SSH.³
Authorship of the `vmicollect` collector	~83% of its C lines are imported (author unknown); ≈1.5k lines of C come from my account (AI-assisted).	I adapted and fixed an existing eBPF collector; I did not write it. My account added the per-bin module and the eBPF load fixes. An AI agent wrote the streaming hash with the SHA-NI path under my direction; its intrinsic ordering follows the Intel/noloader reference.^2,44
Page-table walk in v3	Known bug: for huge pages the mask `0x000FFFFFFFFFF000` keeps bit 12 (PAT) in the address.	When PAT is set, the physical address comes out wrong. v2 masks huge pages correctly, so v3 is not strictly better here.⁴Code: x86-64 4-level page-table walk
The `check_claims.sh` claims linter	At the current commit it reports 38 findings, mostly in `docs/notebookLM.md`.	No CI job or hook runs it, so it blocks nothing. I do not claim the repository passes it.²³

Other projects and work (7)

Table 2, continued: other projects and work
Area	Limit	Why
Other projects and work
SIprojekt: Nginx and TLS	No claim of TLS in production.	Security headers, rate limits and a TLS 1.2/1.3 profile are configured, but the committed production config never served TLS (it fails `nginx -t`).⁴⁵
SIprojekt: OAuth 2.0 server	Among the known gaps: PKCE also accepts the plain method (and defaults to it), code redemption is not atomic, and a private_key_jwt assertion need not carry `exp`; `jti` is not checked.	It is a custom implementation with no OAuth server library, pinned to commit 2e96d44. The gaps are visible in the code and described, with line numbers, next to the excerpts.^30,29Code: Client authentication via private_key_jwt (RFC 7523)
Kubernetes	Basics (minikube).	I have only brought up a cluster in minikube, so I do not list Kubernetes as a skill.
scanforeshop	A prototype with known gaps.	Scoring ignores the dynamic-insertion flag; only `appendChild` and `insertBefore` are wrapped (not `append`, `prepend`, `innerHTML` or `document.write`), and only a directly inserted script is recorded, not one nested in another element; downstream only scripts with a `src` are kept; vendors are matched by substring; the app itself has no authentication; the Next.js frontend is only a prototype (`next build` fails).^33,35
dolt-platform	The harness freeze was by instruction only. The server does not verify the ed25519 signature.	In one commit the agent changed the file mode of `eval/eval.sh`. The ratchet fails only when the pass count drops; it does not catch trading one check for another. The server re-verifies the hash chain of the log but only stores the device key and the signature.^41,43,42
sovereign-ai-poc	The PoC’s “green” status is not backed by a fresh end-to-end run.	It rests on commit messages and `NEXT.md`. Phases 2, 4 and 5 do not run from a clean clone because the dataset is not in the repository.³⁷
Pretix memory (Marketeam)	I measured the memory saving at work; there is no public artefact for it.	Only the one-line change in the merged PR is public. Its title says “Increase concurrency”, but the change adds a fixed `--concurrency 2` where no limit was set before.^26,27

How I verify reviews

What verification means for the reviews on this site, and what it does not.

I only publish reviews from people I have actually worked with. I check each one before publishing, and I do not change a single character without the author’s consent.

What I check

Our work together. I check the stated relationship and period against a contract, an invoice, employment records or a shared project. The records themselves stay private.
The wording. I check that the author sent the review through a personal link I sent them by e-mail or message to a contact from my records, or confirmed its exact wording through such a link. Each link is for one person and one review, and it expires. After any correction the author must confirm the wording again; until then the review is not shown.
The domain. I show the e-mail domain, such as @firma.sk, only with the author’s consent, only if I sent the personal link to an address in that domain, and only if the domain belongs to the company named.
A qualified signature, if the author added one. I check that the signature is qualified under the eIDAS Regulation, covers the exact wording of the review and that the certificate is in the author’s name. Such a review shows the month in which I checked the signature. I do not publish the signed file: the certificate contains the author’s personal data.

What this does not prove

That every statement is accurate. A review is the author’s opinion.
The company’s position. The domain shows where I sent the link, not that the company endorses the review.
The author’s legal identity. A personal link only shows that the review was sent or confirmed by someone who had the link I sent the author, not who that person is; only a qualified signature shows identity.
Independence from me. I run these checks and create the links myself. The independent check is talking to the author: for reviews marked “reference on request” I will put you in touch, and you can also reach the author through the company, if one is named with the review.

Rules

I choose and approve the reviews, so these may not be all the reviews I have received. I do not publish a review the author has not confirmed, one whose collaboration I cannot verify, one that contains a client’s confidential information or other people’s personal data, or one that is abusive. I do not publish reviews from relatives.
I give no payment or favour in return for reviews. Each review states the author’s relationship to me, the project and when we worked together.
Authors can withdraw consent at any time: through the link I send them when the review is published (valid for a year) or by e-mail to erik@erikhorvath.com. I remove the review from the site the same day and delete the submission.

Contact with the author

If you would like to ask an author about our work, write to me at erik@erikhorvath.com. For reviews marked “reference on request”, I will put you in touch once the author agrees.

Sources

Every numbered mark on the site leads here. Paths are relative to the repository root at the commit the snapshot is pinned to.

Show all 48 sources

Master’s thesis

1
Reconstruction compared with in-guest ps, lsmod and ss (one validation session, 18 Sep 2026)
artefacthyptcn3 @ 97b0c43 · private
data/results/2026-09-18_zmrazeny_host/summary.json → values.validacia_voci_pozemnej_prave
processes: 83 in ps, 81 of them stable during the snapshot, 81 found, 0 missing, 0 extra · modules 51/51 · listening sockets 10/10, +2 extra (an unbound UDP socket and a DNS query that ss -tulpn does not list)
2
vmicollect is an adopted collector: ~83% of its C lines are imported (author unknown); ≈1.5k lines of C are mine
git blamehyptcn3 @ 97b0c43 · private
README.mdcommit 6b9053d
Imported in commit 6b9053d (“adopted state, unchanged”); README.md states the origin. Lines from my account by git blame: the per-bin module, SHA-NI and streaming hash, the eBPF load fixes; an AI agent wrote the hashing change (data/results/2026-09-18_zmrazeny_host/env.json).
3
The guest kernel profile (kallsyms + BTF) is taken from the guest beforehand and is valid for one boot
codehyptcn3 @ 97b0c43 · private
scripts/get_profile.sh
The profile records the guest’s boot_id (profiles/debian12-6.1.0-42-cloud-amd64/README.md) and is fetched over SSH or qemu-guest-agent. Capture itself needs no access to the guest.
4
Custom x86-64 page-table walk (walk_pa_detail) with a failure reason per level
codehyptcn3 @ 97b0c43 · private
guestparse/view.py:204-252
Known bug: for a huge page the mask 0x000FFFFFFFFFF000 keeps bit 12 (PAT) in the address, lines 245–248.
Excerpt in the code browser
5
Cross-view rootkit checks: sys_call_table bounds, task list vs children tree, modules vs module_kset
codehyptcn3 @ 97b0c43 · private
guestparse/checks.py
Excerpt in the code browser
6
TCN model: causality and receptive-field tests; the model is deliberately untrained
testhyptcn3 @ 97b0c43 · private
tcn/tests/test_tcn.py
No detection accuracy figure exists.
7
Full 2.02 GiB snapshot without checksum: median read 393.9 ms, 5,240 MiB/s, VM not paused
artefacthyptcn3 @ 97b0c43 · private
data/results/2026-09-18_zmrazeny_host/summary.json → values.once_raw_hash_none
vmicollect once, writer=raw, output.hash=none, 3 repetitions; paused: false.
8
Snapshot cycle with SHA-256 before and after the change (13.4 s → 2.5 s) and its cost (read window 388 → 2,288 ms)
artefacthyptcn3 @ 97b0c43 · private
data/results/optim_hash_20260918.json → values.pred.once_sha256, values.po.once_sha256
Two changes together: a streaming hash in feed() instead of hashing the sparse file in finish(), plus a SHA-NI path; an AI agent wrote the change. Measured on uncommitted changes; the binary hashes are recorded in the file. docs/MERANIA.md:576-605 describes the trade-off.
9
Four reasons the eBPF program would not load on kernel 7.1, and their fixes
codehyptcn3 @ 97b0c43 · private
vmicollect/bpf/vmic_kvm.bpf.ccommit 178ce4f
kfunc BTF FWD/STRUCT mismatch (opaque struct definition); “sequence of 8193 jumps is too complex” and two 1M-instruction limits (bpf_loop()).
Excerpt in the code browser
10
SHA-NI with CPUID dispatch: 357 → 2,151 MiB/s (6.0×), bit-exact vs sha256sum on 223 files, UBSan clean
artefacthyptcn3 @ 97b0c43 · private
data/results/optim_hash_20260918.json → values.sha256_priepustnost_mib_s, values.overenie
The intrinsic ordering in the SHA-NI path follows the Intel / noloader SHA-Intrinsics reference (vmicollect/src/sha256.c:21-26).
Excerpt in the code browser
11
Cause of a 56× slowdown: SHA-256 over the whole 4 GiB sparse file including holes (42.2 s → 0.75 s)
artefacthyptcn3 @ 97b0c43 · private
docs/MERANIA.md:135-156commit 18d4eaf
The measurement log itself notes that the pair of runs is not a clean A/B comparison (different times, 307 vs 493 MiB written) and cannot pass as a repeated measurement.
12
Periodic capture at a 5 s period: 12 cycles, 0 missed slots
artefacthyptcn3 @ 97b0c43 · private
data/results/2026-09-18_zmrazeny_host/summary.json → values.run_delta_perioda_5s.summary_z_behu
The run log in run_delta_5s.json ends with “0 zmeskanych slotov” (0 missed slots).
13
Idle guest: median 245 changed pages of 528,417 between snapshots (~0.046%)
artefacthyptcn3 @ 97b0c43 · private
data/results/2026-09-18_zmrazeny_host/summary.json → values.run_delta_perioda_5s.prirastkove_snimky_bez_sedenia_ssh
14
Snapshot → feature vector latency: median 604.3 ms, p95 612.6 ms
artefacthyptcn3 @ 97b0c43 · private
data/results/latency_vector_20260918.json → values.suhrn["on_2.0s_delta"].latencia_ms
From the start of the capture cycle to the written features block; 2 s period, delta writer, hash off.
15
Kernel-image VA→PA offset (phys_base, includes KASLR) found in the validation snapshot: −2 MiB (−2,097,152 B)
artefacthyptcn3 @ 97b0c43 · private
data/results/2026-09-18_zmrazeny_host/validate2.json → snapshot.ktext_shift
16
The C per-bin feature module matches the Python reference on 6 snapshots × 131 bins
artefacthyptcn3 @ 97b0c43 · private
data/results/perbin_crosscheck_20260918.json → values.vsetky_porovnania_ok
17
Tests: 213 collected, 185 pass, 28 skip on a clean clone
testhyptcn3 @ 97b0c43 · private
python3 -m pytest -q on a clean clone at 97b0c43; the skipped tests need local snapshots that are not in the repository.
18
v1 (hypTcn): 5 of 37 commits carry Co-Authored-By: Claude; the live-VM Go binary was never tested against a real VM
git historyhypTcn @ 9fa11b6 · private
PROJECT.md:247
The C/Go core commits carry no trailer, but Claude Code was already in use in the repository, so a missing trailer proves nothing. The repository is private now.
Excerpt in the code browser
19
v2 (hypTcn002): 332 of 408 commits on develop (81%) carry an AI co-author trailer, including 37 commits imported from v1
git historyavUnitfan/hypTcn002 @ 0acd094 · private
commit 0acd094
Second GitHub account (avUnitfan). Across all branches 348 of 424 (82%).
20
v2: an eBPF agent inside the guest, and a KVM dirty ring “implemented, blocked” (the probe ran in 200 ms polling mode)
codeavUnitfan/hypTcn002 @ 0acd094 · private
internal/extractor/kvm_dirty_ring.c:283-338
Agent: tools/guest-agent/ and probe/ebpf_per_process/. README.md:117-136 at 0acd094 describes the dirty-ring status (ptrace_scope=1, libvirt 10.0).
Excerpt in the code browser
21
Thesis v3: 0 trailers, yet AI-assisted
git historyhyptcn3 @ 97b0c43 · private
About 24 h of history with large commits, review documents written by AI, and an AI agent wrote the SHA-NI hashing change. My role: design, directing and checking the measurements, debugging, checking the validation and retracting wrong results.
22
Retracted v2 results and why: session-level labels and window leakage between the training and test sets
artefacthyptcn3 @ 97b0c43 · private
HONESTY.md → § 2
23
Claims linter: flags retracted numbers and checks {{res:…}} provenance tags against result JSON files
codehyptcn3 @ 97b0c43 · private
scripts/check_claims.sh
No CI job or hook runs it, so it blocks nothing. At 97b0c43 it exits 1 with 38 findings, mostly in docs/notebookLM.md.
24
Test: a signal that carries only the session identity must not beat chance
testhyptcn3 @ 97b0c43 · private
tcn/tests/test_tcn.py:162-176
test_split_neprepusta_identitu_session

Job and projects

25
Marketeam: Symfony 3.4 → 6.4 migration, staging and deployment infrastructure
statement
My own statement from my CV; the company code is not public.
26
Pretix container memory: 6.7 GB before the change, ~0.9 GB after
measured at work
Measured at work; the figures are not in any repository.
27
One-line change --concurrency 2 for the pretix taskworker (supervisord)
git history
deployment/docker/supervisord/pretixtask.confcommit 3e0dc2f07
Merged PR #1 in Marketeam-SK/pretix; commit 3e0dc2f07 in the ErikHorvath-git/pretix fork. The PR is titled “Increase concurrency for pretix taskworker”; the diff adds --concurrency 2 to a command that had no limit before.
On GitHub
28
Share of the backend: 11,075 of 11,215 Python lines (98.75%)
git blameBally17/SIprojekt @ 2e96d44 · public
git blame over the backend Python, excluding migrations; 96.4% with move/copy detection. The frontend (my share 1.7%) and the SQL schema are my teammates’ work.
29
OAuth 2.0 server: grants and private_key_jwt client authentication
codeBally17/SIprojekt @ 2e96d44 · public
backend/services/auth/oauth/token_flow.py:20-71
See also pkce.py and authorization.py in the same folder. Known gap: jwt.decode (line 57) does not require an exp claim, and jti is not checked against replay.
Excerpt in the code browser
30
PKCE: S256 and plain; plain is the default
codeBally17/SIprojekt @ 2e96d44 · public
backend/services/auth/oauth/pkce.py:1-20
pkce.py:5, 18 and authorization.py:64.
Excerpt in the code browser
31
End-to-end test of a client with a signed JWT assertion (RFC 7523)
testBally17/SIprojekt @ 2e96d44 · public
backend/tests/test_external_integration.py:232-265
Excerpt in the code browser
32
GitHub Actions release pipeline (11 steps, images to GHCR)
codeBally17/SIprojekt @ 2e96d44 · public
.github/workflows/release.yml
Successful run on 13 January 2026.
33
Init script: wrapping appendChild and insertBefore before the page’s JavaScript
codescanforeshop @ 23ba0ea · private
backend/services/discovery/__init__.py:9-45
Only these two functions are wrapped (lines 41–42); downstream, only records with a src are kept (lines 130–134).
Excerpt in the code browser
34
scanforeshop was built with AI assistance (OpenAI Codex)
statementscanforeshop @ 23ba0ea · private
My statement of 25 September 2026. Git has no AI trailers; the code has identifiers such as __codexDynamicScripts and data-codex-*.
35
Score formula: noise, unverified scripts and behaviour penalties, with no term for the dynamic flag
codescanforeshop @ 23ba0ea · private
backend/services/scoring/engine.py:151-157
36
SHA-256 script identity and a deterministic scan diff
codescanforeshop @ 23ba0ea · private
backend/services/normalization/__init__.py:45-78
See also backend/services/diff/engine.py and pipeline.py.
Excerpt in the code browser
37
PoC status: phase 6 unfinished, “green” phases per commit messages
git historysovereign-ai-poc @ e9ded40 · private
NEXT.mdcommit e6a304b
The dataset for phases 2, 4 and 5 is not committed, so they cannot run from a clean clone.
38
Supply chain: Trivy gate → cosign signature by digest → SBOM
codesovereign-ai-poc @ e9ded40 · private
scripts/supply_chain.sh:54-92
Excerpt in the code browser
39
Negative tests: unsigned and vulnerable images are rejected
testsovereign-ai-poc @ e9ded40 · private
scripts/verify_phase3.sh:53-80
Excerpt in the code browser
40
bpftrace egress monitor: ordinary connections vs. deliberate exfiltration
testsovereign-ai-poc @ e9ded40 · private
scripts/verify_phase5.sh:123-172
The monitor itself is infra/ebpf/egress_monitor.bt.
Excerpt in the code browser
41
eval/ frozen by instruction only; agent commit b1390f9 changed eval/eval.sh’s mode
git historydolt-platform @ c65abb0 · private
run-loop.sh:20commit b1390f9
The instruction is in run-loop.sh:20 and in the agent instructions. eval/eval.sh arrived in commit b2bdee5 (with a Claude trailer); decision D-012 in CONTEXT.md records that I specified it.
42
The server re-verifies the chain but only stores the ed25519 signature
codedolt-platform @ c65abb0 · private
server/app.py:19-28
See also server/chain.py.
43
Acceptance harness with 27 checks and a ratchet; reproduced 27/27
testdolt-platform @ c65abb0 · private
eval/eval.sh:187-212
The ratchet fails only when the PASS count drops below the best recorded (eval.sh:198–203). Decisions D-001 to D-015 are in CONTEXT.md.
Excerpt in the code browser

Limitations

44
The commit that brought the vmicollect collector into hyptcn3 unchanged
git historyhyptcn3 @ 97b0c43 · private
commit 6b9053d
Commit message: “vmicollect: prevzaty stav k 2026-08-26, bez zmien” (imported state as of 2026-08-26, unchanged). Lines last changed by this commit are marked in the blame as imported code, author unknown.
45
Nginx: rate limits, a TLS 1.2/1.3 profile and security headers are in the config
codeBally17/SIprojekt @ 2e96d44 · public
nginx/nginx.conf:31-66
The committed production config never served TLS: nginx -t fails on it.

Code: repositories

46
Repository snapshot from the GitHub API
git history
File tree, languages, commit counts and excerpts at each repo’s pinned commit, generated by tools/snapshot at build time. Each excerpt’s text is checked against the git blob hash, and an anchor line must lie inside its range.
47
Commit and AI co-author trailer counts for each repository
git history
src/data/snapshot.json → repos[].commits.total, repos[].commits.aiCoAuthored
This site’s static snapshot (tools/snapshot). It counts the commits reachable from the pinned commit; a trailer is a Co-Authored-By line naming Claude, Copilot, Cursor, Codex, GPT, OpenAI or Anthropic.

Code: excerpts

48
Git blame of the excerpts at the pinned commit (GitHub GraphQL)
git blame
Only a short hash, a date and three flags are kept per commit: author is my account, AI co-author trailer, imported commit. No names, e-mails or commit messages are stored. Checked against a local git blame --porcelain: all 960 lines in 25 excerpts match.

Work

Experience and education

Employment

Education

Stack

Master’s thesis

Three iterations

I found a flaw in my own results and withdrew them

What I built afterwards

How an address in the machine’s memory becomes one specific byte of RAM

Job and projects

Marketeam: Symfony 3.4 → 6.4, staging and Pretix memory

Internship management system: backend and custom OAuth 2.0 server

scanforeshop: scripts injected into e-shops at runtime

Signed supply chain and egress monitor (PoC)

dolt: assessing DevOps skills from work traces

How I work with AI

Limitations

Reviews

How I verify reviews

What I check

What this does not prove

Rules

Contact with the author

Sources

Master’s thesis

Job and projects

Limitations

Code: repositories

Code: excerpts