AIR Handoff Card - Threat model & risk assessment

[eddlev]

AIR Handoff Card — Threat Model & Risk Assessment

Status: Disclosed for discussion · hardening under consideration Scope: the AIR_HANDOFF_CARD mechanism — creation, transport, and restoration Posture: produced under AIR governance (strict / resolve-early), VM4AI Date: June 2026

---

Summary

A handoff card is a complete, portable, resumable snapshot of a project's state, written as a single file and re-loadable in a new session — on any model — to continue work. That portability is the feature. It is also the risk: the same property that lets a project survive a context cap or move between models lets project state walk out of its access context cleanly, persist past the access that created it, and cross provider and jurisdiction boundaries with no control in the path.

This document states the threat model and the current gaps plainly, including the boundary the whole AIR project refuses to overclaim past: AIR is prompt-based. It has no backend, no cryptography, and no runtime. Every control a card carries is advisory. A cooperating model follows it; a malicious actor edits the card, ignores the rule, or scrapes the chat instead. AIR can reduce exposure. It cannot enforce.

This assessment is published openly because disclosing a known weakness is more honest than implying it does not exist.

---

1. What the handoff card is

The card is a single top-level JSON object (AIR_HANDOFF_CARD) derived from the live session. It captures project identity, the active contract and bound capability layer, the current active step and blockers, decision state, the onboarding answers, and the runtime law and architectural invariants needed to restore behavior. Re-uploading it in a new session (entry path Q1 = C) lets a model recognize the continuation and resume at the recorded step.

It is designed for two things: continuity across sessions (survive a dead or capped session) and portability across models (the project is not locked to one provider). Both are genuine values. Both are also the attack surface.

2. The honest core

The card carries no enforcement. Restoration depends on the next session loading it correctly, not on any layer that can compel behavior. The handoff-creation flow itself records that it is a prompt-side/runtime-surface control that "does not create backend validation." Stated plainly so expectations stay accurate: a determined insider is not stopped by anything the card says about itself.

3. Threat model

3.1 Insider exfiltration

Anyone who can run the session can already read everything in it, so the card is not a new way in. What it changes is the economics and the persistence of getting state out. It concentrates the whole project into one clean, complete, portable file — far lower friction than scraping a transcript, and more deniable ("it is just a save file"). Critically, it outlives the access that made it: revoke a person's access tomorrow and a card they exported today still resumes.

3.2 Cross-border / data-residency violation — highest severity

The card is built to travel across models and vendors. A card holding regulated or personal data, loaded into a third-party model hosted in another jurisdiction, is an uncontrolled cross-border transfer of that data. The feature is the violation vector.

This is made worse by an existing runtime rule (the model portability sovereignty rule), which states that AIR must not depend on a single provider, platform, deployment environment, jurisdictional access regime, or residency policy. That rule protects against vendor lock-in — a real value — but it normalizes cross-jurisdiction movement and has no counterbalancing residency control. The runtime encodes the portability side of the tension and is currently silent on the residency side.

3.3 Third-party processor exposure

Loading a card into any model sends its full contents to that provider's servers — a data-processing event with no data-processing agreement, no record, and no control in the path. Even absent a residency constraint, this is uncontrolled disclosure to a sub-processor the project owner never vetted.

4. Current state — what handoff creation does today

The only control on card creation is a completeness check: the Control Surface and the card template must be present in-session, or the flow fails closed and asks for the missing file. When both are present, the card is derived from the active session and written.

There is no content-sensitivity classification, no PII or secret detection, no redaction, no consent step describing what is being exported, and no residency check. The card captures full active state by default.

5. Gap analysis

Several of these map to schema fields that already exist but sit empty or inactive — anticipated, never wired.

| Gap | What exists today | What is missing

1 | Payload minimization is not the default | Source-reference machinery (task_source_references / REQUIRED_SOURCE) exists but is active: false and not wired into handoff | A pointer-by-default mode: carry state and references, not embedded sensitive payload
2 | No sensitivity classification / redaction | — | PII / secret / credential detection; omit-by-default; a redaction manifest
3 | No residency / transfer control | model_portability.jurisdiction_or_residency_constraints exists but is empty | Residency tagging; a cross-jurisdiction restore warning; reconciliation with the sovereignty rule
4 | No content-consent gate on export | Handoff is an AIR_GATE-able action; the gate checks completeness | A sensitivity gate: "this card will contain X — confirm export"
5 | No provenance | model_portability records current model fields | Creator, time, scope, and consent stamping for traceability
6 | No reuse binding or expiry | — | Optional scope-binding, expiry, or require-sources-to-resume
7 | Enforcement ceiling | All of the above are advisory | A layer that decides on the literal card bytes and can compel — which prompt-based AIR cannot provide

6. Risk ratings

• Gap 3 (residency) — highest severity. Regulatory exposure, and the runtime currently encourages the bad path.
• Gap 1 (pointer-not-payload) — highest leverage. The one mitigation that is genuinely real regardless of enforcement: you cannot leak what the card never contained. A leaked pointer-card's blast radius drops to metadata.
• Gap 7 — the honest boundary on everything else. Advisory controls reduce accidental over-capture; none bind a determined insider.

7. Mitigation directions (under consideration, not committed)

Genuinely effective — data minimization. Make pointer-by-default the handoff mode: the card carries state and source pointers, and resume requires re-providing the sources. This is half-advisory ("refuse to resume without the source") and half-real ("the secret was never in the card"). The real half is the valuable one.

Advisory hygiene — kills accidental over-capture, not a determined insider. Sensitivity classification with a redaction manifest; an export-consent gate; residency tagging with a cross-jurisdiction warning that reconciles the sovereignty rule ("portability is for the framework, not for residency-bound data"); provenance stamping.

Actual enforcement — a layer that can compel. Exporting a card is a payload-bearing write on a literal artifact. A fail-closed gate that decides on the actual bytes — classifying real content, redacting or blocking, requiring approval — is the only thing that can enforce any of the above. AIR generates the card; an enforcement gate governs whether and how it leaves. This sits outside prompt-based AIR by definition.

8. The honest one-line boundary

AIR can make the card carry less and warn loudly. Only an enforcement layer can stop it.

9. Disclosure and discussion

These gaps are disclosed openly and ahead of any fix. Hardening is under consideration; nothing here is a committed roadmap. Feedback, additional threat vectors, and real-world residency constraints are welcome — that input is what keeps the assessment honest.

If you are evaluating AIR for work that touches regulated or personal data: treat a handoff card as sensitive data at rest and in transit, do not place secrets or personal data in a project you intend to hand off without stripping them first, and be aware that loading a card into any model discloses its contents to that provider.