Protection Strategies

Quick summary

AUTO generates a supported partition, AGENT creates implementation handoff instructions, and MANUAL_REVIEW stops automatic changes.

Start with the decision table. Only apply approved plans whose source and specification hashes still match.

How a spec decides what happens to each asset — and what each decision actually produces.

Spec invariants — the closed registry

Specs may only reference invariant IDs from the closed registryexperiments/auto-protection/spec/invariants.json (registry_version: 1). Unknown IDs fail validation; REQUIRES_APPROVAL markers excepted. Each invariant maps to one of the analyzer's seven property verdicts (CODE_CONFIDENTIALITY, CODE_TAMPER_RESISTANCE, OFFLINE_CLONE_RESISTANCE, UNAUTHORIZED_EXECUTION_RESISTANCE, TOKEN_REPLAY_RESISTANCE, ORACLE_ABUSE_RESISTANCE, VERSION_ROLLBACK_RESISTANCE) — or null — and declares whether it requires_server (cannot be enforced client-side under the threat model).

Registered invariants include: unauthorized_execution_denied, fresh_input_offline_clone_denied, unauthorized_grant_denied, duplicate_consumption_denied, token_replay_denied, capability_single_use, version_rollback_denied, server_secret_custody, tenant_isolation, fail_closed_on_error — each with a required_evidence list (e.g. e2e:unentitled-request-denied, red-team:replay) that verification must produce.

A spec conflict — e.g. an asset claiming client authority while requiring enforcement on a server-requiring invariant — fails validation.

Decisions

Decision	Meaning	Apply output
AUTO	The partitioner can execute this asset mechanically.	Generated partition server + partitioned client + manifest.
AGENT	Needs agent-authored work — apply writes a handoff brief only.	Brief; no code produced.
MANUAL_REVIEW	A human must decide; apply skips it.	Nothing.

AUTO is degraded to AGENT when the estimated server calls per operation exceed constraints.max_server_calls_per_operation — batching/ caching design needed. Assets blocked by unresolved analysis gaps are forced to MANUAL_REVIEW (blocking_unknowns lists them).

What the partitioner emits (AUTO)

• A generated partition server importing the shared runtime/ — HTTP on loopback, endpoints registered per partitioned function, plus nonce-gated attestation counts and (dev-open only) /api/usage.
• A partitioned client keeping the module's public API.
• A manifest + sha256-recorded artifacts and a track-a-report.md.

The partitioner is refusal-first: a spec without a genuinely server-side keying story is refused rather than decorated — "partition without server-side keying is decorative" (spec/from-analysis.mjs notes; CANDIDATE_FOR_PARTITION alone proves nothing).

Auth modes for the generated server

Mode	Behavior	Use
dev-open	No auth. Opt-in, loopback only.	Local development.
yp-license	Entitlement JWS + DPoP proof per call (the licensing wire).	Real protection posture; requires --license-seed.

PARTITION_* env vars are the designed user→partition channel — generated servers read PARTITION_AUTH, PARTITION_DEV_OPEN, PARTITION_LICENSE_SEED, PARTITION_SECRET_* themselves (see Configuration).

Where strategies come from

• Track A (from-analysis.mjs): class-derived default invariants per analyzer verdict, always flagged in draft_notes as proposed — the generator never auto-asserts an invariant the analysis cannot support.
• Track B (from-requirements.mjs): authority, enforcement, and per-asset invariants are always REQUIRES_APPROVAL — they are product+security decisions, not derivable from requirements.