I'm Miha, a software engineer based in Slovenia. I've spent most of the last decade on backend systems and digital identity infrastructure, with a long run of embedded and hardware work alongside it, and now I bring that depth to AI engineering, building reliable, secure LLM systems.
My work runs from multi-tenant APIs to microcontrollers. On the software side: the access-control layer and audit trail of a multi-tenant platform in production, EU digital-identity wallets that passed EBSI Conformance Testing in full, and serverless security infrastructure on AWS. On the hardware side, embedded systems and environmental sensing — a GPS-GSM tracker deployed on around a hundred sea turtles for an EU conservation project, and a network of stations monitoring air and sea quality around a working port. A good share of it ran on blockchain rails, in Rust and Solidity; that's depth I still draw on rather than the headline.
The two sound unrelated, but the discipline is the same. A turtle surfaces for a couple of seconds at a time, so the device has to catch what it can and let the server do the thinking — and then keep doing that, unattended, for months on a sliver of power. A permission check has to hold every single time, because letting the wrong tenant through once is a breach rather than a bug. Both are about staying reliable when there's no second chance. That's the instinct I bring to AI: the interesting problem isn't getting a model to respond, it's making the system around it reliable, and keeping it from getting exploited.
That second half is deliberate. I'm a Certified AI Security Professional (CAISP, May 2026), trained hands-on to attack and defend LLM systems: direct and indirect prompt injection, insecure tool use, model and supply-chain risks, and the threat modeling to catch them before they ship. It isn't theoretical. Adversarial testing of LLM systems is part of my current work, including a PyRIT-based scanning suite for MCP tool servers that covers part of the OWASP Top 10 for MCP, with an agent mode that drives a real tool-calling loop rather than replaying static prompts. Regulation is catching up fast, so findings increasingly have to hold up as evidence rather than as a bug report. It's the same instinct as the reliability work: assume the thing will be attacked, and build so it holds anyway.
Lately that instinct is pointed at agents with memory. I run Hermes Agent self-hosted, with HindSight as the memory provider in Docker and fact extraction on a local Ollama model, and I use it the way I'd audit anything: check what the agent says against what the provider actually holds. The two disagree more than you'd expect. The agent confirms a fact as saved before extraction has run, and a failed extraction never reaches the conversation. Memory is shared across profiles unless you configure isolation yourself. A fact can be persisted for minutes before recall will return it, so a missing answer is not a missing write. I wrote a skill that verifies the write against the provider instead of taking the agent's word for it, and I'm writing up what the SOUL.md file does to the prompt, measured rather than assumed. An agent that remembers across sessions and writes its own skills has an attack surface nobody has mapped properly yet. That's the work I want.