Problem
When the sandbox supervisor proxies inference calls through inference.local, it emits NetworkActivityBuilder and HttpActivityBuilder OCSF events. These are generic network events with no AI-specific metadata. A security analyst sees "HTTP POST to inference.local" but not "agent called claude-opus-4 with 45K input tokens via anthropic provider."
OCSF v1.8.0 (March 2026) introduced the ai_operation profile specifically for AI/ML workload observability. No agent sandbox tool in the market emits these events today.
Why This Matters
Security analysts need to correlate AI model calls with network activity to detect patterns like:
14:32:07 - ai_operation: claude-opus-4, 45K tokens, anthropic provider
14:32:09 - NetworkActivity DENY: /usr/local/bin/claude -> pastebin.com:443
This pattern (large model call followed by exfiltration attempt) is invisible when inference calls are logged as generic HTTP traffic. The security team sees the blocked network request but has no context about what the agent was doing with the model right before.
In a PoC, a bridge was built that generates synthetic ai_operation events by detecting inference.local HttpActivity events and enriching them. A Splunk "Model Usage" dashboard showing model, tokens, provider, and latency was the most compelling part of the demo. But the events were synthetic, not native.
Proposed Solution
When the inference proxy in crates/openshell-supervisor-network/src/proxy.rs handles a request to inference.local:
- Parse the request body to extract
model name
- After proxying, parse the response body to extract
usage.prompt_tokens and usage.completion_tokens
- Emit an OCSF ai_operation event (class_uid 7001) with:
model: model name from request
provider: resolved upstream provider
input_tokens: from response usage
output_tokens: from response usage
latency_ms: request duration
sandbox_id: from SandboxContext
metadata.version: "1.8.0"
The event should flow through the existing OCSF pipeline (ocsf_emit!() macro -> OcsfShorthandLayer + OcsfJsonlLayer -> LogPushLayer -> gateway TracingLogBus).
OCSF ai_operation Profile Reference
From OCSF v1.8.0 schema:
- Class UID: 7001
- Category: AI/ML Operations
- Fields: model, provider, input_tokens, output_tokens, latency, operation_type (inference/embedding/fine-tune)
Scope
This covers inference calls through the inference.local virtual host only. The supervisor already sees every inference request/response for credential swapping (phantom token pattern), so the data is available without additional network interception.
Relates To
Competitive Context
No agent sandbox in the market produces OCSF events at all (E2B, Modal, Daytona all lack OCSF). Being the first sandbox with ai_operation events is a genuine differentiator for enterprise security teams evaluating agentic platforms.
Problem
When the sandbox supervisor proxies inference calls through
inference.local, it emitsNetworkActivityBuilderandHttpActivityBuilderOCSF events. These are generic network events with no AI-specific metadata. A security analyst sees "HTTP POST to inference.local" but not "agent called claude-opus-4 with 45K input tokens via anthropic provider."OCSF v1.8.0 (March 2026) introduced the
ai_operationprofile specifically for AI/ML workload observability. No agent sandbox tool in the market emits these events today.Why This Matters
Security analysts need to correlate AI model calls with network activity to detect patterns like:
This pattern (large model call followed by exfiltration attempt) is invisible when inference calls are logged as generic HTTP traffic. The security team sees the blocked network request but has no context about what the agent was doing with the model right before.
In a PoC, a bridge was built that generates synthetic ai_operation events by detecting
inference.localHttpActivity events and enriching them. A Splunk "Model Usage" dashboard showing model, tokens, provider, and latency was the most compelling part of the demo. But the events were synthetic, not native.Proposed Solution
When the inference proxy in
crates/openshell-supervisor-network/src/proxy.rshandles a request toinference.local:modelnameusage.prompt_tokensandusage.completion_tokensmodel: model name from requestprovider: resolved upstream providerinput_tokens: from response usageoutput_tokens: from response usagelatency_ms: request durationsandbox_id: from SandboxContextmetadata.version: "1.8.0"The event should flow through the existing OCSF pipeline (
ocsf_emit!()macro ->OcsfShorthandLayer+OcsfJsonlLayer->LogPushLayer-> gatewayTracingLogBus).OCSF ai_operation Profile Reference
From OCSF v1.8.0 schema:
Scope
This covers inference calls through the
inference.localvirtual host only. The supervisor already sees every inference request/response for credential swapping (phantom token pattern), so the data is available without additional network interception.Relates To
Competitive Context
No agent sandbox in the market produces OCSF events at all (E2B, Modal, Daytona all lack OCSF). Being the first sandbox with ai_operation events is a genuine differentiator for enterprise security teams evaluating agentic platforms.