Action-bound authority
Evaluate permission against the requested action, its target and its validity conditions.
AUTHORITY LAYER · DEVELOPED IN JAPAN
Autonomy needs an authority boundary.
AEGIS is an authority layer for autonomous systems. It separates the ability to execute an action from the authority to execute it, with an IP architecture designed to keep accepted actions within independently established limits.
Offered through D-Code for integration into autonomous agents, digital asset operations, unmanned systems, critical infrastructure and space platforms.
Developed in Japan. Licensed for integration.
01 / The IP
A defined boundary for permitted action.
A command can come from a legitimate source and still fall outside its permitted scope. AEGIS addresses the local decision: whether the available authority and evidence permit this action on this asset, under the applicable conditions.
Controlled degradation
Keep accepted actions within the authority that can still be established. Weaker connectivity or evidence must not create additional permission.
Local operational control
Design around the adopter’s operational authority, with no runtime dependency on D-Code infrastructure in the sovereign offline configuration.
Integration must preserve the platform’s stabilisation, safety controls and pre-authorised contingency behaviour.
Explore the architectureHow we develop the IPOriginal IP.
Original IP.
Foundations re-engineered for today.
AEGIS brings original IP together with insights from established research and publicly disclosed patent literature. We revisit useful ideas, including those disclosed in patents whose terms have ended, and assess them against the needs of today’s distributed and autonomous systems.
The architectural value lies in how authority, evidence and local state work together at the point of command acceptance. Our development process selects the useful elements, revisits their assumptions and defines how they should behave as a coherent system.
Explore our approach to IP02 / Use casesOne authority boundary.
One authority boundary.
Four integration contexts.
Application scenarios for evaluation. Qualification is specific to the target platform.
UAV / Autonomous systems
UAV & Autonomous Systems
When a delayed command reaches an aircraft after connectivity returns, its permission must still be valid. Evaluate local acceptance, refusal and replay handling alongside the existing flight controller and autonomy stack.
Explore autonomous systems
Water / Energy / Remote assets
Critical Infrastructure
Remote commands must stay within the authority granted for each asset and operation. Evaluate this boundary at the local controller while preserving authorised local operation and established safety controls.
Explore infrastructure
Satellites / Ground / Onboard authority
Space Systems
Intermittent contact makes the validity of received commands and delegated actions critical. Evaluate local authority checks against the intended asset, activity and validity window.
Explore space systemsAI / Digital assets / Machine commerce
Autonomous Agents & Digital Assets
Credentials give an actor the ability to submit an action. AEGIS is designed to evaluate whether that specific action falls within independently established authority. Explore applications for agent-operated payments, asset operations and machine-to-machine commerce.
Explore agent authorityAI-generated conceptual imagery. The images do not depict AEGIS-equipped platforms or customer deployments.
A new application domainAuthority for
Authority for
autonomous agents.
Possession of credentials does not equal permission to act. As AI agents operate wallets, purchase services and control machines, their ability to act needs a defined authority boundary.
CAN is not MAY.
AEGIS separates technical capability from permission for a specific action. Authority must hold where the action executes, including when the acting system or its credentials are compromised.
Delegate work.
Define authority.
An agent may pay an approved service provider or operate a permitted resource. Its credentials alone should not authorise a different recipient, asset or operation.
Separate signing
from permission.
A valid signature does not by itself establish that a transfer is authorised. Evaluate authority for the proposed asset, recipient and operation at the point of execution.
Let machines act
within agreed limits.
Machines can request services, use resources and initiate payments. Each action needs to stay within the authority granted by the operator.
These are application scenarios and design objectives for evaluation. Compromise resistance depends on independent authority enforcement and execution paths that cannot bypass it; those conditions must be verified for each target platform. This page does not report completed digital-asset testing or a production deployment.
03 / EvidenceDefined rules.
Defined rules.
Reviewable evidence.
The current technical package includes documented acceptance rules, integration requirements and reproducible reference-model checks.
Selected authority, replay and recovery conditions have been checked with synthetic inputs under explicit model assumptions. Trusted state continuity is assumed in the models. Hardware validation is a separate qualification step.
View the evaluation scope01
Architecture and acceptance rules
DocumentedThe decision boundary and integration responsibilities are defined.
02
Selected reference-model checks
Executed under stated assumptionsResults address selected model conditions, with their assumptions and limits.
03
Platform validation and qualification
To be agreed for the adopting platformHardware, restart behaviour, timing and operational qualification require target-specific evaluation.
The principle / 24 secondsConnectivity can change.
Connectivity can change.
Authority does not expand.
A short illustration of the acceptance boundary through connection loss and recovery.
Concept animation · illustrative behaviour · no audioDownload MP4 ↓
Read the video transcript
Connected: each command still needs valid authority. Degraded: weaker evidence grants no additional permission. Link lost: only actions within locally established authority may be accepted. Reconnected: arriving commands are checked again; recovery does not grant blanket permission. Existing platform safety controls remain responsible for stabilisation and pre-authorised contingencies. This is a conceptual illustration, not footage of a validated implementation.
04 / LicensingLicense the layer
License the layer
your platform needs.
Commercial engagement is through paid IP licensing. Licence fees cover agreed evaluation and implementation rights. The adopting partner funds platform-specific validation and integration under a defined scope and acceptance criteria.
Paid IP rights
The licence defines the permitted use, deliverables and evaluation or implementation rights.
Partner-funded integration
The adopting partner funds its platform evaluation, integration and qualification.
Retained ownership
Core IP ownership is retained. Operational authority remains with the adopter. Treatment of improvements is agreed in writing.
Engagements are subject to Japanese export-control review, which we complete before any technical disclosure.
Detailed technical discussions proceed under NDA and an agreed disclosure scope.
A message from the CEOCompany information
A foundation for trusted autonomy.
As technology becomes more capable, we need a clear understanding of what a system is authorised to do. I believe this is one of the foundations of trust in AI and autonomous systems.
That trust depends on more than fast decisions or reliable connectivity. It also depends on who authorised an action, what that authority covers and the conditions under which it remains valid. Those limits need to hold where action takes place.
At D-Code, we develop this philosophy through the AEGIS architecture. Its design goal is to keep accepted commands within pre-authorised limits as connectivity and supporting evidence degrade, preserving the operator’s authority at the point of execution.
We also look carefully at the technical knowledge accumulated in research and patent literature. By selecting useful foundations, revisiting their assumptions and connecting them with original IP, we aim to build an architecture that addresses present-day implementation needs.
We aim to bring this approach to autonomous AI agents and digital asset operations, autonomous platforms and robotics, critical infrastructure such as water and energy, and satellite and space systems. Each application must be shaped by its own operating conditions and safety requirements, with clear criteria that adopters can evaluate.
Our role is to develop original IP and a clear architectural foundation, then work with partners who can carry it into their platforms. Through scoped IP licensing and partner-funded integration, we aim to make technology developed in Japan useful in demanding environments around the world.
Hiroaki Katsumoto
CEO, D-Code Inc.
Architecture notes
The Architecture of Acceptance
Selected perspectives on command authority and autonomous systems.
Start a conversation
Where does the authority boundary matter to you?
Send a brief, non-confidential introduction: your organisation, the platform you are working with and the authority-control problem you want to address.
Message Hiroaki on LinkedInOpens Hiroaki Katsumoto’s LinkedIn profile. A short introductory message is enough to start.