Skip to content

Independent offensive security research

Research what breaks.
Engineer what holds.

Independent vulnerability research, advanced penetration testing, and security engineering for complex software, cloud infrastructure, and AI systems.

Research-led security

Most security work inspects the surface. We go after the structure — because a system is only as trustworthy as the assumptions holding it together, and those assumptions are where real failures live.

Understanding a system deeply is not an academic luxury. It is the difference between a finding that gets patched and a defect class that stops shipping. When you know why something breaks, you can engineer what holds.

01

Depth over coverage

A scanner tells you what it already knows to look for. We understand a system well enough to find what nobody was looking for.

02

Evidence over assertion

Every claim is reproduced and demonstrated. Executed proof is the only standard that survives an adversary.

03

Causes over symptoms

A patched instance is not a solved problem. We work to eliminate the defect class so the next variant never ships.

04

Clarity over theatre

Findings are written to be acted on — precise for the engineer, honest for the people carrying the risk.

Expertise & services

Five disciplines, one way of working.

01

Vulnerability Research

Find the flaw before an adversary writes the exploit.

Sustained, curiosity-driven investigation into how software and systems break — from kernel memory handling to isolation boundaries — grounded in executed evidence rather than theory.

  • Operating-system and kernel security
  • Memory corruption and memory safety
  • Virtualization and isolation boundaries
  • AI inference systems and native execution
  • Security architecture and trust boundaries
  • Implementation-level defect analysis
02

Penetration Testing

Authorized assessment with the depth of real research.

Scoped, consent-based engagements for organizations that need serious technical investigation — not a scan report. Every finding is reproduced, explained, and tied to concrete impact.

  • Web applications and APIs
  • Cloud and infrastructure
  • Kubernetes and container platforms
  • AI agents and LLM applications
  • Authentication and authorization systems
  • Remediation validation
03

AI Security

Measure what an AI system can actually reach.

Assessment of agents, LLM applications, and inference stacks as execution surfaces — tool and data boundaries, authorization between agents and services, and the native code behind modern inference.

  • Agent and tool-execution boundaries
  • LLM application security
  • Inference runtimes and native code
  • Model-serving infrastructure
  • Agent, tool, and data authorization
  • Model and extension supply chain
04

Cloud & Infrastructure Security

Find the identity that quietly owns everything.

Assessment of cloud accounts, Kubernetes platforms, and the infrastructure that deploys them — privilege paths, workload isolation, and the trust placed in managed services, proven from a realistic foothold.

  • Cloud IAM and privilege-escalation paths
  • Kubernetes and container platforms
  • Workload, tenant, and account isolation
  • Infrastructure-as-code and configuration
  • CI/CD and deployment-pipeline trust
  • Service-to-service authorization
05

Security Engineering

Remove the weakness, not just the symptom.

Work with your engineers to understand and eliminate the underlying causes — design flaws, unsafe assumptions, inadequate authorization, missing validation, and incomplete fixes.

  • Threat modelling and trust-boundary review
  • Secure design and architecture guidance
  • Authorization and access-control design
  • Fix verification and defect-class elimination
  • Security review of critical software
  • Hardening and defensive engineering
The research process

How we move from a question to a proven answer.

We investigate assumptions, execution paths, and system boundaries until a claim is either disproven or demonstrated. Every finding carries evidence and a fix that holds.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Technical focus

Where we go deep.

The domains where implementation detail decides whether a boundary actually holds — from the kernel upward to the systems running modern inference.

Systems

Kernel & operating systems

Privilege boundaries, syscall surfaces, drivers, and the memory handling that underpins the whole stack.

Memory

Memory safety & corruption

Use-after-free, out-of-bounds access, type confusion, and the primitives that turn a bug into a capability.

Cloud

Cloud-native infrastructure

Kubernetes, containers, and the identity, isolation, and configuration seams between managed services.

Isolation

Virtualization & isolation

Hypervisor and sandbox boundaries — the assumptions that are supposed to keep tenants and workloads apart.

AI

AI inference & native execution

Model-serving runtimes, agent tool execution, and the native code paths behind modern inference.

AppSec

Applications & APIs

Authentication, authorization, and the logic flaws that scanners never reach.

Selected research

The questions we are chasing.

These are active directions of inquiry, not a list of trophies. Verified advisories appear here only after coordinated disclosure is complete.

R-01
  • 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.

R-02
  • Memory safety
  • Exploitation
  • Systems

Memory safety as a capability question

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.

R-03
  • AI
  • Inference
  • Native code

Native execution behind AI inference

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.

R-04
  • Cloud
  • Kubernetes
  • AppSec

Authorization in distributed systems

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.

The practice

Independent by design.

Edictum Labs is a small, senior security practice being established in Prague. Founder-led and research-first, it exists to do the deep technical work larger firms treat as an exception — with no layer of account managers between you and the person doing the research.

The work is held to one standard: understand the system well enough to say something true about it, then prove it.

Projects

Edictum

Runtime governance for AI agents — decide before the agent acts, record every decision. A separate product initiative, developed independently of the Labs’ client work.

Engagements

Bring us the system you’re least sure about.

Vulnerability research, an authorized assessment, or a second opinion on a fix you are not confident closed the issue. Tell us what you need examined.

Reply
Within two business days
Authorization
Written, before any testing
Based in
Prague, Czech Republic