The model sees a tool and calls it
instruction→AI→tool
Maximum fluidity, but prompt injection can inherit the agent’s authority.
Agent without keys · security experiment
AI can have tools. It does not need the keys.
A public crash test compares a direct agent, common hardening and a CCG (Constitutional Capability Governance) architecture where the model only proposes a tool call and a separate kernel decides the permission.
12 synthetic scenarios · no real shell, email or credential · exactly reproducible result.
CCG Agent Security · public pilot
12 synthetic scenarios · 3 architectures · 0 real tools
The experiment in 20 seconds
Can AI have tools without owning the power?
We give the same request to three systems. A direct agent acts. A hardened agent uses a sandbox, allowlist and human approval. A CCG agent only asks for a one-shot permission.
The model proposes. Credentials and tools remain behind the gateway.Sandbox reduces reach, a person approves
AI→policy→approval
An essential defence. Frequent questions, however, create approval fatigue.
The agent does not own the key; it asks
AI→constitution→token / stop
Provenance, target, risk and trajectory are checked before the tool is reached.
Built-in crash-test result
Loading the deterministic benchmark…
The result belongs to this published policy harness. It is not a measurement of a real OpenClaw deployment or proof of complete security.
Whole-corpus comparison
What passed without being stopped
For attacks, lower is better. For legitimate tasks, higher is better.
Loading results…
Try one case
—
The same tool call, three boundaries of power
—
—
—
- Instruction provenance
- —
- Proposed tool
- —
- Target
- —
- Risk
- —
CCG audit
From untrusted text to a token — or a stop
The cost of control follows the risk
Not every file read needs five AIs
Control increases with reach, sensitivity and irreversibility.
Practical benefit
What changes when the agent has no keys
Prompt injection does not inherit a credential
What the agent does not physically possess cannot be exported by a text instruction alone.
Every permission has a small scope
A token is valid for one tool, target, purpose and short time — not an entire account.
Routine work stays fast
R0 and R1 use cheap deterministic rules; expensive challenge belongs at higher risk.
A decision can be explained afterwards
The audit preserves provenance, canonical tool call, rules, evidence and the kernel result.
The gateway can be portable
The same boundary can sit in front of OpenClaw, an MCP agent, a coding agent or an internal workflow.
Some powers simply do not exist
R4 does not have “very strict approval”. It has no token path at all.
Possible integration point
OpenClaw can call the gateway immediately before a tool
The before_tool_call hook can rewrite a call, block it or require approval. A strong CCG design needs one more boundary: credentials and executive tools must be owned by the gateway or a separate host, not by the agent itself.
OpenClaw→before_tool_call→CCG Gateway→narrow token→tool broker
The pilot measures a policy, not model intelligence
- The input is fixed. All three architectures receive the same canonical tool call.
- The result is reproducible. A published deterministic harness decides, not a random model response.
- Negative cases remain visible. Legitimate tasks protect usefulness; attacks test the security boundary.
Continue from the result to the evidence
The pilot measures a published policy on a fixed corpus. It does not yet demonstrate the security of a real agent.