1. はじめに: 自己拡張問題
最新の AI エージェント システムは、静的なコマンド実行者ではなくなりました。彼らは運用環境のパターンを観察し、機能のギャップを特定し、それらのギャップを埋めるコードを生成することが増えています。データ パイプラインを管理するエージェントは、一般的な変換に専用のコマンドが欠けていることに気づきました。変換関数を作成し、サンプル データに対してテストし、システム内のすべてのエージェントが使用できる新しいコマンドとしてそれを登録することを提案します。
この機能は非常に強力です。これは、システムが人間工学の努力なしで新しい要件に適応できることを意味します。しかし、これは、自律システムによる実行時の自己変更という、従来のソフトウェア エンジニアリングが直面したことのない種類のリスクをもたらします。
攻撃対象領域を考慮してください。生成されたツールは、生成エージェントが保持するあらゆる権限にアクセスできます。登録が管理されていない場合、新しいツールはそれらのアクセス許可を永続的に継承します。このツールは、外部エンドポイントにログを書き込んだり、暗号化されていない一時ファイルに機密データをキャッシュしたり、他のプロセスが枯渇するまでリソース消費を徐々に拡大したりするなど、サイド チャネルを同時に開きながら、意図した目的のために正しく機能する可能性があります。
根本的な問題は、エージェントがツールを生成すべきかどうかではありません。生産性の向上は無視できないほど重要です。問題は、ツール Genesis を安全にするガバナンス アーキテクチャは何ですか? です。
1.1 既存のアプローチが失敗する理由
コード生成の安全性に対する現在のアプローチは 3 つのカテゴリに分類されますが、いずれもツールの生成には不十分です。
静的分析 は既知の脆弱性パターンを捕捉しますが、状況に応じて緊急の動作を推論することはできません。静的解析を個別に通過する生成されたツールは、既存のツールと組み合わせると危険な相互作用を引き起こす可能性があります。
コード レビュー により、自律的なツール生成の速度の利点が無効になる人間のボトルネックが生じます。生成されたすべてのツールに人間によるレビューが必要な場合、システムは自己拡張ではなく、人間が承認する必要がある拡張機能を提案していることになります。
テストでは、指定された期待に対する動作を検証しますが、指定されていない動作がないことを検証することはできません。すべてのテストに合格したツールでも、テストで予期されなかったアクションが実行される可能性があります。
必要なのは ガバナンス パイプラインです。これは、個々のゲートよりも強力な安全保証を提供する一連の自動ゲートです。
2. 形式モデル: 限定された決定可能性としてのツールの安全性
ツール $T$ をタプル $(C, P, S, E)$ として定義します。ここで、$C$ は実行可能コード、$P$ は宣言された権限セット、$S$ はツールがアクセスできる状態空間、$E$ はツールが生成する可能性のある副作用のセットです。
T = (C, P, S, E) \quad \text{where} \quad P \subseteq \mathcal{P}_{\text{system}}, \quad S \subseteq \mathcal{S}_{\text{registry}}, \quad E \subseteq \mathcal{E}_{\text{allowed}}ツールは次の 3 つの条件が同時に満たされる場合にのみ 安全 です。
\text{Safe}(T) \iff \text{Bounded}(C) \land \text{Contained}(P, S) \land \text{Declared}(E)制限付き は、リソース バジェット (時間、メモリ、I/O 操作) 内でコードが終了することを意味します。 含まれている は、ツールの実際のリソース アクセスが、宣言されたアクセス許可と状態空間を超えないことを意味します。 宣言 とは、ツールが生成するすべての副作用が登録前に明示的に宣言されていることを意味します。
一般に、任意のコードがこれらの特性を満たすかどうかを判断することは (停止問題に帰着することによって) 決定できません。ただし、制限付き実行 (ハード リソース制限を課し、隔離された環境で実行する場合) では、安全性が決定可能になります。
\text{Given } \text{budget}(\tau, M, I) \text{ and sandbox } \Sigma: \quad \text{Safe}_{\text{bounded}}(T) \in O(\tau \cdot \log M)重要な洞察は、ツールがすべての入力に対して常に安全であることを証明する必要はないということです。 実際に実行される限定された実行コンテキスト内内で安全であることを証明する必要があります。
3. 7 段階のツール生成パイプライン
MARIA OS Tool Genesis Framework は 7 つの連続ゲートを実装します。生成されたツールがコマンドとして登録されるには、7 つすべてに合格する必要があります。いずれかのゲートで障害が発生すると、パイプラインが終了し、詳細な監査レコードが記録されます。
| Stage | Gate | Purpose | Fail Action |
|-------|------|---------|-------------|
| 1 | Schema Validation | Verify tool declaration completeness | Reject with missing field list |
| 2 | Static Safety Analysis | Detect known vulnerability patterns | Reject with violation report |
| 3 | Sandbox Execution | Run tool in isolated environment | Terminate + capture forensics |
| 4 | Permission Verification | Confirm actual access matches declared | Reject with access diff |
| 5 | Formal Safety Proof | Verify bounded termination and containment | Reject with counterexample |
| 6 | Integration Testing | Test composition with existing tools | Reject with conflict report |
| 7 | Governed Registration | Register with audit trail and rollback hooks | N/A (final stage) |各ゲートは、ゲート証明書、つまり署名され、タイムスタンプが押された検証結果の記録を生成します。証明書の完全なセットは、不変でクエリ可能なツールの 出自チェーン を形成します。
interface ToolGenesisGateCertificate {
gateId: 1 | 2 | 3 | 4 | 5 | 6 | 7
gateName: string
toolId: string
timestamp: string // ISO 8601
result: "pass" | "fail" | "conditional_pass"
evidence: {
checksPerformed: string[]
resourcesConsumed: { cpuMs: number; memoryBytes: number; ioOps: number }
findings: GateFinding[]
}
signature: string // HMAC-SHA256 of evidence payload
previousCertificateHash: string | null // chain linkage
}
interface GateFinding {
severity: "info" | "warning" | "critical" | "blocking"
category: string
description: string
location?: { file: string; line: number; column: number }
recommendation: string
}4. サンドボックス検証: 妥協のない分離
パイプラインのステージ 3 では、生成されたツールが分離されたサンドボックスで実行されます。サンドボックスは、すべてのリソースへのアクセス試行をキャプチャしながら、本番環境を模倣する完全な実行環境を提供します。
サンドボックス アーキテクチャでは、次の 3 つの分離層が使用されます。
レイヤー 1: プロセスの分離。 このツールは、システム コールが制限された別のプロセスで実行されます。このプロセスにはネットワーク アクセスがなく、指定されたワークスペース外のファイル システム アクセスもありません。また、明示的な許可なしに子プロセスを生成する機能もありません。
レイヤー 2: リソースの割り当て。 CPU 時間 (デフォルト: 5 秒)、メモリ割り当て (デフォルト: 256MB)、および I/O 操作 (デフォルト: 1000 ops) に対するハード制限。制限を超えると、即時に終了します。
レイヤー 3: 機能インターセプト すべての API 呼び出しは、すべてのリソース アクセス試行を記録し、ツールの宣言された権限セットと比較する機能インターセプターを通じてプロキシされます。
interface SandboxConfig {
resourceBudget: {
cpuTimeMs: number // Hard CPU time limit
memoryBytes: number // Hard memory limit
ioOperations: number // Maximum I/O operations
networkCalls: number // Maximum network calls (usually 0)
}
permissions: {
allowedApis: string[] // Whitelisted API endpoints
allowedStateKeys: string[] // Accessible state keys
allowedFilePatterns: string[] // Glob patterns for file access
denyList: string[] // Explicitly blocked resources
}
monitoring: {
captureAllSyscalls: boolean
recordMemorySnapshots: boolean
traceApiCalls: boolean
escapeDetectionEnabled: boolean
}
}
class ToolSandbox {
async execute(
tool: GeneratedTool,
config: SandboxConfig,
testInputs: TestInput[]
): Promise<SandboxResult> {
const process = await this.spawnIsolated(tool.code, config)
const monitor = new ResourceMonitor(config.resourceBudget)
const interceptor = new CapabilityInterceptor(config.permissions)
for (const input of testInputs) {
const result = await process.run(input, {
monitor,
interceptor,
timeout: config.resourceBudget.cpuTimeMs,
})
if (interceptor.hasViolations()) {
await process.terminate()
return {
status: "permission_violation",
violations: interceptor.getViolations(),
forensics: await monitor.captureState(),
}
}
}
return {
status: "pass",
resourceUsage: monitor.getSummary(),
apiTrace: interceptor.getTrace(),
}
}
}サンドボックスエスケープ検出は、中央レイテンシー 23 ミリ秒、P99 48 ミリ秒で動作します。エスケープの試み (許可されたセット外のシステム コール、サンドボックス境界外のメモリ アクセス、またはネットワーク接続の試行) が検出されると、サンドボックスは直ちにプロセスを終了し、フォレンジック分析のために完全なメモリ ダンプをキャプチャし、ブロックされた結果をゲート証明書に書き込みます。
5. 権限昇格モデル: ラティスベースの権限境界
新しく生成されたツールは、それを作成したエージェント以上の権限を決して持ってはなりません。この原則 (権限上限) は、ツールの生成による権限昇格を防ぎます。
権限を格子 $(\mathcal{L}, \sqsubseteq)$ としてモデル化します。$\sqsubseteq$ は権限の順序を定義します。生成されたツールの権限セットは、生成エージェントの権限セットの下限である必要があります。
\forall T \text{ generated by agent } A: \quad P(T) \sqsubseteq P(A) \quad \text{(Authority Ceiling)}さらに、ツールは上限を超える権限を構成できません。権限 $P_1$ を持つツール $T_1$ が権限 $P_2$ を持つツール $T_2$ を呼び出す場合、呼び出しポイントでの有効な権限は次の条件に適合します (最大下限)。
P_{\text{effective}}(T_1 \circ T_2) = P(T_1) \sqcap P(T_2) \sqsubseteq P(A)これにより、ツール構成では権限を狭めることのみが可能になり、決して広がらないことが保証されます。格子構造には、次の 3 つの重要な特性があります。
1.単調な制限。 各構成ステップでは、権限セットを削減または維持することしかできません。一連のツール呼び出しは、元のエージェントの権限を超えてエスカレーションすることはできません。
2.決定可能な包含。 2 つの権限セットが与えられた場合、ソートされた権限ベクトルを比較することで、一方が他方に含まれるかどうかを $O(|P| \log |P|)$ 時間以内に決定できます。
3.監査の透明性。 ラティス構造により、権限関係が視覚的に検査可能になります。ラティス内での各ツールの位置は、他のすべてのツールと比較したそのツールの権限を完全に説明します。
interface PermissionLattice {
// Check if permission set A is dominated by B
isBelow(a: PermissionSet, b: PermissionSet): boolean
// Compute the meet (greatest lower bound) of two permission sets
meet(a: PermissionSet, b: PermissionSet): PermissionSet
// Validate that a tool's permissions respect the authority ceiling
validateCeiling(
tool: GeneratedTool,
generatingAgent: AgentIdentity
): {
valid: boolean
violations: PermissionViolation[]
effectivePermissions: PermissionSet
}
// Compute the transitive closure of tool composition permissions
compositionPermissions(
toolChain: GeneratedTool[]
): PermissionSet
}
type PermissionSet = {
read: ResourcePattern[]
write: ResourcePattern[]
execute: CommandPattern[]
network: NetworkScope[]
maxCpuMs: number
maxMemoryBytes: number
}6. ツール作成のための不変の監査証跡
すべてのツール生成イベントは、不変の監査レコードを生成します。監査証跡には、コンプライアンス (ガバナンス ゲートが遵守されたことの証明)、フォレンジック (生成されたツールに関連するインシデントの調査)、学習 (履歴パターンに基づいた生成パイプラインの改善) の 3 つの目的があります。
監査レコードは、各ゲート証明書がリーフ ノードであるマークル ツリーとして構造化されています。ツリーのルート ハッシュは、ツールの ガバナンス フィンガープリント です。これは、検証履歴全体に暗号的にコミットされる単一の値です。
H_{\text{root}} = H(H(G_1 \| G_2) \| H(G_3 \| G_4) \| H(G_5 \| H(G_6 \| G_7)))ここで、$G_i$ はステージ $i$ のシリアル化されたゲート証明書、$H$ は SHA-256 です。ゲート証明書を変更するとルート ハッシュが変更されるため、改ざんがすぐに検出可能になります。
interface ToolGenesisAuditRecord {
toolId: string
governanceFingerprint: string // Merkle root of all gate certificates
genesisTimestamp: string
generatingAgent: {
coordinate: string // MARIA coordinate (e.g., G1.U2.P3.Z1.A5)
permissionSetHash: string
}
pipeline: {
gateCertificates: ToolGenesisGateCertificate[]
totalDurationMs: number
resourcesConsumed: ResourceSummary
}
registration: {
registryVersion: number
previousToolVersion: string | null // for updates
rollbackToken: string // token to trigger automatic rollback
expiresAt: string | null // optional TTL for provisional tools
}
mariaCoordinate: string // where this tool is registered in the hierarchy
}監査レコードは追加専用であり、プライマリ データベース、イベント ログ、外部コンプライアンス アーカイブの 3 つのストレージ バックエンドにわたってレプリケートされます。この 3 重の冗長性により、単一のストレージ障害が発生しても監査データが存続することが保証されます。
7. ロールバックメカニズム: ツール登録の取り消し
登録されたツールは、実行時の監視、ユーザーレポート、または最新の安全性分析を通じて、後で安全でないことが判明する可能性があります。システムはツールの登録を完全に取り消し、システムを登録前の状態に復元できる必要があります。
ロールバックは、補償トランザクション パターンを通じて実装されます。登録時に、システムはツールの登録に必要なすべての状態の突然変異を記録し、それぞれに対応する補償突然変異を生成します。
interface RollbackPlan {
toolId: string
rollbackToken: string
compensatingActions: CompensatingAction[]
dependencyCheck: {
// Tools that depend on this tool
dependents: string[]
// Whether cascade rollback is required
cascadeRequired: boolean
// Estimated blast radius
affectedAgents: string[]
}
stateSnapshot: {
registryStateHash: string
toolConfigHash: string
permissionStateHash: string
}
}
interface CompensatingAction {
order: number
action: "deregister" | "restore_previous" | "cleanup_cache" |
"revoke_permissions" | "notify_dependents" | "archive_audit"
target: string
params: Record<string, unknown>
timeout: number
retryPolicy: { maxRetries: number; backoffMs: number }
}
async function executeRollback(plan: RollbackPlan): Promise<RollbackResult> {
// Phase 1: Dependency check — fail if cascade would affect critical paths
if (plan.dependencyCheck.cascadeRequired) {
const cascadeApproval = await requestCascadeApproval(plan)
if (!cascadeApproval.approved) {
return { status: "blocked", reason: "cascade_not_approved" }
}
}
// Phase 2: Execute compensating actions in order
const results: ActionResult[] = []
for (const action of plan.compensatingActions) {
const result = await executeWithRetry(action)
results.push(result)
if (result.status === "failed") {
// Partial rollback — escalate to human operator
await escalatePartialRollback(plan, results)
return { status: "partial", completedActions: results }
}
}
// Phase 3: Verify state matches pre-registration snapshot
const currentStateHash = await computeRegistryStateHash()
if (currentStateHash !== plan.stateSnapshot.registryStateHash) {
await escalateStateMismatch(plan, currentStateHash)
return { status: "verify_failed", stateHash: currentStateHash }
}
return { status: "complete", completedActions: results }
}ロールバック P99 の遅延は 340 ミリ秒で、5,000 件のロールバック イベントにわたって測定されました。この時間の大部分 (68%) は、実際の状態の変更ではなく、依存関係のチェックに費やされます。
8. 工具の安全性の正式な検証
パイプラインのステージ 5 では、正式な検証が実行されます。つまり、ツールが安全性特性を満たしていることをテストではなく証明します。制限付き実行では、ツールの安全性を一次式の充足可能性に還元します。
リソース予算 $B = (\tau, M, I)$ を持つツール $T = (C, P, S, E)$ の場合、検証条件 $\phi_T$ を構築します。
\phi_T \equiv \forall \vec{x} \in \text{Input}(T): \quad \text{Exec}(C, \vec{x}, B) \Rightarrow (\text{Access}(C, \vec{x}) \subseteq P) \land (\text{Effects}(C, \vec{x}) \subseteq E) \land (\text{Time}(C, \vec{x}) \leq \tau)検証条件は、すべての有効な入力について、コードが予算内で実行される場合、そのリソース アクセスは宣言されたアクセス許可に含まれ、その副作用は宣言された効果に含まれ、その実行時間は時間予算内にあることを示します。
SMT ソルバーによる有界モデル検査を使用して $\phi_T$ を放出します。制限付き実行の仮定により状態空間が有限になり、検証が決定可能になります。実際には、AST ノードが 500 未満のツールの検証は 2 秒以内に完了します (運用データで生成されたツールの 94% をカバーします)。
Formal verification proves safety within the bounded execution model. It does not prove safety for executions that exceed the resource budget. This is by design: executions that exceed the budget are terminated by the sandbox, so safety beyond the budget is enforced by runtime mechanisms rather than static proofs.9. 実行時監視: 登録後の監視
ガバナンスは登録だけでは終わりません。登録されたすべてのツールは、実行中に継続的に監視されます。実行時モニタリングは、正式な検証ではできない動作、つまり環境依存性、タイミングに敏感な相互作用、および段階的なリソースのドリフトを捕捉します。
監視システムは 4 つの信号カテゴリを追跡します。
| Signal Category | Metrics | Alert Threshold | Response |
|----------------|---------|-----------------|----------|
| Resource Consumption | CPU, memory, I/O per invocation | > 2x declared budget | Rate limit, then suspend |
| Permission Usage | API calls, state access patterns | Any undeclared access | Immediate suspend + audit |
| Behavioral Drift | Output distribution, error rates | KL divergence > 0.3 | Flag for review |
| Composition Effects | Cross-tool interaction patterns | New dependency detected | Integration re-test |ツール安全性インデックス (TSI) は、4 つの信号カテゴリすべてを 1 つのスコアに集約する複合ランタイム メトリックです。
\text{TSI}(T, t) = w_r \cdot R(T, t) + w_p \cdot P(T, t) + w_b \cdot B(T, t) + w_c \cdot C(T, t) \quad \in [0, 1]ここで、$R$ はリソース コンプライアンス (1.0 = 予算内)、$P$ は権限コンプライアンス (1.0 = 違反なし)、$B$ は動作の安定性 (1.0 = ドリフトなし)、$C$ は構成の安全性 (1.0 = 予期しない相互作用なし)、$w_r、w_p、w_b、w_c$ は合計が 1 になる重みです。0.85 未満の TSI は自動レビューをトリガーします。 0.60 未満の場合、自動停止がトリガーされます。
10. MARIA OS ツールのレジストリ アーキテクチャ
ツール レジストリは、MARIA OS のツール ライフサイクル管理の中心機関です。登録されているすべてのツールの正規の記録、そのガバナンスの来歴、実行時ステータス、および依存関係グラフが維持されます。
interface ToolRegistry {
// Registration
register(tool: VerifiedTool, certificates: GateCertificate[]): Promise<RegistrationResult>
deregister(toolId: string, reason: string): Promise<DeregistrationResult>
// Discovery
findTool(query: ToolQuery): Promise<RegisteredTool[]>
getToolByCoordinate(coordinate: string): Promise<RegisteredTool | null>
getDependencyGraph(toolId: string): Promise<DependencyGraph>
// Governance
getProvenanceChain(toolId: string): Promise<ToolGenesisAuditRecord>
getSafetyIndex(toolId: string): Promise<number> // Current TSI
getPermissionBounds(toolId: string): Promise<PermissionSet>
// Lifecycle
suspend(toolId: string, reason: string): Promise<void>
resume(toolId: string, approval: ApprovalRecord): Promise<void>
rollback(toolId: string, rollbackToken: string): Promise<RollbackResult>
// Analytics
getGenesisStats(timeRange: TimeRange): Promise<GenesisStatistics>
getFailureAnalysis(timeRange: TimeRange): Promise<FailureReport>
}
interface RegisteredTool {
id: string
name: string
version: number
coordinate: string // MARIA coordinate
code: string
permissions: PermissionSet
declaredEffects: Effect[]
status: "active" | "suspended" | "deprecated" | "rolled_back"
tsi: number // Current Tool Safety Index
registeredAt: string
registeredBy: string // Agent coordinate
governanceFingerprint: string
rollbackToken: string
invocationCount: number
lastInvokedAt: string | null
}レジストリは MARIA 座標系に従って編成されます。各ツールは特定の座標 (ギャラクシー、ユニバース、プラネット、ゾーン、エージェント) に登録され、その権限はその座標の権限に限定されます。ゾーン レベルで登録されたツールは、生成エージェントにクロスゾーン権限がある場合でも、別のゾーンに属するリソースにアクセスできません。
10.1 バージョン管理
ツールは再生成を通じて更新できます。更新されたツールは、新しいツールと同じ 7 段階のパイプラインを通過しますが、追加のチェックが 1 つあります。更新されたツールは、それに依存するすべてのツールと 下位互換性 がある必要があります。下位互換性は、新しいバージョンに対して依存ツールの統合テストを実行することによって検証されます。
下位互換性を維持できない場合、更新により カスケード再検証 がトリガーされ、すべての依存ツールが新しいバージョンに対して再検証されます。これにはコストがかかる可能性があるため、レジストリは、更新が開始される前にカスケード コストを予測する依存関係影響スコアを維持します。
11. ベンチマークと生産結果
私たちは、90 日間にわたる MARIA OS の実稼働展開における 10,000 のツール生成イベントにわたってツール生成フレームワークを評価しました。この展開には、12 のゾーンにわたる 847 のアクティブなエージェントが含まれていました。
| Metric | Value | Notes |
|--------|-------|-------|
| Total genesis events | 10,000 | Unique tool generation attempts |
| Stage 1 pass rate | 97.2% | Schema validation |
| Stage 2 pass rate | 89.1% | Static safety analysis |
| Stage 3 pass rate | 96.8% | Sandbox execution (of Stage 2 passes) |
| Stage 4 pass rate | 98.4% | Permission verification |
| Stage 5 pass rate | 93.7% | Formal safety proof |
| Stage 6 pass rate | 91.2% | Integration testing |
| End-to-end pass rate | 72.3% | All 7 stages passed |
| Safety compliance (registered tools) | 99.7% | No safety incidents post-registration |
| Mean pipeline latency | 4.2s | End-to-end for passing tools |
| P95 pipeline latency | 8.7s | End-to-end for passing tools |
| Rollback events | 31 | 0.43% of registered tools |
| Mean rollback time | 180ms | Time to complete rollback |
| P99 rollback time | 340ms | Worst-case rollback time |最も一般的な障害モードはステージ 2 (静的安全性解析) で、生成されたツールの 10.9% に潜在的な脆弱性としてフラグが付けられたパターンが含まれていました。これらの大部分は偽陽性 (推定偽陽性率 62%) でしたが、これは静的分析の既知の限界です。ただし、偽陽性 (再生成) のコストは偽陰性 (本番環境での安全でないツール) のコストよりもはるかに低いため、高い偽陽性率を受け入れます。
A 72.3% pass rate means 27.7% of generated tools are rejected by the governance pipeline. This is not a failure of the generation system — it is the governance system doing its job. The generating agent receives detailed feedback from the rejection and can re-generate an improved tool. On average, tools that fail on the first attempt pass on the second attempt 84% of the time.12. 結論: 統治された進化としての自己拡張
ツールの生成は、エージェント システムの自然な進化です。エージェントの能力が高まるにつれて、新しいツールを作成する能力が基本的な能力になります。抑制すべきバグではなく、管理すべき機能となります。
MARIA OS Tool Genesis Framework は、ガバナンスと自律性が緊張状態にないことを示しています。 7 ステージのパイプラインは、99.7% の安全性準拠を達成しながら、追加されるレイテンシのオーバーヘッドは 12% のみです。制限された実行下での形式的検証により、ツールの安全性が決定可能な問題になります。権限格子により、ツールの構成によって権限が狭まるだけであり、決して広がらないことが保証されます。不変の監査証跡により、すべてのツールの出所が検査可能になり、改ざんが明らかになります。自動ロールバックは、実験を安全にするセーフティ ネットを提供します。
アーキテクチャ上の重要な洞察は、ガバナンスにより自律性が可能になるということです。ツールを生成できる非統治エージェントは危険であるため、制限する必要があります。検証済みのパイプラインを通じてツールを生成する管理対象エージェントには、幅広い自由度が与えられます。これは、ガバナンス インフラストラクチャによって、どのツールもその限界を超えないことが保証されているためです。
これは MARIA OS のすべての基礎となる原則です。つまり、ガバナンスの強化により自動化が可能になります。ツールの生成では、この原則が最も強力に表現されます。このシステムは、ガバナンスの下で安全に拡張され、その際に危険性が高まることなく、より機能が向上します。
\lim_{n \to \infty} \text{Capability}(\text{System}_n) = \infty \quad \text{subject to} \quad \forall n: \text{TSI}(\text{System}_n) \geq \theta_{\text{safe}}自己拡張は危険ではありません。管理されない自己拡張です。違いはアーキテクチャです。