Governing AI Agents: Why Contenox Treats LLMs as Operating-System Subjects

The Soul of Contenox: Stop begging the model. Start programming the runtime.

Contenox is a local-first runtime for governing LLM execution through explicit policy, capability isolation, and declarative workflows. Built as a single Go binary, it treats AI agents as constrained operating-system subjects rather than trusted employees with inherited authority.

Why This Matters

Current AI frameworks often connect probabilistic models directly to production terminals and internal APIs, relying on system prompts like ‘don’t modify anything dangerous’ for security. This approach fails because LLMs are excellent at reasoning but inherently terrible at maintaining boundaries, making them a liability in production environments. Contenox moves authority enforcement out of the prompt and into a deterministic engine that fails closed, ensuring that a model cannot negotiate or hallucinate its way around mechanical access controls.

Key Insights

• Policy as Firewalls: Unlike prompts which are merely advice, Contenox policies are enforced by the engine to mechanically block tool calls, such as denying access to .ssh or .env files via glob patterns.
• Capability Isolation: Contenox rejects inherited authority by exposing only curated OpenAPI subsets; if a DELETE operation is not in the schema, it is absent rather than just discouraged.
• Declarative Infrastructure: Agent behaviors, including retry policies and branching logic, are defined in JSON chain files that can be versioned in Git and reviewed via PRs (Alexander Ertli, 2026).
• Trust Profiles: The runtime supports ‘Interactive Mode’ for editor-integrated approvals and ‘Autonomous Mode’ which operates on a strict deny-by-default basis without human fallback.
• Model Agnosticism: The runtime remains predictable regardless of the backend, supporting GGUF, Ollama, OpenAI, Gemini, and vLLM while keeping governance logic local.

Working Examples

Enforcing mechanical security boundaries via policy files rather than system prompts.

[
  {
    "tools": "local_shell",
    "tool": "local_shell",
    "action": "deny"
  },
  {
    "tools": "local_fs",
    "tool": "*",
    "action": "deny",
    "when": [
      {
        "key": "path",
        "op": "glob",
        "value": "**/{.ssh,.gnupg,.aws,.env}/**"
      }
    ]
  }
]

Declarative chain definition for version-controlled agent behavior.

{
  "id": "agent",
  "tasks": [
    {
      "id": "chat",
      "handler": "chat_completion",
      "execute_config": {
        "model": "{{var:model}}",
        "retry_policy": {
          "max_attempts": 4,
          "initial_backoff": "1s"
        }
      }
    }
  ]
}

Practical Applications

• Use Case: Secure local development using Contenox within Zed or JetBrains to route tool approvals through the editor’s permission system. Pitfall: Relying on ‘Human in the Loop’ for every action often leads to muscle-memory approvals and subsequent production incidents.
• Use Case: Autonomous infrastructure drivers where every API call is denied by default unless explicitly authored as a capability. Pitfall: Granting agents full terminal access which allows one hallucinated command to exfiltrate credentials from the host.

References:

• https://github.com/contenox/contenox
• https://contenox.com/docs/
• https://contenox.com/docs/guide/zed/
• https://contenox.com/docs/guide/local-models/