Scope Security and Non Claims

Scope, Security, and Non-Claims

Scientific scope

CCR is a coordination and measurement runtime. Its protocol-relative ASI-proxy surfaces can evaluate whether a declared team forms checked, reusable capabilities under a declared resource envelope. They do not demonstrate real ASI, consciousness, generalized intelligence, or a real-world outcome.

Any measurement claim is conditional on its task manifest, evaluation design, resource envelope, baseline, sample requirements, score definitions, and verifier evidence. A source-checkout fixture is a test of protocol mechanics, not a general empirical benchmark result.

Explicit non-claims

CCR does not claim to:

• Detect or create real ASI.
• Self-modify models or update model weights.
• Grant authority or bypass safety controls.
• Treat external content as more than candidate evidence until it is checked.
• Settle a mission merely because PIC or another provider accepts an input.
• Execute imported safe_commands.
• Turn a cache hit, static workbench, provider registry, MCP descriptor, or A2A card into proof or authority.
• Treat settled=false as a failure of the runtime.

Core security model

The release review maps to NIST AI RMF and OWASP AI Agent Security controls. It is an engineering checklist, not a security certification.

Governance and measurement

• Keep human approver identity separate from worker identity.
• Name provider, verifier, scheduler, and integrator responsibilities.
• Keep non-claims visible in reports and documentation.
• Declare mission scope, authority scope, resource envelope, and hazard envelope.
• Classify external reports, prompts, MCP descriptors, A2A cards, and provider responses as untrusted inputs.
• Record correlation groups and do not turn unknown measurements into progress.
• Preregister a fixed-horizon or confidence-sequence design before measurement claims.

State integrity and execution control

• Preserve blocking residuals until independent artifact-bound review.
• Require task owner identity, fencing token, and idempotency key for completion.
• Bind operation approvals to plan, provider, config, scope, resources, expiry, nonce, and use count.
• Fail closed on provider-circuit, rollback, hazard, incident, and verifier gates.
• Document PostgreSQL delivery as at least once, not exactly once.

Network and agent-facing controls

• Use strict schemas, least privilege, allowlists, and bounded tool inputs and outputs.
• Require HTTPS, exact host allowlists, redirect denial, public DNS checks, and time/byte limits for network providers.
• Verify OIDC issuer, audience, expiry, and DPoP key, method, URI, token hash, time, and replay identifier.
• Exclude prompts, secrets, cookies, credentials, and PII-like fields from default telemetry.
• Preserve digest provenance for memory, packets, residuals, providers, and verifier artifacts.
• Never execute safe-command hints automatically.

Useful local review commands

uv run ccr audit repo --json
uv run python scripts/check_schema_registry.py
uv run pytest
uvx bandit -q -r src
uvx pip-audit
uv build
uv run ccr audit release --dist dist --json

These commands improve release evidence. They do not publish a package, execute a provider, dispatch an operation, or prove a physical outcome.

For the formal boundary around provider execution, see Operations and Authority. For sources, see References and Traceability.