Developer Integrations — Product Capability Brief

This brief defines the canonical Developer Integration experience: how a developer installs Agent Assembly protection into an AI development tool, what protection they get, what they provably do not get, and how the experience fails. It is the product-level source of truth that the lifecycle contract (AAASM-5277), the plan/receipt/rollback model (AAASM-5278), the local integration API (AAASM-5279), the CLI surface (AAASM-5280) and the Claude Code productization (AAASM-5281) all implement against.

Status: product definition. Behaviour described here is either (a) grounded in code that exists today and cited as such, or (b) explicitly marked planned with the ticket that builds it. Nothing here should be read as a shipped capability unless it is cited to code.

This document deliberately does not fill in the Claude Code row of the L0–L3 Capability Matrix. That row was filled by AAASM-5284 from the AAASM-5276 evidence and is canonical there, not here.

1. Purpose and scope

Why this document exists

The dev-tool governance work to date is organised around technical primitives: the DevToolAdapter trait, per-tool adapter crates, the aasm run launcher, the gateway and the proxy. Those primitives are necessary but they are not a product. A developer cannot currently answer three questions without reading source code:

1. What do I run to become protected?
2. How do I know protection is actually on, as opposed to merely configured?
3. What is still able to leak?

Every one of those questions is a product question with a security consequence. Answering them inconsistently per tool is how a governance product ends up over-claiming. This brief fixes the answers once, at the product layer, so that every tool integration either implements them or declares the gap explicitly.

The thin-surface principle

Plugins, extensions and installers are thin integration and UX surfaces. The security core — policy evaluation, sensitive-data detection, redaction, approval, and audit — lives in Agent Assembly and is never reimplemented inside a plugin.

This is a security boundary, not a code-organisation preference. A plugin runs inside a host process that the user (and the agent under governance) can influence: it can be disabled, downgraded, or fed a tampered configuration. If a plugin decided whether a secret may leave the machine, the enforcement decision would sit inside the thing being governed. Instead:

A corollary the whole document depends on: an integration surface may never be the source of a protection claim. It reports what the core observed; it does not assert protection on the core’s behalf.

In scope

• The persona set, entry points and end-to-end journey every tool integration must support.
• The user-visible protection profiles and protection levels, with testable definitions.
• Truthful guarantee and limitation copy, reusable verbatim by the CLI, a future UI and public docs.
• The MVP boundary and the non-goals that must not be quietly re-entered.
• The acceptance-test scenarios the AAASM-5276 Spike is expected to satisfy.

Out of scope

• Choosing the IPC transport between an integration client and the core (AAASM-5279).
• The concrete API/trait shape of the lifecycle contract (AAASM-5275, AAASM-5277).
• Implementing any CLI or plugin UI (AAASM-5280, AAASM-5282).
• Per-tool tier declarations — those belong in the L0–L3 Capability Matrix.

2. MCP is one optional tool capability, not the plugin architecture

MCP is not the integration mechanism, and no integration is required to use it. “Plugin” here is a product and distribution concept — the thing a developer installs. MCP is one of several mechanisms an integration may drive, and for several tools it is not the most useful one.

Conflating the two is a live risk because the word “plugin” is overloaded by the tools themselves. The concrete failure mode it would cause: designing the lifecycle around an MCP server would make protection depend on the agent choosing to call a tool — an agent-cooperative design, which is exactly the property enforcement must not have.

The mechanisms an integration may use, and what each is good for:

Read the table by the last column. The mechanisms that produce a real guarantee are the ones the governed agent cannot decline. MCP appears twice, and only its loading control half is non-cooperative — which is why MCP is classified as optional, defence-in-depth, never as a required substrate.

3. Personas and entry points

Four personas. They differ less in what protection they need than in what they must never be required to understand — which is the constraint that actually shapes the product. The “must not have to understand” column is therefore normative: if an integration forces a persona to learn one of those concepts, the integration has failed for that persona regardless of whether protection works.

3.1 Individual developer (local)

3.2 Team developer (org-managed policy)

3.3 CLI-first user

3.4 IDE / plugin-first user

3.5 What is common to all four

Every persona shares one requirement: the difference between “configured” and “protected” must be visible in the product, not only in the docs. That single requirement is what §7’s entry criteria and §11’s acceptance scenarios exist to enforce.

4. The canonical journey

Every tool integration implements the same nine stages. A tool that cannot support a stage declares it unsupported rather than skipping it silently — a skipped stage is indistinguishable from a broken one, and the failure surfaces later as an over-claimed protection level.

Discover → Install → Connect → Choose profile → Apply → Verify → Use → Diagnose/Repair → Remove

The stage order encodes one deliberate decision: Verify comes after Apply and before Use, and it is the only stage permitted to raise the displayed protection level. Apply changes configuration; only Verify produces evidence that protection was exercised. Everything in §7 follows from that split.

4.1 Discover

4.2 Install

4.3 Connect

4.4 Choose profile

4.5 Apply

4.6 Verify

4.7 Use

4.8 Diagnose / Repair

4.9 Remove

5. Journey diagrams

Both entry points drive the same lifecycle against the same core. They differ only in where the user stands and how status is surfaced. That is the point of the diagrams: if the two paths could reach different protection outcomes, the integration surface would be making security decisions, which §1 forbids.

5.1 CLI-first onboarding

flowchart TD
    classDef user fill:#e8f1ff,stroke:#5b8def
    classDef core fill:#eaf6ee,stroke:#3aa55b
    classDef check fill:#fff3d6,stroke:#c98a00
    classDef bad fill:#fdecea,stroke:#d75748

    U0["Developer runs<br/>integrations install &lt;tool&gt;"]:::user --> D["Discover:<br/>detect tool + version + config scopes"]:::core
    D -->|not found / below minimum| E1["Report unsupported<br/>no changes made"]:::bad
    D -->|supported| C["Connect:<br/>find or start core, health + version check"]:::core
    C -->|unreachable| E2["Fail closed:<br/>abort install, nothing written"]:::bad
    C --> P["Choose profile<br/>(default: Recommended)"]:::user
    P --> PL["Compute integration plan<br/>show diff of intended changes"]:::core
    PL --> A["Apply transactionally<br/>+ write receipt"]:::core
    A -->|write fails| RB["Roll back to pre-apply state<br/>report NOT installed"]:::bad
    A --> V{"Verify"}:::check
    V --> V1["Read back managed values<br/>vs plan"]:::core
    V --> V2["Exercise synthetic secret<br/>through model-bound path"]:::core
    V1 --> LV{"Evidence<br/>sufficient?"}:::check
    V2 --> LV
    LV -->|read-back only| LI["Level: Integrated"]:::core
    LV -->|protection exercised| LG["Level: Gateway Protected"]:::core
    LV -->|secret escaped| E3["HARD FAIL<br/>report unprotected"]:::bad
    LI --> USE["Use tool normally"]:::user
    LG --> USE
    USE --> ST["status / verify on demand"]:::user
    ST -->|drift found| REP["repair:<br/>re-apply AASM-owned values only"]:::core
    REP --> ST
    ST -->|done with it| RM["remove:<br/>restore from receipt"]:::core

5.2 Plugin / extension-first onboarding

The plugin never decides anything. Every arrow that crosses into the core is a request for a verdict or for evidence; every status the plugin renders is something the core told it.

sequenceDiagram
    autonumber
    actor Dev as Developer
    participant Plug as Plugin / extension<br/>(thin surface)
    participant Core as AASM core<br/>(gateway + runtime)
    participant Tool as AI dev tool

    Dev->>Plug: Install / enable the plugin
    Plug->>Core: Discover core (running? version compatible?)
    alt core missing or incompatible
        Core--xPlug: unavailable
        Plug-->>Dev: Show "Not protected" + one recovery action
        Note over Plug,Dev: Never shows a green state on a<br/>failed core handshake
    else core ready
        Core-->>Plug: ready (version, endpoint, org/team if any)
        Plug->>Core: Request integration plan for this tool
        Core-->>Plug: Plan (files, keys, env to be changed)
        Plug-->>Dev: Show plan + profile choice
        Dev->>Plug: Confirm profile
        Plug->>Core: Apply plan
        Core-->>Plug: Receipt (change inventory + hashes)
        Plug->>Core: Verify
        Core->>Tool: Launch through managed path
        Tool->>Core: Model-bound request containing synthetic secret
        Core-->>Tool: Redacted payload with placeholder
        Core-->>Plug: Verification record (mechanisms exercised vs read back)
        Plug-->>Dev: Protection level + profile + honest limits
    end

    loop Normal use
        Tool->>Core: Governed actions
        Core-->>Core: Evaluate policy, scan, redact, audit
        Core-->>Plug: Status changes (protected / degraded / off)
        Plug-->>Dev: Update indicator
    end

    Dev->>Plug: Remove
    Plug->>Core: Remove using receipt
    Core-->>Plug: Pre-install state restored
    Plug-->>Dev: Confirm removal (no AASM residue)

6. Protection profiles

A profile is a named bundle of concrete core settings, not a mood. Every profile below is defined by the five things a user can actually observe a difference in: the EnforcementMode, what happens to a sensitive-data finding, the approval posture, the network-egress posture, and what the user sees. Adjectives like “balanced” or “maximum” are deliberately absent — if a profile cannot be distinguished by one of those five columns, it should not exist.

EnforcementMode (aa-core/src/policy.rs) has exactly three values, and only two of them are reachable from a profile:

6.1 Profile definitions

6.2 Rules that bind all profiles

• Observe only must never be displayed as protection. Status output for Observe only says monitoring, and any protection level shown alongside it is annotated as not enforced. This is the single most likely place for the product to accidentally lie.
• Org policy clamps the profile. Profiles resolve into policy inputs that merge with the org cascade under most-restrictive-wins. A local profile can tighten; it can never loosen. Choosing Observe only on an org-managed machine whose policy is Enforce yields Enforce, and the UI says why.
• A profile never changes what is detected — only what is done about it. Detection and audit run identically across all three, which is what makes Observe only a usable dry run for Recommended.
• Switching profile is not a reinstall. It re-resolves policy inputs; managed settings that encode policy are re-applied through the same plan/receipt path so drift detection stays valid.

7. Protection levels

A profile is what the user chose. A level is what the system can prove it is currently doing. They are separate because a user can choose Strict on a machine where the tool is not routed through the gateway — and the honest answer there is Integrated, not Strict protection active.

The reported ladder has six rungs — Not Installed, Detected — Not Integrated, Partially Integrated, Integrated, Gateway Protected, Host Enforced (aa-core/src/integration/state.rs; the vocabulary clients must use verbatim is in protection levels). The three below Integrated say how far an install got and make no protection claim, so they need no entry criteria. §7.1–§7.3 below specify the three rungs that do claim something, which is why the rest of this section counts three.

The governing rule: the existence of a configuration file is never sufficient evidence for a protection level. Configuration expresses intent. A level is a claim about behaviour, and a claim about behaviour requires an observation of behaviour. Every entry criterion below is written to be executable by a test, which is why §11 can assert against them directly.

7.1 Integrated

7.2 Gateway Protected

7.3 Host Enforced

7.4 Level reporting rules

• Report the highest level whose criteria are currently met, and re-evaluate rather than cache. A level earned at install time is not still true after the core stops.
• Report the mechanisms behind the level, split into “exercised” and “read back”. A user who can see which is which can reason about their own risk; a user shown a single word cannot.
• Always report the next level up and why it is not active. The status renderer does this twice over: the ladder lists every rung, and a separate Next level up: line carries the service’s reason for the rung immediately above the one achieved. Whether a rung can be reached at all is the adapter’s answer, never the client’s: aa-cli reads host_enforced reachability out of the adapter’s declared capability support (aa-cli/src/commands/integrations/model.rs), and distinguishes three states — available (a path exists; the limitation names the command that takes it), unsupported (the adapter said no, and its own reason is printed) and unmeasured (nothing was declared, so nothing is asserted in either direction). A client may not manufacture a claim about a platform it has not examined; before AAASM-5454 aa-cli hardcoded that rung unavailable and so told every macOS user — the one platform where the mechanism works — that it was impossible for them.
• Available is not achieved. A reachable rung still reports achieved: false until the evidence justifies it. Reachability is a statement about a path; the level is a statement about a measurement, and the two never substitute for one another.
• Degrade loudly. Losing a criterion mid-session drops the level and surfaces it. There is no state in which the level shown is higher than the evidence supports.

8. Product guarantees and their limits

The copy below is written to be used verbatim by the CLI, a future UI and public docs. Each guarantee is paired with its own limitation, and the two must always travel together — a guarantee quoted without its limit becomes an over-claim the moment it leaves this page.

Two words carry weight throughout and are used precisely:

• “supported path” — a path AASM actually observes: traffic through the managed launch and the gateway/proxy, from the governed tool, in the current session. Everything else is unsupported, which is not the same as unprotected-by-accident; it is out of scope by construction.
• “detected” — matched by the deterministic scanner’s pattern set. Detection is not comprehension. AASM does not claim to recognise every secret, only the shapes it knows.

G1 — Sensitive-data handling on supported model-bound paths

We guarantee: on supported model-bound paths, content is scanned before it leaves the machine, and every detected secret is replaced with a [REDACTED:<kind>] placeholder so the raw value is not transmitted. A field too large to scan reliably is replaced wholesale with [REDACTED:OVERSIZED] rather than forwarded — the scanner fails closed. A field that cannot be decoded as UTF-8 and carries a finding is likewise replaced wholesale, with [REDACTED:UNDECODABLE], because the secret cannot be excised precisely from bytes the scanner could only read through a lossy decoding. The agent still receives a semantics-preserving placeholder, so the request remains usable.

This does NOT guarantee: that every secret is found. Detection is deterministic and pattern-based (aa-security CredentialScanner), so a credential whose shape is not in the pattern set — a bespoke internal token, a secret with no distinguishing prefix, a value split across fields — passes through unrecognised. It also does not cover unsupported paths: a direct provider connection that ignores the managed proxy/base URL is never scanned. Redaction is not encryption and not a data-loss-prevention product.

G2 — Tool and action monitoring, and approval

We guarantee: governed actions from the managed tool are evaluated against policy before they take effect and are recorded in the audit log with agent attribution. Under an Enforce profile, a denial blocks the action and an action requiring approval halts until a human decides. With no applicable policy the system fails closed and denies.

This does NOT guarantee: that every action the tool takes is visible. Enforcement reaches the surfaces AASM manages; an action performed through a mechanism the tool does not route through those surfaces is neither seen nor blocked. Under an Observe only profile nothing is blocked at all — decisions are computed and audited, and the action proceeds. Approval coverage is bounded by what the tool’s own hook/callback surface exposes, which varies per tool and is declared in the capability matrix.

G3 — Local-only raw-content processing

We guarantee: scanning and redaction of your content happen locally, in the AASM runtime on your machine. Raw file contents and raw prompt text are not shipped to Agent Assembly infrastructure in order to be analysed.

This does NOT guarantee: that your content stays on your machine overall — the entire point of the tool is to send prompts to a model provider, and AASM’s job is to make what is sent safe, not to prevent sending. Nor does it guarantee that a future org-managed deployment transmits nothing: policy documents, audit metadata and decision records may be forwarded to a control plane where one is configured. Metadata is not raw content, but it is not nothing either.

G4 — Audit data minimisation

We guarantee: raw secret material is never written to AASM logs, traces, audit events, installation receipts, API responses or diagnostic output. Findings are recorded as metadata — kind, position, count — and the redaction record deliberately stores no raw value (aa-security/src/redaction.rs). Diagnostics intended for support are subject to the same rule.

This does NOT guarantee: that undetected secrets are absent from audit records. If the scanner did not recognise a value (see G1), that value was never classified as a secret and may appear in a recorded payload like any other content. Nor does it govern the tool’s own logs: Claude Code’s transcripts, your shell history and your provider’s server-side logs are outside AASM’s control entirely.

G5 — Drift detection and repair

We guarantee: the installation receipt records what AASM changed, so status can compare live state against it across every managed mechanism, report each difference, and re-apply only AASM-owned values. Where drift means protection is no longer active, the reported protection level drops.

This does NOT guarantee: real-time detection. Drift is found when status/verify runs, so a window exists between a change and its discovery. Repair is also deliberately narrow: AASM will not overwrite a key it does not own, even when that key is the cause — it reports and stops. Some drift is unrepairable in place (the tool removed the config surface, the tool’s schema changed) and requires a reinstall.

G6 — Removal and restoration

We guarantee: removal uses the receipt to restore the pre-install value of every managed key — restoring the original where one existed and deleting the key where none did — and removes only AASM-owned artifacts. Unrelated user configuration is preserved through the entire install→use→remove cycle, because AASM writes only its four managed keys and merges them over existing content with an atomic write (aa-devtool-claude-code/src/apply.rs).

This does NOT guarantee: restoration without a receipt. If the receipt is missing or corrupt, AASM refuses to guess and requires explicit confirmation rather than deleting on a hunch. It also does not undo changes AASM did not make: config the user edited after install is left as the user left it, and any change made by the tool itself is out of scope.

G7 — What we never claim

Stated positively so it can be quoted directly:

• We do not claim host-level bypass prevention. A user or process able to launch the tool outside the managed path is outside our enforcement, at every level available in this MVP.
• We do not claim protection for unmanaged direct provider connections.
• We do not claim complete secret detection.
• We do not claim protection while the core is stopped. Protection is a running-system property; when the core is down the product says not protected, not protection unknown.

9. Failure journeys

Default posture: fail closed. When AASM cannot establish that protection is active, it reports not protected and — where a decision is required — denies. The gateway already behaves this way: an empty policy cascade returns Deny { reason: "no policy — fail-closed" } rather than allowing (aa-gateway/src/engine/decision.rs).

Failing closed does not mean bricking the developer’s tool. The tool remains usable; what fails closed is the protection claim and any decision AASM is asked to make. The two exceptions below are marked explicitly, and both are exceptions in availability, never in claim: in both cases the product says it is not protecting.

9.8 Cross-cutting rules for every failure

• One cause, one action. Each message names what happened and the single next action. A failure message that offers three options is a message the user will ignore.
• Never green on a failed check. No failure path may leave a protection level displayed that its criteria (§7) no longer support.
• Diagnostics are subject to G4. Any diagnostic bundle produced during triage is scanned and redacted like any other output; troubleshooting is not an exemption from data minimisation.
• A bypass is not a failure. Launching the tool outside the managed path is reported as an unprotected launch, not as an AASM error — the distinction matters because the remedy is different and blaming the system trains users to ignore real failures.

10. MVP scope and non-goals

10.1 What the MVP is

macOS + Claude Code + the existing deterministic scanner + a local runtime/gateway.

That narrowness is the point. Proving one vertical slice end-to-end — install, verify with real evidence, use, detect drift, repair, remove — tells us whether the lifecycle works. Adding tools before the lifecycle is proven multiplies unvalidated surface by unvalidated tools, and the first honest failure would then be indistinguishable from an integration bug.

10.2 The model stays multi-tool

Restricting the MVP to one tool must not restrict the model to one tool. The following stay tool-neutral and are validated against the existing Codex / Copilot / Windsurf adapters as well: the nine-stage journey (§4), the three profiles (§6), the three claim-bearing protection levels and their entry criteria (§7), the guarantee set (§8), the failure taxonomy (§9), and the lifecycle contract those imply. Any design that can only be expressed for Claude Code is a design defect, and AAASM-5277 is where that is caught.

10.3 Explicit non-goals

Each of these is a thing someone will reasonably propose. Each is out of scope, with a reason — because “no” without a reason gets re-litigated.

11. Acceptance-test scenarios for the AAASM-5276 Spike

These are the scenarios the Spike must be able to execute and report on. They are written in Given/When/Then so they can be lifted directly into the Spike harness and, later, into the conformance suite (AAASM-5283).

Every scenario shares one design rule, and it is the reason the list exists at all:

A scenario passes on observed behaviour, never on the presence of configuration. Any assertion satisfiable by reading a config file is not an acceptance test — it is a read-back check, and §7 forbids raising a protection level on one.

Environment for all scenarios: macOS; a supported Claude Code release; a temporary repository; a local AASM core; a mock model provider endpoint that records every request body it receives; and a synthetic secret whose value matches the deterministic scanner’s pattern set and appears nowhere else on the machine.

11.1 Idempotent install

Given a machine with Claude Code installed and no AASM integration, When install is run and then run a second time with no intervening change, Then the first run produces an integration plan, applies it and writes a receipt; the second run reports no changes required, exits successfully, applies no additional mutation, and leaves the managed configuration and receipt byte-identical to the first run’s result.

11.2 Unrelated user settings preserved

Given a Claude Code settings file containing user-authored keys outside the AASM-managed set, and a snapshot taken beforehand, When install, verify, repair and remove are each executed in sequence, Then every unmanaged key retains its original value and ordering-independent content at every step, and after removal the file (or its absence) matches the pre-install snapshot semantically (accepted constraint C3 — restore is semantics-exact, not byte-exact).

11.3 Synthetic secret never reaches the model provider

Given a temporary repository containing the synthetic secret, an integration installed under the Recommended profile, and model traffic routed to the mock provider, When Claude Code is launched through the managed path and the secret-bearing content is caused to enter a model-bound context, Then the mock provider records at least one request (proving the path was actually exercised) and no recorded request body contains the raw synthetic value in any encoding the harness checks for.

Note: the “at least one request” clause is load-bearing. A test where no traffic reached the provider would also satisfy “no raw secret received” while proving nothing.

11.4 Agent still receives a usable placeholder

Given the conditions of 11.3, When the redacted request is delivered, Then the payload contains a semantics-preserving placeholder in place of the secret (the [REDACTED:<kind>] form), the surrounding content is otherwise intact, and the Claude Code session continues without error — demonstrating that protection does not break the tool.

11.5 Raw secret absent from audit, logs, traces and diagnostics

Given a completed run of 11.3, When the AASM audit events, application logs, traces, the installation receipt, the status and verify output, and any generated diagnostic bundle are collected, Then none of them contains the raw synthetic value, while the redaction finding metadata (kind and count) is present — proving the secret was detected rather than merely never seen.

11.6 Drift detected and repaired in at least two mechanisms

Given a verified installation, When two distinct managed mechanisms are perturbed independently — for example an AASM-managed settings key is edited by hand, and the proxy/gateway endpoint the integration injects is changed, Then status reports drift for both, naming expected versus actual per mechanism; the reported protection level drops before repair is attempted; repair restores only AASM-owned values; a subsequent verify re-exercises protection (not just read-back) and restores the level; and any user-authored key touched during the perturbation is left unmodified by repair.

11.7 Removal restores pre-install state

Given a snapshot of all affected configuration taken before install, When the full install → verify → use → remove cycle completes, Then every managed key is restored to its pre-install value — or deleted where none existed — no AASM-owned artifact remains, the post-removal state matches the snapshot semantically (accepted constraint C3 — restore is semantics-exact, not byte-exact), and Claude Code launches and operates normally afterwards.

11.8 Protection-level reporting distinguishes the three claim-bearing levels

Given three configurations — (a) managed settings applied but the tool never launched through the managed path, (b) a fully verified installation with protection exercised per 11.3, and (c) any installation on macOS, When status is invoked in each, Then (a) reports at most Integrated and explicitly does not claim sensitive-data protection; (b) reports Gateway Protected and names the mechanisms confirmed by exercise as distinct from those confirmed by read-back; and (c) in every case names Host Enforced rather than omitting it — with the reason it is not active on a default install, and with the caveat on what the attestation covers when an authorized managed-settings install has been verified.

11.9 Core stopped mid-session fails closed

Given a verified installation with an active Claude Code session, When the AASM core is stopped, Then the reported protection level drops to none within the product’s stated detection window, status says not protected (not “unknown”), and no output continues to display a protection level whose §7 criteria are no longer met.

11.10 Observe-only profile never reads as protection

Given an installation under the Observe only profile, When the conditions of 11.3 are repeated, Then the decision is computed and audited as a shadow event, the payload is forwarded unchanged (the mock provider does receive the synthetic value), and status describes the state as monitoring with a standing not-enforcing warning — never as protected.

Note: this scenario deliberately asserts that the secret does reach the provider. That is the correct behaviour for EnforcementMode::Observe, and asserting it is how the product proves its own honesty: the profile that does not protect must not be able to look like the one that does.

11.11 Unmanaged launch is reported as a bypass

Given a verified installation, When Claude Code is launched directly, outside the managed path, Then the session is not protected, and status reports an unprotected launch as a bypass rather than as an AASM failure — establishing that the product can distinguish “we are broken” from “you went around us”.

11.12 Scenario-to-criteria map

12. Assumptions register

The two tables below are deliberately separated. Accepted constraints are decisions already made — they are not open questions and should not be re-argued in implementation tickets. Assumptions requiring validation are beliefs this brief rests on that could turn out to be wrong; each names the ticket that would prove or disprove it. If one is invalidated, the corresponding section of this document changes rather than being quietly worked around.

12.1 Accepted constraints (decided — do not re-litigate)

12.2 Assumptions requiring validation

References

• L0–L3 Governance Capability Matrix — canonical tier definitions and per-tool declarations, including the Claude Code row.
• Onboarding a Developer Integration — the install → verify → operate → remove path with the commands and exit codes that exist today.
• Protection levels — §7 restated as an operational reference.
• Limitations and known bypasses — the demonstrated-versus-inferred bypass split and the other honest limits.
• Protection and enforcement — the policy pipeline, redaction semantics and fail-closed behaviour this brief’s guarantees rest on.
• Three-layer defense in depth — SDK / proxy / eBPF.
• aa-core/src/dev_tool.rs — GovernanceLevel (L0Discover … L3Native).
• aa-core/src/policy.rs — EnforcementMode (Enforce / Observe / Disabled).
• AAASM-5275 — plugin, adapter, lifecycle API and core-runtime boundaries.
• AAASM-5276 — Claude Code lifecycle Spike (consumes §11 of this document).
• AAASM-5277 … AAASM-5281 — lifecycle contract, plan/receipt/rollback, local integration API, CLI commands, Claude Code productization.
• AAASM-5284 — public onboarding, protection-level and limitation docs.

Last updated: 2026-08-03 by Chisanan232