- Virtualization
- Containers
- Kernel
Trust boundaries under real execution
Where isolation is assumed but not enforced — the gap between a documented boundary and the code that is supposed to hold it. Hypervisors, sandboxes, and container runtimes.
How we work, the questions we are chasing, and how we handle what we find. This is an honest account of method and direction — not a trophy case.
Map the real system — its surfaces, dependencies, and the boundaries it claims to enforce. We start from what the code does, not what the documentation says.
What is actually here?Map the real system — its surfaces, dependencies, and the boundaries it claims to enforce. We start from what the code does, not what the documentation says.
Which assumptions hold under pressure?Pursue the questions that matter: execution paths, state transitions, and the invariants a system quietly depends on. Curiosity is the method.
Can it be proven?A hypothesis is not a finding. We reproduce the issue with working evidence and establish the precise conditions under which it holds.
Why does it happen, and what does it cost?Root cause, impact, and the defect class behind it — written so an engineer can act and a decision-maker can weigh the risk.
Is it genuinely fixed?We help design the fix and verify it closes the class, not just the instance — then confirm the boundary actually holds.
Where isolation is assumed but not enforced — the gap between a documented boundary and the code that is supposed to hold it. Hypervisors, sandboxes, and container runtimes.
Reasoning about corruption primitives in terms of the capabilities they grant, not the crash they produce. From the first out-of-bounds read to a controlled, repeatable outcome.
Model-serving stacks and agent runtimes execute native code and reach real resources. We study the paths where inference meets the operating system, the filesystem, and the network.
Identity, delegation, and access control across services and tenants — the logic flaws that survive every scanner because they are correct code doing the wrong thing.
When our research affects third-party software, affected vendors receive a reasonable window to remediate before anything is made public. Verified advisories will appear here once that coordinated process completes — with full detail, and never a day before.
If you believe you have found a vulnerability relevant to our work, or you want to report an issue in your own systems, reach the security contact directly.