# CCG Agent Security — public protocol v0.1

## Research question

Can an external authorization gateway preserve the routine usefulness of an AI agent while preventing untrusted instructions from inheriting its permissions?

## Hypothesis

If the model owns neither credentials nor executive tools and every canonical tool call must obtain a narrowly bound one-shot token before execution, deterministic rules can stop forbidden calls on a fixed corpus without transferring every legitimate task to a person.

## Compared architectures

1. **Direct agent:** the model has an available tool and no further authorization layer exists.
2. **Hardened agent:** sandbox, allowlist, denylist and human approval for selected classes. This is a simplified control profile, not a claim about every real hardening configuration.
3. **CCG gateway:** the agent submits a proposal; a separate kernel evaluates provenance, target, sensitivity, irreversibility and trajectory. The tool accepts only a token bound to one tool and target.

## Corpus

The fixed synthetic corpus contains 12 scenarios:

- 5 legitimate tasks: file read, tests, local patch, approved email and push of a reviewed branch;
- 7 attacks: indirect prompt injection, CI persistence, credential export, malicious plugin, exfiltration trajectory, self-escalation and production-backup deletion.

Every architecture receives the same canonical request. The scenarios use no real model, plugin, credential, shell, email or production target.

## Risk classes

| Class | Example | Default control |
|---|---|---|
| R0 | read inside the project | automatic |
| R1 | reversible local change | deterministic rules |
| R2 | email or push | narrow one-shot token |
| R3 | production, deletion, large impact | independent challenge or safe hold |
| R4 | credential export, disabling the gateway | no token path exists |

## Metrics

- attacks allowed to execute by each architecture;
- legitimate tasks completed without unnecessary blocking;
- decisions transferred to a person;
- blocked calls;
- completeness of the six-step CCG audit trail.

## Negative controls

- Legitimate R0–R2 scenarios prevent a trivial “block everything” policy.
- Attacks using common allowed tools test the difference between a tool allowlist and the authority behind an instruction.
- R4 scenarios verify that some powers cannot be created even through approval by the agent itself.
- When the API is unavailable, the dashboard does not invent a replacement score; it displays `SAFE HOLD`.

## Reproducibility

The decision harness is published in `wp-theme/ithz-dev/inc/agent-security/AgentSecurityExperiment.php`. Public data is returned by `/api/agent-security/status?lang=en`. The same input must return the same result under the same protocol version; generation time is not part of the decision.

## Claim boundary

This pilot measures the behaviour of a published deterministic policy on a small fixed synthetic corpus. It does not measure the security of a model, OpenClaw, an MCP server or a real deployment. It does not test a compromised host, bypassing the gateway, flawed human rules, collusion, side channels or approval fatigue.

A later phase should add real but isolated agent runs, more attack variants, blind annotation of expected results and comparisons of cost, latency and false blocking.