There is a strange pattern emerging in modern AI tooling.
We take probabilistic language models, connect them directly to terminals, cloud infrastructure, internal APIs, and production data, then try to control them with sentences like:
“Please don’t modify anything dangerous.”
That is not governance. That is wishful thinking wrapped around root access.
LLMs are excellent at reasoning. They are terrible at boundaries. And in production systems, boundaries are the only thing standing between automation and damage.
Contenox was built from a different premise:
An AI agent should be treated like an operating-system subject — constrained by explicit capabilities, enforced policy, and deterministic runtime behavior.
Not a chatbot with inherited authority.
Not a black box SaaS runtime.
Not a vendor-defined orchestration engine you cannot inspect.
Contenox is a local-first runtime for governing LLM execution through explicit policy, capability isolation, and declarative workflows.
A single Go binary. Your models, your chains, your policies, your infrastructure.
1. Prompts are hopes. Policies are firewalls.
A system prompt is not a security boundary.
This is the standard pattern today:
"You are a helpful assistant. Do not use sudo. Avoid sensitive files."
The model sees that instruction. It may even follow it.
Until it doesn’t.
Contenox moves authority enforcement out of the prompt and into the runtime itself.
[
{
"tools": "local_shell",
"tool": "local_shell",
"action": "deny"
},
{
"tools": "local_fs",
"tool": "*",
"action": "deny",
"when": [
{
"key": "path",
"op": "glob",
"value": "**/{.ssh,.gnupg,.aws,.env}/**"
}
]
}
]
The distinction matters.
A prompt is advice to the model.
A policy is enforced by the engine.
The model cannot negotiate with it, reinterpret it, or hallucinate around it.
If a tool call violates policy, the runtime refuses it mechanically.
Fail closed.
2. Cognition is cheap. Authority is precious.
The dangerous part of an AI agent is not the model.
It is the authority you accidentally hand to it.
Most frameworks expose your terminal, your API credentials, or your SaaS integrations directly to the model runtime. At that point the agent becomes a probabilistic extension of your own permissions.
One hallucinated command can become production damage.
Contenox rejects inherited authority entirely.
Instead of exposing “the CRM” or “the ERP,” you author a constrained tool surface:
- A curated OpenAPI subset
- Explicitly allowed operations
- Local credential binding
- Deny-by-default policy enforcement
The model never receives the underlying credential.
It cannot exfiltrate what it cannot read.
And if the schema only exposes:
GET /contacts
then:
DELETE /contacts
does not exist to the model at all.
Not hidden.
Not discouraged.
Absent.
You did not “grant access.”
You authored a capability.
3. Agent behavior belongs in Git. Not a black box.
Modern AI tooling often hides orchestration inside opaque runtimes:
- hidden prompts
- undocumented retries
- proprietary planning heuristics
- silently changing behavior
That is tolerable for chat applications.
It is unacceptable for infrastructure.
In Contenox, agent behavior is declarative infrastructure:
- model selection
- system prompts
- retries
- transitions
- branching logic
- pause conditions
- tool budgets
- approval behavior
- policy enforcement
All defined in chain files you own.
{
"id": "agent",
"tasks": [
{
"id": "chat",
"handler": "chat_completion",
"system_instruction": "You are an assistant running inside the user's tools.",
"execute_config": {
"model": "{{var:model}}",
"provider": "{{var:provider}}",
"tools": [
"*"
],
"retry_policy": {
"max_attempts": 4,
"initial_backoff": "1s",
"max_backoff": "30s"
}
},
"transition": {
"branches": [
{
"operator": "edge_traversed_at_least",
"edge": "chat->run_tools",
"when": "20",
"goto": "end"
},
{
"operator": "equals",
"when": "tool-call",
"goto": "run_tools"
},
{
"operator": "default",
"when": "",
"goto": "end"
}
]
}
},
{
"id": "run_tools",
"handler": "execute_tool_calls",
"input_var": "chat",
"transition": {
"branches": [
{
"operator": "default",
"when": "",
"goto": "chat"
}
]
}
}
],
"token_limit": 131072
}
You version it in Git.
You review it in pull requests.
You diff changes like any other production artifact.
Vendor updates do not silently rewrite your automation behavior upstream.
The runtime stays predictable because the behavior definition belongs to you.
Explicitness beats magic.
4. A hard deny is stronger than a soft ask.
“Human in the Loop” systems sound reassuring until you use them long enough.
Eventually every approval prompt becomes muscle memory.
Click.
Approve.
Click.
Approve.
Click.
Production incident.
Contenox treats autonomy and safety as competing forces, not marketing slogans.
So the runtime operates differently depending on the trust profile.
Interactive Mode — The Owner
Inside Zed, JetBrains, or AionUi, Contenox routes approvals through the editor’s own permission system.
You define:
- what is always allowed
- what is always denied
- what requires approval
The runtime pauses exactly where your chain says it should pause.
Autonomous Mode — The Driver
In environments where the user is not the owner of the host or infra execution is different!
There is no trusted human sitting at the keyboard.
So there is no fallback approval prompt.
Everything is deny-by-default.
Wire in a new MCP server or API and it is still denied automatically.
No implicit trust.
No inherited capability.
No “the model probably won’t do that.”
Until you explicitly allow the tool in policy, the runtime refuses access mechanically.
Registering a tool does not grant authority to use it.
That distinction is the difference between orchestration and governance.
The Anti-Black-Box Runtime
Contenox is not trying to be an AI companion.
It is not trying to replace your judgment.
It is not trying to become an omniscient autonomous employee.
It is infrastructure.
A programmable runtime that:
- pipes inputs
- enforces policy
- governs capabilities
- executes deterministic workflows
- runs locally
- speaks open protocols
- works with any model provider — or none at all
GGUF via the built-in engine.
or pick
Ollama.
or
OpenAI.
or
Gemini.
or
vertex ai
or
vLLM.
and
aws bedrock is coming soon.
Your own cluster.
Your own choice or own hardware.
Your own chain files.
Your own policies.
The runtime is replaceable.
The models are replaceable.
The governance stays yours.
Contenox is open source under Apache 2.0.
Install
curl -fsSL https://contenox.com/install.sh | sh
Then:
contenox init
contenox model pull gemma4-e4b # https://contenox.com/docs/guide/local-models/
contenox "say hello world in python"
No SaaS runtime required.
⭐ GitHub: https://github.com/contenox/contenox
📖 Docs: https://contenox.com/docs/
🔌 Zed Guide: https://contenox.com/docs/guide/zed/
If you believe AI agents should not inherit authority by accident, welcome to Contenox.
Top comments (1)
Finally. Someone said it: governance is not a prompt. It's a runtime gate. We built exactly that deterministic enforcement before execution, not polite requests to the model. Same diagnosis. Deeper engineering.