Exec Primitive

An Exec Primitive is any path inside an AI agent's tool surface that reaches a shell call, subprocess spawn, or interpreted-code execution — system(), subprocess.Popen, child_process.spawn, Function(), eval, exec(), or any of their language-specific equivalents. The term covers the obvious cases (a tool that wraps bash) and, more importantly, the non-obvious ones: paths the operator did not explicitly model as exec but that nonetheless terminate at an interpreter call.

Non-obvious exec primitives are the principal source of OWASP ASI05 (Unexpected Code Execution) findings in production. The disclosed CVE record from 2025–2026 includes several worked examples: CVE-2025-59528 (Flowise CustomMCP) used Function() over unsanitised input — the operator wrote the integration as a "node configuration" feature without realising the configuration field reached an interpreter. CVE-2026-0755 (gemini-mcp-tool) passed user-supplied content directly to execAsync — the wrapper looked like a thin abstraction over an API call. Each is an exec primitive that the operator did not classify as one until the CVE was filed.

Why Enumeration Matters

The single most under-performed control against ASI05 is exhaustive enumeration of exec primitives in a deployment's full tool surface. Most teams can name the primitives they explicitly built. They cannot name the ones embedded in third-party packages, hidden in framework defaults, or composed across multiple tools that individually look like read or transform operations. Enumeration is the prerequisite for every other control — sandbox effectiveness depends on knowing which paths to wrap; argument validation depends on knowing which paths take user input; composition policy depends on knowing which combinations terminate at exec.

The enumeration process traces every tool's call graph from the agent-facing API down to any path that reaches a shell, spawn, or interpreter call. For each terminal call: what inputs influence the call? Where do those inputs come from? What sandbox or isolation layer wraps the call? What human checkpoint, if any, gates the call?

Defensive Patterns

Once enumerated, every exec primitive needs three layers of defence: a kernel-level sandbox (containers, seccomp, AppArmor/SELinux); strict allowlisting of inputs before the call (exact executable paths, schema-validated arguments, scoped environment-variable inheritance); and, for agent-generated code paths, a human-in-the-loop checkpoint between generation and execution.

For deeper guidance on how to enumerate and harden exec primitives in MCP-based deployments, see the OWASP ASI05 explainer and the MCP Security Audit service description.