OpenShell: Среда безопасности, стоящая за NemoClaw
Если NemoClaw — это стек безопасности, то OpenShell — его основа. Разработанный командой инженеров безопасности NVIDIA на протяжении последних 18 месяцев, OpenShell обеспечивает изоляцию на уровне ядра для выполнения ИИ-агентов — гарантируя, что даже полностью скомпрометированный агент не сможет получить доступ к ресурсам за пределами определённых границ безопасности.
Эта статья представляет собой техническое глубокое погружение в архитектуру OpenShell, механизмы изоляции и способы применения политик безопасности с минимальными накладными расходами на производительность.
Почему изоляция на уровне ядра?
Традиционная изоляция приложений — контейнеры, виртуальные машины, изоляция на уровне процессов — была разработана для программного обеспечения, которое ведёт себя предсказуемо. ИИ-агенты принципиально отличаются. Они генерируют собственные планы выполнения во время работы, совершают вызовы инструментов, взаимодействующих с внешними системами, и могут демонстрировать новое поведение, которое ни один набор тестов не предусмотрел.
Эта непредсказуемость требует модели безопасности, работающей на самом низком возможном уровне: уровне ядра. OpenShell перехватывает каждый системный вызов, совершаемый процессом агента, классифицирует его в соответствии с активной политикой безопасности и принимает решение о разрешении или запрете до того, как вызов достигнет ядра.
Agent Process
│
▼
OpenShell eBPF Layer ←── Policy Engine
│
├── ALLOW → System Call → Kernel
│
├── DENY → Error returned to agent
│
└── ESCALATE → Human approval queue
eBPF: Технология, стоящая за OpenShell
OpenShell построен на eBPF (extended Berkeley Packet Filter) — технологии ядра Linux, которая позволяет запускать пользовательские программы в пространстве ядра без изменения самого ядра. Команда NVIDIA разработала набор программ eBPF, специально оптимизированных для рабочих нагрузок ИИ-агентов:
Перехватчик системных вызовов
Перехватчик системных вызовов подключается к точке трассировки sys_enter и оценивает каждый системный вызов в соответствии с активной политикой:
// Simplified OpenShell eBPF syscall interceptor
SEC("tracepoint/raw_syscalls/sys_enter")
int openshell_syscall_enter(struct trace_event_raw_sys_enter *ctx) {
u32 pid = bpf_get_current_pid_tgid() >> 32;
struct sandbox_policy *policy = bpf_map_lookup_elem(&sandbox_policies, &pid);
if (!policy)
return 0; // Not a sandboxed process
long syscall_nr = ctx->id;
int decision = evaluate_policy(policy, syscall_nr, ctx->args);
if (decision == DENY) {
// Send event to userspace audit log
emit_security_event(pid, syscall_nr, DENY);
// Override return value to -EPERM
bpf_override_return(ctx, -EPERM);
} else if (decision == ESCALATE) {
// Pause the process and notify approval queue
emit_approval_request(pid, syscall_nr, ctx->args);
send_signal(pid, SIGSTOP);
}
return 0;
}
Защита файловой системы
Защита файловой системы ограничивает доступ агента к файлам и каталогам. Она работает на уровне операций VFS (виртуальной файловой системы), перехватывая вызовы open, read, write, unlink и rename:
# Filesystem policy for a customer support agent
filesystem:
# Agent can read its own configuration
- path: "/etc/nemoclaw/agent.yaml"
permissions: [read]
# Agent can read/write to its workspace
- path: "/var/nemoclaw/workspace/**"
permissions: [read, write, create]
# Agent can read shared data
- path: "/var/nemoclaw/shared/**"
permissions: [read]
# Everything else is denied by default
defaultAction: deny
Сетевой контроль
Сетевой контроль подключается к операциям с сокетами для управления сетевым доступом агента на уровне соединений:
SEC("cgroup/connect4")
int openshell_connect4(struct bpf_sock_addr *ctx) {
u32 pid = bpf_get_current_pid_tgid() >> 32;
struct network_policy *policy = bpf_map_lookup_elem(&net_policies, &pid);
if (!policy)
return 1; // Allow non-sandboxed processes
__be32 dst_ip = ctx->user_ip4;
__be16 dst_port = ctx->user_port;
if (!is_allowed_destination(policy, dst_ip, dst_port)) {
emit_security_event(pid, NETWORK_BLOCKED, dst_ip, dst_port);
return 0; // Block connection
}
return 1; // Allow connection
}
Архитектура применения политик
Политики OpenShell компилируются в байткод eBPF для максимальной скорости применения. Конвейер компиляции работает следующим образом:
- 1.Файлы политик YAML создаются командами безопасности в человекочитаемом формате
- 2.Компилятор политик преобразует YAML в промежуточное представление (IR)
- 3.Валидатор политик Nemotron проверяет IR на логическую согласованность и конфликты
- 4.Компилятор eBPF генерирует верифицированный байткод, который загружается в ядро
- 5.Верификатор среды выполнения проверяет, что программы eBPF завершаются и безопасны по памяти
Весь конвейер компиляции выполняется менее чем за 2 секунды для типичных наборов политик, и политики могут быть обновлены «на лету» без перезапуска агента.
# Compile and load a policy
nemoclaw policy compile policies/customer-support.yaml
nemoclaw policy load customer-support
# Hot-reload a modified policy (no agent restart required)
nemoclaw policy reload customer-support
# Verify policy is active
nemoclaw policy status
# Output:
# POLICY STATUS LOADED AT RULES
# customer-support active 2026-03-19 14:30:01 47
# network-default active 2026-03-19 14:30:01 12
# filesystem-strict active 2026-03-19 14:30:01 23
Процессы утверждения оператором
Одна из самых отличительных особенностей OpenShell — встроенная система утверждения оператором. Когда агент пытается выполнить действие, классифицированное как высокорисковое, OpenShell приостанавливает выполнение агента и направляет запрос на утверждение оператору-человеку.
Как работает утверждение
- 1.Агент пытается выполнить высокорисковый системный вызов (например, запись в защищённый файл, подключение к неодобренной конечной точке)
- 2.Программа eBPF OpenShell отправляет SIGSTOP процессу агента
- 3.Генерируется запрос на утверждение и отправляется через настроенный канал (Slack, Teams, PagerDuty, email)
- 4.Оператор рассматривает контекст запроса и одобряет или отклоняет его
- 5.При одобрении OpenShell отправляет SIGCONT для возобновления агента; при отклонении возвращает EPERM
Запрос на утверждение включает полный контекст:
{
"request_id": "apr-2026031914-00042",
"agent": "customer-support-agent-01",
"action": "email.send",
"target": "[email protected]",
"context": {
"ticket_id": "TKT-12345",
"customer_name": "[REDACTED]",
"reason": "Agent wants to send a follow-up email to the customer regarding their refund request",
"email_preview": "Dear Customer, your refund of $250 has been processed..."
},
"risk_level": "medium",
"policy_rule": "external-communication-requires-approval",
"timestamp": "2026-03-19T14:30:42Z"
}
Таймаут утверждения и действия по умолчанию
Операторы могут настроить поведение при истечении таймаута утверждения:
approvalConfig:
timeout: 15m
onTimeout: deny # deny | allow | escalate
onEscalate:
target: security-team
channel: pagerduty
maxPendingApprovals: 10 # Queue limit per agent
autoApprove:
# Automatically approve if the same action was approved
# 3 times in the past 24 hours for this agent
repeatThreshold: 3
repeatWindow: 24h
Характеристики производительности
OpenShell спроектирован для промышленных нагрузок, где задержка имеет значение. Вот измеренные накладные расходы на DGX Spark:
| Операция | Накладные расходы |
|---|---|
| Перехват системного вызова (разрешение) | 8 микросекунд |
| Перехват системного вызова (запрет) | 12 микросекунд |
| Проверка файловой системы | 15 микросекунд |
| Проверка сетевого подключения | 20 микросекунд |
| Обновление политики «на лету» | < 500 миллисекунд |
| Полный цикл утверждения (Slack) | 2–30 секунд (зависит от человека) |
Для сравнения: типичный вызов инференса LLM занимает 500–5000 мс, поэтому накладные расходы OpenShell незначительны в контексте рабочих нагрузок агентов.
Сравнение с существующими методами изоляции
| Функция | OpenShell | Docker/OCI | gVisor | Firecracker |
|---|---|---|---|---|
| Уровень изоляции | Ядро (eBPF) | Пространство имён | Ядро пользовательского пространства | microVM |
| Фильтрация системных вызовов | По политике, обновление «на лету» | Статический seccomp | Полный перехват | Полная изоляция |
| Сетевая политика | По агенту, L7-уровень | iptables | iptables | iptables |
| Утверждение человеком | Встроенное | Нет | Нет | Нет |
| Политики с поддержкой ИИ | Да (Nemotron) | Нет | Нет | Нет |
| Накладные расходы | ~10 микросекунд | ~5 микросекунд | ~50 микросекунд | ~100 мс при запуске |
| Проброс GPU | Нативный | NVIDIA CTK | Ограниченный | Ограниченный |
Ключевое отличие OpenShell в том, что он был разработан с нуля для рабочих нагрузок ИИ-агентов, со встроенной поддержкой политик на естественном языке, процессов утверждения человеком и оценки политик с GPU-ускорением.
Начало работы с OpenShell
OpenShell можно использовать автономно, без остального стека NemoClaw:
# Install OpenShell standalone
curl -fsSL https://github.com/NVIDIA/OpenShell | bash
# Create a minimal sandbox policy
cat > my-policy.yaml << 'EOF'
apiVersion: openshell.nvidia.com/v1
kind: SandboxPolicy
metadata:
name: my-first-sandbox
spec:
isolation:
network: restricted
filesystem: workspace-only
syscalls: minimal
EOF
# Run any process inside the sandbox
openshell run --policy my-policy.yaml -- python my_agent.py
OpenShell распространяется с открытым исходным кодом под лицензией Apache 2.0 и доступен по адресу nvidia/openshell на GitHub. В следующей статье мы рассмотрим реальные сценарии корпоративного развёртывания полного стека NemoClaw.