Just as a traditional Operating System (OS) serves as the foundation for safely coordinating computational resources such as CPUs, memory, and processes, Runtime OS can be viewed as the foundation for safely coordinating intelligence, humans, rules, organizations, and the physical world.
Whereas a conventional OS is responsible for the coordinated management of:
- CPUs
- Memory
- Processes
Runtime OS is responsible for the coordinated management of:
- Decisions
- Agents
- Boundaries
- Responsibilities
- Human approval
From this perspective, the architecture of Runtime OS closely mirrors that of a traditional operating system.
The Signal Input Layer corresponds to device drivers, the Decision Scheduler corresponds to the CPU scheduler, the Decision Runtime Kernel corresponds to the operating system kernel, and the Boundary Layer corresponds to the permission and protection mechanisms of a conventional OS.
In other words, AI-era decision systems can be understood through an operating-system-like architectural model.
In this chapter, we examine the Boundary / Permission Layer in detail.
Overview (Equivalent to Memory Protection and Permission Management)
Within Runtime OS, the Boundary / Permission Layer is one of the most critical components.
This is because the greatest risk in the age of AI is not simply that:
AI makes mistakes.
The real danger is that:
AI is allowed to execute actions without limits.
The same principle applies to traditional operating systems.
Without permission management, an operating system simply could not function.
Imagine if every process were free to:
- Modify another process’s memory
- Obtain root privileges
- Directly control hardware devices
- Delete system files
The operating system would collapse almost immediately.
For this reason, modern operating systems provide protective boundaries such as:
- Root privileges
- Process isolation
- Sandboxing
- Memory protection
- Capability control
The essence of the Permission Layer in a traditional OS is therefore simple:
Restrict what is allowed to execute.
Runtime OS faces exactly the same challenge.
However, Runtime OS is not responsible for managing:
- CPUs
- Memory
- Files
Instead, it manages:
- Decision making
- Agent execution
- Operations on external systems
- Workflows
- Human impact
- Effects on the physical world
Consequently, what the Boundary Layer protects in Runtime OS is:
The physical world from unsafe AI actions.
Why Is a Boundary Layer Necessary?
With a standalone generative AI model, occasional mistakes may not lead to serious consequences.
However, the situation changes dramatically as AI evolves into autonomous agents.
Modern AI systems can:
- Call APIs
- Modify databases
- Control manufacturing equipment
- Participate in medical decision-making
- Execute financial transactions
- Connect directly with social and industrial systems
In other words, AI becomes:
An entity capable of changing the real world.
The key point is that AI is no longer limited to reasoning.
It is beginning to acquire:
Execution capability.
The moment AI gains the ability to act upon the world, a Boundary / Permission Layer becomes indispensable.
What Is the Boundary in Runtime OS?
In Runtime OS, the Boundary defines:
The limits of how far AI and autonomous agents are allowed to affect the real world.
The Boundary Layer manages:
- Execution permissions
- Risk control
- Access and authority management
- Human approval
- Regulatory compliance
- Safety enforcement
In essence, it serves as:
The Permission System for the AI Era.
Correspondence with a Traditional Operating System
Traditional Operating System
| OS Function | Purpose |
|---|---|
| Root Privileges | Administrative control |
| Process Isolation | Protects processes from one another |
| Sandboxing | Isolates potentially dangerous operations |
| Memory Protection | Prevents runaway processes and unauthorized memory access |
Runtime OS
| Runtime Function | Purpose |
|---|---|
| Human Authority | Final human approval |
| Decision Boundary | Restricts executable decisions |
| Agent Isolation | Prevents autonomous agents from interfering with one another or behaving uncontrollably |
| Policy Enforcement | Applies organizational policies, regulations, and laws |
| Execution Permission | Controls execution privileges for AI and agents |
What Does the Boundary Layer Manage?
The Boundary Layer is far more than a conventional access control mechanism.
It governs:
- Execution scope
- Autonomy permission levels
- Risk levels
- Human impact
- Irreversibility
- Legal and regulatory constraints
- Safety requirements
- Organizational authority
- Responsibility boundaries
1. Agent Capability Control
The first responsibility of the Boundary Layer is to determine what each agent is allowed to do.
For example:
| Agent | Allowed Actions |
|---|---|
| Summary Agent | Summarization only |
| Monitoring Agent | Send alerts only |
| Financial Agent | Submit payment requests only |
| Medical Agent | Provide recommendations only |
In other words,
Every agent must have a clearly defined capability boundary.
Each autonomous agent should possess an explicit set of permissions that defines what it can and cannot execute.
2. Autonomy Level
The next responsibility is to determine how much autonomy should be granted to an AI system.
For example:
| Action | Autonomy Level |
|---|---|
| Drafting emails | Full Auto |
| Internal notifications | Semi Auto |
| Financial transfers | Human Approval |
| Factory shutdown | Multi-stage Approval |
The important question is not:
What is AI capable of doing?
Instead, the real question is:
How much autonomous execution should AI be permitted to perform?
The Boundary Layer is responsible for defining these limits, ensuring that autonomous execution is granted only where it is appropriate, safe, and consistent with organizational policy.
3. Risk Boundary
The Boundary Layer evaluates the level of risk associated with every requested action.
For example:
| Action | Risk Level |
|---|---|
| Save logs | Low |
| Update database | Medium |
| Modify medical records | High |
| Emergency shutdown | Critical |
When assessing risk, the Boundary Layer considers factors such as:
- Impact on human safety
- Financial impact
- Legal implications
- Irreversibility
- Societal impact
Its purpose is to ensure that high-risk actions receive an appropriate level of scrutiny before execution.
4. Human Approval Boundary
Actions that exceed a predefined risk threshold require approval through a Human Gate.
For example:
| Action | Human Approval Required |
|---|---|
| Reply to an email | No |
| Modify a contract | Yes |
| Change a medical diagnosis | Mandatory |
| Shut down a factory | Multi-stage approval |
This means that Runtime OS must define:
Areas where AI is prohibited from acting autonomously.
Certain decisions should never be executed solely by AI, regardless of its confidence or capability.
5. Legal / Compliance Boundary
The Boundary Layer also evaluates legal and regulatory requirements.
Examples include:
- Personal data protection
- Medical regulations
- Financial regulations
- Anti-Money Laundering (AML)
- General Data Protection Regulation (GDPR)
- Occupational health and safety regulations
In other words, Runtime OS must manage not only technical boundaries, but also:
Legal and regulatory boundaries.
Autonomous execution must always remain consistent with applicable laws, industry standards, and organizational policies.
6. Execution Isolation
Just as a traditional operating system implements process isolation, Runtime OS should implement agent isolation.
For example:
- A Financial Agent must not control manufacturing equipment.
- A Medical Agent must not initiate financial transfers.
- A Monitoring Agent must not delete databases.
In other words,
Autonomous agents must be isolated according to their responsibilities and capabilities.
This prevents agents from performing actions outside their designated domains and limits the impact of failures or unexpected behavior.
7. Boundary Escalation
Whenever an action exceeds the permitted boundary, Runtime OS initiates an escalation process.
For example:
AI
↓
Supervisor Agent
↓
Human Operator
↓
Manager
↓
Emergency Control
This mechanism is conceptually similar to the following mechanisms in a traditional operating system:
- Interrupts
- Privilege escalation
- Kernel panic handling
Rather than allowing an unsafe action to proceed automatically, Runtime OS transfers responsibility to a higher level of authority.
The Essence of the Boundary Layer
The most important point is this:
The Boundary Layer is not simply a mechanism for imposing restrictions.
Its true purpose is:
To safely connect AI to the real world.
Because the Boundary Layer exists:
- AI can safely execute actions.
- Autonomous agents can participate in society.
- Appropriate levels of autonomy can be granted.
- Risks can be controlled before execution.
- Responsibility and accountability can be clearly established.
The Boundary Layer is therefore not a barrier to AI—it is the foundation that makes trustworthy autonomous execution possible.
The Position of the Boundary Layer in Runtime OS
From the perspective of the Decision Trace Model (DTM), the execution flow is:
Event
↓
Signal
↓
Decision
↓
Boundary
↓
Human
↓
Execution
↓
Trace
The Boundary Layer is positioned between:
Decision
↓
Boundary
↓
Execution
In other words, the Boundary Layer serves as:
The safety layer between reasoning and real-world execution.
It is the mechanism that transforms AI-generated decisions into actions that are safe, authorized, explainable, and accountable.
The Fundamental Difference in Runtime OS
In a traditional operating system, the primary objective is to:
Prevent runaway processes.
In Runtime OS, however, the objective becomes:
Prevent runaway decision-making.
In other words, the Boundary Layer in Runtime OS serves as a:
Decision Protection Mechanism.
Design Principles of the Boundary Layer
Accordingly, the Boundary / Permission Layer can be defined as follows:
The Boundary / Permission Layer is the safety control layer of Runtime OS that governs the extent to which Agents, Decisions, and Executions are permitted to affect the real world. It evaluates Human Authority, Organizational Policies, Risk, and Legal Constraints to determine the allowable scope of autonomous execution.
This definition captures the true essence of the Boundary Layer within Runtime OS.
Architectural Design
The basic architecture is as follows:
Decision Request
↓
Capability Checker
↓
Risk Evaluator
↓
Policy / Legal Checker
↓
Autonomy Level Resolver
↓
Human Gate Resolver
↓
Execution Permission Engine
↓
Boundary Decision
1. Capability Checker
The first step is to determine whether a particular agent is authorized to perform the requested action.
In a traditional operating system, this is equivalent to questions such as:
- Can this process read this file?
- Does this user have root privileges?
- Is this application allowed to access the network?
Similarly, Runtime OS asks questions such as:
- Can this agent initiate a financial transfer?
- Can this agent modify a database?
- Can this agent shut down a manufacturing system?
- Can this agent participate in medical decision-making?
Example:
{
"agent_id": "summary_agent",
"requested_action": "send_payment",
"capability_result": "deny",
"reason": "summary_agent_has_no_financial_permission"
}
The key principle is that every autonomous agent must have a clearly defined Capability Profile.
2. Capability Profile
A Capability Profile defines the permissions and limitations assigned to each agent.
Example:
{
"agent_id": "monitoring_agent",
"allowed_actions": [
"read_logs",
"detect_anomaly",
"send_alert"
],
"denied_actions": [
"delete_database",
"transfer_money",
"stop_machine"
],
"allowed_resources": [
"logs",
"sensor_streams"
],
"max_autonomy_level": "semi_auto"
}
This profile specifies:
- What the agent is allowed to do
- What the agent is prohibited from doing
- The maximum level of autonomous execution the agent is permitted to perform
Clearly defining these capabilities prevents agents from operating outside their intended responsibilities.
3. Risk Evaluator
The next component evaluates the inherent risk associated with the requested action.
Typical evaluation criteria include:
human_impactfinancial_impactlegal_impactsafety_impactprivacy_impactreversibilityexternal_world_impact
Example:
{
"risk_score": 0.91,
"risk_level": "critical",
"risk_factors": [
"human_safety",
"irreversible_action",
"physical_world_control"
]
}
The important principle is that authorization alone is not sufficient.
Even if an agent has permission to perform an action, autonomous execution should be prevented whenever the associated risk exceeds an acceptable threshold.
4. Policy / Legal Checker
The next stage verifies whether the requested action complies with organizational policies, legal requirements, and safety standards.
Typical policies include:
safety_policyprivacy_policyfinancial_policymedical_policyfactory_operation_policyhuman_approval_policy
Example:
{
"policy_result": "requires_human_approval",
"matched_policies": [
"factory_shutdown_policy",
"human_safety_policy"
],
"reason": "machine_shutdown_requires_manager_approval"
}
This layer connects AI-generated decisions with organizational governance and legal compliance.
Rather than allowing AI to operate solely according to its internal reasoning, the Policy / Legal Checker ensures that every execution is evaluated against external rules, regulations, and organizational requirements before it is allowed to proceed.
5. Autonomy Level Resolver
The next step is to determine how much autonomous execution should be permitted.
A practical approach is to define five levels of autonomy.
| Level | Description |
|---|---|
| L0 | Observe Only |
| L1 | Recommend |
| L2 | Draft / Prepare |
| L3 | Execute with Human Approval |
| L4 | Execute Automatically |
For example:
| Level | Meaning | Example |
|---|---|---|
| L0 | Observation only | Log monitoring |
| L1 | Recommendation only | Anomaly detection recommendations |
| L2 | Draft preparation | Drafting emails |
| L3 | Execute after approval | Contract modifications, financial transfers |
| L4 | Fully autonomous execution | Low-risk notifications |
Actions such as factory shutdowns or changes to medical decisions should generally never be classified above L3.
Instead, they should be managed as:
Autonomous Execution Prohibited Zones
where human approval is always required before execution.
6. Human Gate Resolver
Based on the evaluated risk and policy, Runtime OS determines whether human approval is required.
Example:
{
"human_gate_required": true,
"approval_level": "plant_manager",
"approval_reason": "critical_safety_action",
"timeout_sec": 300,
"on_timeout": "escalate"
}
The Human Gate Resolver determines:
- Whether approval is required
- Who must approve the action
- Whether multi-stage approval is required
- What happens if the approval request times out
- What happens if the request is rejected
This mechanism ensures that critical decisions remain under appropriate human supervision.
7. Execution Permission Engine
Finally, the Execution Permission Engine returns the execution decision.
For an initial implementation, the following five permission states are sufficient:
allowallow_with_constraintsrequire_human_approvalescalatedeny
Example:
{
"permission_result": "require_human_approval",
"allowed_actions": [
"notify_operator",
"prepare_shutdown_request"
],
"blocked_actions": [
"auto_shutdown_machine"
],
"constraints": [
"manager_approval_required",
"record_decision_trace"
]
}
This clearly separates:
- Actions that AI is permitted to execute autonomously
- Actions that require mandatory human approval before execution
Proposed Boundary Policy Schema
Boundary rules are best managed using JSON or YAML, making them easy to maintain, version, and extend.
boundary_id: factory_shutdown_boundary
domain: manufacturing
action: stop_machine
risk_level: critical
conditions:
- safety_impact: true
- physical_world_impact: true
- reversibility: low
permission:
result: require_human_approval
approval_level: plant_manager
multi_stage: true
allowed_pre_actions:
- notify_operator
- prepare_shutdown_request
- run_additional_diagnostics
blocked_actions:
- auto_shutdown_machine
trace_required: true
escalation:
on_timeout: emergency_control
on_conflict: supervisor_review
Proposed Boundary Decision Schema
The Boundary Layer should return a structured decision object to the Runtime Kernel, such as the following:
{
"boundary_decision_id": "bd_001",
"decision_id": "dec_001",
"agent_id": "risk_agent",
"requested_action": "stop_machine",
"permission_result": "require_human_approval",
"risk_score": 0.94,
"risk_level": "critical",
"capability_result": "allowed",
"policy_result": "requires_human_approval",
"autonomy_level": "L3_execute_with_human_approval",
"human_gate": {
"required": true,
"approval_level": "plant_manager",
"multi_stage": true
},
"allowed_actions": [
"notify_operator",
"prepare_shutdown_request",
"run_additional_diagnostics"
],
"blocked_actions": [
"auto_shutdown_machine"
],
"matched_boundaries": [
"factory_shutdown_boundary",
"human_safety_boundary"
],
"reason": [
"physical_world_control",
"human_safety_impact",
"low_reversibility"
],
"trace_required": true,
"created_at": "2026-05-26T10:00:00+09:00"
}
Proposed Module Structure
boundary/
schemas.py
capability_checker.py
risk_evaluator.py
policy_checker.py
autonomy_resolver.py
human_gate_resolver.py
permission_engine.py
boundary_registry.py
service.py
Processing Flow
def evaluate_boundary(decision, agent, action, context):
capability = capability_checker.check(agent, action)
risk = risk_evaluator.evaluate(action, context)
policy = policy_checker.evaluate(
decision,
action,
context
)
autonomy = autonomy_resolver.resolve(
agent,
action,
risk,
policy
)
human_gate = human_gate_resolver.resolve(
risk,
policy,
autonomy
)
permission = permission_engine.decide(
capability=capability,
risk=risk,
policy=policy,
autonomy=autonomy,
human_gate=human_gate
)
return permission
Building the MVP
For the initial Minimum Viable Product (MVP), only four core components are required.
- Capability Checker
- Risk Evaluator
- Human Gate Resolver
- Permission Engine
The Policy / Legal Checker can initially be implemented using simple rule-based logic and expanded later as organizational policies and regulatory requirements become more sophisticated.
Minimal Rule Example
def decide_permission(action, risk_score, human_impact, reversibility):
if action in ["medical_change", "factory_shutdown"]:
return "require_human_approval"
if risk_score >= 0.9:
return "escalate"
if human_impact and reversibility == "low":
return "require_human_approval"
if risk_score < 0.3:
return "allow"
return "allow_with_constraints"
This simple implementation already provides a practical foundation for safe autonomous execution.
It ensures that:
- High-risk actions require human approval.
- Extremely dangerous actions are escalated.
- Low-risk actions may execute automatically.
- Medium-risk actions execute under defined constraints.
Additional policy, legal, and organizational rules can be layered onto this foundation over time.
Design Principles
The Boundary / Permission Layer is not merely a mechanism for prohibiting actions.
Its essential role is to evaluate the following decision flow:
AI Execution Capability
↓
Potential Impact on the Real World
↓
Policy / Risk / Human Authority
↓
Allow / Restrict / Require Approval / Deny
Rather than asking only “Can the AI perform this action?”, Runtime OS asks:
“Should the AI be allowed to perform this action under the current circumstances?”
This distinction is fundamental.
Definition
The Boundary / Permission Layer is the safety control layer of Runtime OS that evaluates an Agent’s capability, the associated risk, applicable organizational policies, human authority, and legal constraints before a Decision is allowed to affect the real world.
Based on this evaluation, it determines one of the following execution outcomes:
- Automatic execution
- Execution with constraints
- Human approval required
- Escalation
- Denial
This transforms autonomous AI from a system that merely can act into one that acts safely, responsibly, and within defined governance boundaries.
Ultimately, it is the Boundary Layer that enables AI to become:
A trustworthy execution system capable of safely participating in society.
Chinoba
Intelligence as Relationship
Research Platform
founded by
Masao Watanabe
AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance
Related Research
This topic is part of the Chinoba Knowledge Base.
コメント