Explicit authority
Execution is allowed by structured policy, not by a model deciding that something looks safe.
Drelvan · Developer Beta · v0.1.1
Security at the
moment of action.
Drelvan is a deterministic execution-security kernel for developers, AI agents and automated workloads. It turns execution authority into an explicit, enforceable security decision.
WINDOWS x86_64·LINUX x86_64·LOCAL-FIRST
DRELVAN / SECURITY KERNELLOCAL / ENFORCED
AUTH●EXECUTION
AUTHORITY
AUTHORITY
IDENTITY
POLICY
EFFECT
EVIDENCE
authorize·enforce·observe·prove
01 / THE PRODUCT
A small developer tool with a large security trajectory.
Drelvan today: a local execution-security kernel and CLI. A developer can initialize a project, inspect an explicit policy, authorize a workload, enforce execution through the host, and inspect the resulting events, evidence and receipts.
Drelvan over time: the same security primitive can sit underneath agents, tools, applications, workloads and managed fleets without moving the fundamental authorization decision into a cloud service or an AI model.
Real enforcement
The authorization decision reaches the native process-execution boundary.
Evidence by design
Decisions and execution outcomes can produce events, provenance and verifiable receipts.
Local security authority
The core security decision does not depend on cloud availability.
02 / SEE IT WORK
From deny to protected execution.
Use the same mental model as the real CLI: start with a closed policy, make authority explicit, activate it, then execute and inspect the security record.
LIVE WALKTHROUGH
$ drelvan init initialized Drelvan project policy=deny-by-default runtime_state=ready $ drelvan protect ./your-program status=denied message=no policy rule matched the requested action $ drelvan policy activate policy_activation=updated runtime_state=ready $ drelvan protect ./your-program status=succeeded execution=native-protected-process $ drelvan evidence records=4 integrity=verified
This is a product walkthrough, not a simulated security claim. The beta implements the same core workflow locally; exact workload behavior depends on the platform and policy.
03 / QUICK START
Five minutes from download to protected execution.
Start with a real developer workload. Drelvan is deny-by-default, so authorization is visible instead of implicit.
Initialize
drelvan init
Creates the local Drelvan project and starts with a deny-by-default policy.
Inspect
drelvan doctor drelvan policy
Check platform readiness and inspect the current authorization rules.
Try the workload
drelvan protect <absolute-program>
An unmatched execution request is denied rather than silently granted.
Change policy deliberately
drelvan policy validate drelvan policy activate
Validate the structured policy, then activate the new policy state.
Execute and inspect
drelvan protect <absolute-program> drelvan events drelvan evidence drelvan receipt
Run the authorized workload and inspect the resulting security history.
04 / POLICY
Policy is the authority.
Drelvan uses structured policy rather than natural-language authorization. Rules explicitly describe who can perform an action against a resource.
The safe policy-change path is deliberate: validate → verify → activate → re-check → execute. Revocation removes runtime authorization; approval can explicitly re-authorize after a deliberate revoke.
EXAMPLE / EXECUTION RULEallow
policy=allow|local-user|execute|logical|<exact-workload-identifier>
Exact matching is intentional. Drelvan does not assume that an unmentioned workload is safe.
05 / WHAT DEVELOPERS CAN PROTECT
Developer workloads
Protect native programs, scripts and command-line workloads where execution authority matters.
AI tooling
Use explicit execution authorization around agent and tool-running workloads instead of treating tool output as authority.
Windows applications
The beta's native process path can protect ordinary executables and has been exercised with a packaged Windows application.
Security-sensitive automation
Put a policy boundary around automated workloads whose ability to execute commands should be explicit and inspectable.
Beta scope.These are current developer use cases, not a claim that every application, platform or isolation mechanism is supported.
06 / ARCHITECTURE
One security lineage from intent to outcome.
Drelvan keeps the security relationship intact from an untrusted request through authorization, native execution, real effect, evidence and response.
01REQUEST → IDENTITY → POLICYunderstand the requested action
↓
02AUTHORIZATION → SECURITY INVARIANTSestablish permitted authority
↓
03EXECUTION AUTHORITY → NATIVE BINDING → OS ENFORCEMENTmake authority real
↓
04REAL EFFECT → OBSERVATION → OUTCOMErecord what actually happened
↓
05PROVENANCE → EVIDENCE → RECEIPT → AUDITmake security history verifiable
↓
06RE-EVALUATION → CONTAINMENT / REVOCATIONrespond when authority changes
07 / THE LARGER VISION
The first product is narrow.
The security kernel is not.
Developers should be able to use Drelvan today without buying into the entire future platform. The architecture is designed so the same kernel can grow underneath larger security systems.
Developer execution security
Local policy, deterministic authorization, protected process execution, events, evidence, receipts and diagnostics.
Agent & tool security
Execution boundaries for AI agents, tool calls and automated workflows, with authority and provenance attached to real effects.
Universal runtime security
Cross-platform enforcement adapters, execution graphs, information-flow and behavioral analysis, response and containment.
Security control plane
Managed policies, identity, fleets, governance, centralized evidence, collaboration, integrations and enterprise deployment.
The thesis: security should reach the moment software actually causes an effect. Drelvan is being built as the substrate that makes that authority explicit, enforceable and provable.
08 / TRUST & BETA SCOPE
Claims stay inside the evidence.
The current public release is a Developer Beta. Internal engineering validation covers documented security, enforcement, adversarial, reliability, performance and supply-chain work. That is not represented as an independent audit, penetration test or external certification.
✓Windows x86_64 — supported developer beta.
✓Linux x86_64 — supported developer beta.
✓Local security authority does not depend on cloud authorization.
—macOS native enforcement — not claimed in this beta.
—Independent security assessment — not yet performed.
09 / BETA FEEDBACK
Try to break it.
The Developer Beta is where real workloads become product evidence. Tell us what you protected, what failed, what surprised you, and what you need next.
What should you send?
What workload did you protect?Was execution allowed or denied as expected?Where did the developer experience get confusing?What would make you keep Drelvan installed?
Send beta feedback →
Feedback opens a public release-repository issue. Do not include secrets, credentials or sensitive data.
DRELVAN DEVELOPER BETA
Give your workloads an explicit execution boundary.
Start local. Protect something real. Inspect what happened.