In developmentAlpha
Deckent.
An Agent Control & Execution Plane, installed on your own infrastructure, that authorises, isolates, runs and proves every action of AI agents.
Deckent is an Agent Control & Execution Plane (a policy driven agent runtime) that a company installs on its own computer or server: the control plane that grants permission and the runtime where work proceeds in isolation, in one product. A person or an AI hands over a job; Deckent routes the tasks in order to the right agent, asks for human approval at risky steps, writes every step to a durable ledger and checks the result before delivering it. The core is open source under Apache-2.0 and runs on its own; enterprise packages are distributed separately.
deckent
Problem
Either let the agent loose or stand over it
Using a coding agent such as Claude Code, Codex or Cursor on its own is fast. As the work grows, three questions go unanswered: what does the agent have access to, what did it do, and can the result be trusted.
An agent working on its own runs on your computer with broad permissions. What it did stays in the conversation history. Whether to run a risky command is left to its judgement. The code it writes goes straight into your project. A crash or a cancellation leaves work half done, and nobody can say for certain whether the same operation ran a second time.
For one person this arrangement is manageable. For a team running several agents at once, or an organisation that wants to give agents real authority, it does not scale. Either you let the agent loose or you stand over it at every step.
Approach
The tower and the runway together
Deckent sits on top of the agents. The control plane (the tower) puts every operation through the question of who, in which scope, on which resource and under which written rule. The runtime (the runway) carries out the work in an isolated environment. Because both live in the same product, work that has not been permitted does not run, and no work that runs goes unrecorded.
Deckent's fixed principle is this: AI does not grant authority. A model's suggestion, a persona or a timeout never stands in for permission; permission comes only from an authenticated person and a written rule.
Every request travels the same route, in the same order.
Admission
A task graph arrives from the terminal, the command line, MCP or the SDK: which task waits for which, and which can run at the same time. Deckent admits the job and writes the intent to the durable ledger in a single transaction.
Authority and approval
If a rule requires it, an approval request opens. A pending request consumes no capacity and the decision is made by a person. An expired approval is void.
Isolated execution
A slot is reserved from the capacity pool. The coding agent (Claude Code, Codex or Cursor) runs inside Docker, without a network and on a pinned image, against its own copy of the project. The only way out is a gateway to permitted model addresses. The terminal agent's shell commands run in a bubblewrap sandbox with the network off.
Evaluation
The agent saying "I finished" is not enough; that report is kept only as a claim. Today a coding task is accepted on its acceptance criterion, the worker's exit code; the content is not verified independently, and the delivery window says so plainly. Before delivery, an accepted candidate is checked again in a separate copy of the repository with the checks the installation defines. A person accepts or rejects the result; once accepted, the tasks that depend on it open.
Delivery
The patch first becomes a separate Git candidate, then a delivery reference. Advancing the branch is a separate, approved step. Your working files are never touched, and a delivery can be rolled back.
Every transition along this route is written to the ledger, and the order is never left to the model's improvisation. Model output is probabilistic; what is deterministic is the authority, scheduling and recording layer.
Today
What it can do today
Deckent is reached through four doors: an interactive terminal, the command line, an MCP server for AI tools and an SDK for developers. All of them use the same contract and the same rules.
Agent terminal
An interactive agent terminal in the Claude Code class: reading and writing code through conversation, mentioning files, shell commands, approval cards, saving and resuming sessions, context and usage tracking. The difference is that every step passes through Deckent's rule, approval and recording system. The permission mode is switched with Shift+Tab; full access requires company permission and shows a warning on the bottom line while it is on.
Work with several agents
Splitting a job into tasks with a defined order and dependencies and having several coding agents work on them in parallel. Concurrency limits, holding and resuming the pool, cancellation and resuming where work stopped. If a step fails, the steps that depend on it close as "skipped".
Live monitoring
The monitor shows pending approvals, stuck work, failing tests and running agents in one place, and tells you which model each agent used, how long it ran and how it finished. The monitor changes nothing and makes no decisions.
Models and spending
Models on your own server (vLLM), Anthropic, OpenAI compatible servers and OpenRouter are managed from one place. Spending accounts are kept, and no call is made once the budget is exhausted. Deckent never quietly swaps one model for another.
Access from other software
The MCP server lets AI tools start work, monitor it and call models, but it cannot approve. The MCP client connects the tools of external MCP servers to Deckent's agent after a trust approval. The SDK lets developers call the same operations from their own code.
Termınal
Screens from the terminal
The screens below were taken from Deckent's own terminal: the real command line and the real runtime service on a temporary sample project, with a local test server standing in for the model.
Governance
You stay in control
What sets Deckent apart from its peers is not speed but accountability. You choose how much freedom to give the agent; whatever you choose, some things are always protected. For one person it is a safe working habit; for an organisation it is audit infrastructure. They are the same mechanism.
Written rules and four eyes
The answer to who may do what lives in written rules: deny, ask for approval, allow. Roles and the requirement that two different people approve an operation can be defined as rules. The template that comes with the first installation allows reading freely and requires approval for writing and shell commands.
Approval gates
At a risky step an approval window opens in the terminal: what will be done, with which command, where and inside which sandbox, on whose behalf, in which scope, why it is being asked, its risk and whether it can be undone, each on its own line. An approval is bound to a digest of the operation; if no decision is made in time, nothing runs. An AI tool can see approval decisions but cannot make them; the decision always belongs to a person.
Closed boxes
Coding agents run in containers without a network; credentials are handed over from a temporary in memory disk. The terminal agent's shell commands run inside a bubblewrap or Landlock sandbox where possible. If no sandbox is available, Deckent does not silently fall back to running unprotected; the screen says so plainly.
A floor no mode opens
Deckent's own records, identity and approval files, the audit key and credential patterns stay closed to the agent even in full access mode. This floor cannot be loosened by an approval either.
Secrets and hidden characters
API keys are never written to the settings file; the setting holds only the secret's name. If the agent tries to print a secret, the value is masked, and known provider key formats are hidden as well. Hidden and direction changing Unicode characters are flagged before they reach the model.
Sealed audit log
Every job, attempt, approval and result is written to a durable ledger. The audit log is append only; changes and deletions are blocked at database level and every record is sealed. An effect is recorded before it happens: no record, no effect.
The honesty rule
If Deckent cannot do something, it says so plainly. An unsupported platform or an unreachable provider does not quietly divert to another path; the state and the reason are written down. Unfinished work is never labelled a success. An operation with an uncertain outcome is never blindly retried; it is reconciled first.
Independence
Your data, no provider lock in
Deckent is not a cloud service. It is installed on a personal computer, an on premises server or the organisation's own cloud; the ledger, records and work outputs stay on the organisation's own disk. It does not need a Deckent cloud to run.
Nor is Deckent an AI model of its own; it manages models and agents. No provider is part of the product's identity. You can manage a model on your own GPU from the same place as cloud models and keep work that must not leave the company on a local model. Coding agents run with their own subscription sign ins.
Lıcence
An open core, separate enterprise packages
Core
Deckent's core is open source under Apache-2.0 and comes with the same rights for individual, team and commercial use. The core runs on its own and is not a limited trial.
Enterprise
Enterprise packages are distributed separately and are not part of the core's source. They plug in without changing the core; they do not invent security the core lacks, they carry controls that are already structural in the core to organisational scale. Installation, process analysis and integration are carried out together with Verhex consulting.
Roadmap
Today and tomorrow
Deckent's core (execution, security, recording and model connections) works and is used daily for software development. The enterprise and learning layers have not been written yet.
On the roadmap: long running missions, persistent memory, approved business processes with ERP systems, an additional isolation layer with micro virtual machines, a desktop application, an HTTP API, enterprise single sign on (SSO) and SIEM integration, and one step installation. None of these exist today; they will take their place on this page when they are ready.
Status
Where it stands
Deckent is a pre release in the 1.0.0 alpha series. It is written in TypeScript and requires Node.js 24 or 26. Today it is used daily on Linux and on Windows through WSL2; full support for macOS and native Windows has not been proven yet. Docker is required to isolate coding agents.
It has not been published to a package registry yet and is installed from source. The interface is in Turkish and English.
The release process is deliberately human approved. Every release goes through an independent review and more than five thousand automated tests, and the architecture rules are checked automatically on every change.
Early access
Deckent is in pre release. If you would like to try governed work with agents on a codebase, or discuss the enterprise layer for your organisation, fill in the form and we will clarify your use case together. Early participants have a direct say in how the product takes shape.
Next project