Provider Context and Persistent-Memory Firewall

Prompt-first procedure: Describe the outcome you want in your agent conversation. The agent should select and load the appropriate AIWG assets, explain material changes, request any needed approval, and report verification evidence. Exact commands and flags appear only in the CLI reference.

AIWG inventories provider-facing context before it reaches an agent session. The firewall is a local, read-only gate: it measures context cost, compares deployed artifacts with current packaged sources, applies review trust labels, and flags instruction-poisoning signals without printing source contents.

Run the advisory scan from a project root:

Use AIWG to complete this documented outcome: Run the advisory scan from a project root
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Use strict mode in CI or before a sensitive run:

Use AIWG to complete this documented outcome: Use strict mode in CI or before a sensitive run
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

Strict mode exits non-zero for an over-budget context, stale deployment, quarantined or external input, changed reviewed content, or a missing review baseline. The default doctor check reports the same state as a warning so an operator can review and remediate it first.

What the Gate Measures

The report separates six contributions rather than presenting one opaque total:

Contribution	Budget treatment
`memory`	Counts provider memory and workspace orientation loaded into context
`rule`	Counts deployed rules loaded by a provider
`skill`	Counts listing metadata in the active budget; reports full bodies as potential on-demand context
`agent`	Reports bodies as potential subagent context, not startup context
`generated-bridge`	Counts generated provider bridge files
`project-local`	Counts `.aiwg/context`, `.aiwg/memory`, and operator workspace context

The portable default is 200,000 tokens with a warning at 60%. Override it for a known provider tier with `the budget-tokens option <n>` or doctor's `the context-budget-tokens option <n>`. A larger budget does not suppress stale or unsafe input findings.

For managed deployments, the report includes both deployed bytes and current packaged-source bytes. A manifest digest mismatch is labeled `stale`; it cannot be hidden by an unchanged total byte count.

Trust and Review

Every discovered file receives one trust label:

Label	Meaning
`user-authored`	Local operator content without a package provenance record
`generated`	Deployed content matches its package manifest or packaged source
`external`	A symlink leaves the project root; its target is not read
`stale`	Deployed bytes differ from the recorded or current packaged source
`quarantined`	Poisoning signals or an unreviewed digest change require review
`superseded`	The review baseline marks the file inactive

`quarantined` is a gate state, not a filesystem move. The scanner never deletes, rewrites, or follows an external link. Its JSON and text reports contain paths, digests, sizes, labels, and signal identifiers only—not matched content or file bodies.

After reviewing every reported file, create the digest baseline explicitly:

Use AIWG to complete this documented outcome: After reviewing every reported file, create the digest baseline explicitly
Have it inspect the current state, explain the plan, ask before material
changes, and report the result with verification evidence.

The plan is read-only and prints every record that would enter the baseline. Custom destinations use `the output option <project-relative-path>`. The writer rejects absolute, parent-traversal, and symlink-resolved destinations outside the project root, and replaces the baseline atomically only after the explicit confirmation.

The writer refuses to approve stale, quarantined, or external entries. Review a changed file, remove any injected instructions, then deliberately regenerate the baseline. To retire trusted content without deleting it, change that entry's `trust` value to `superseded` in the reviewed baseline.

Remediation

• Stale generated deployment: run the agent-owned refresh operation, then scan

again.

• Unneeded framework or addon: run the agent-owned remove operation, or redeploy only the

required set with the agent-owned use operation. Provider-scoped removal is not supported.

• Excess standing context: follow the context tier model

and move procedures or examples from Tier 1 rules/bridges into Tier 2 routing or Tier 3 on-demand skills.

• Skill listing pressure: use the provider-specific controls in the

skills budget guide. Increase a listing budget only where the provider supports it and only after narrowing unnecessary skills.

• Poisoning or changed memory: inspect the named local file, remove or rewrite the

unsafe instruction, review its provenance, and regenerate the baseline. Do not approve a baseline merely to clear the gate.

Use the json option for CI evidence and `the limit option <n>` to bound human-readable changed-file output. The fixture at `test/fixtures/context-memory-firewall` exercises malicious memory, changed reviewed memory, superseded context, and deployed/package drift.

This gate protects a single project checkout. Organization-wide policy, endpoint isolation, and provider-side session retention remain outside its scope.