AEF 1100: Threat Model

1. Status#

AEF 1100 v0.1 is an early draft and will change. It is the third document in the series and the first in the 1100 block.

AEF 1000 section 4 named seven adversary capabilities in a paragraph and pointed here for the full model. This document is that analysis. AEF 1000 remains the source of authority, and AEF 1001 supplies the vocabulary, which is used here exactly and not redefined.

Versions are dated, kept at their own paths, and recorded in CHANGELOG.md beside this document.

2. Why this document exists#

An evidence system is worth what its defeat surface says it is worth, and a reviewer who cannot see that surface cannot calibrate anything. Vendors omit theirs, which is why security claims about evidence systems tend to be unfalsifiable in the direction that flatters the vendor. This document states the defeat surface completely, in the same register as the claims, so that a reviewer weighing an aer knows what the record cannot tell them before they rely on it.

Most of the threats below are conceded. Section 15 gives the count. That is the intended outcome of an honest analysis rather than a defect in the framework, and it is the reason this document is more useful for what it concedes than for what it claims.

3. Normative language#

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174, and only when they appear in all capitals.

This document is largely non-normative. It analyzes threats and states dispositions. Requirements that follow from the analysis belong to AEF 1200 and AEF 1300, and where the analysis implies one, the implication is stated and pointed forward rather than imposed here.

4. The adversary#

The primary adversary is the operator. This is unusual, and it is the framework's central assumption, following AEF 1000 principle 2: verification must not depend on the operator, which is only a meaningful requirement if the operator is the party whose account is in question. Most threat models assume a trusted operator and an external attacker. This one does the opposite.

The assumed adversary is not malicious in the ordinary sense. The adversary wants a favorable account of work already done, and controls the systems that produced the record, which is the disposition of a normal institution under pressure rather than an intruder.

What the adversary can do. Control the execution environment completely. Configure, modify, or disable the capturing system before or during a run. Choose what the capturing system emits. Choose when to seal. Choose which records to retain and which to produce. Draw the declared scope. Select the approving signer. Supply the verifier. Control the clock, unless a time source outside its control is in use.

What the adversary is assumed unable to do. Obtain a valid seal for content it did not seal, or for a seal time it did not hold the key at. This is the boundary assumption of the entire framework, and it rests on the trust dependencies enumerated per threat below. Where key compromise breaks this assumption, section 12 states what follows.

Timing. The adversary acts both before and after the fact, and the asymmetry between those two is where the framework's entire value lives. Before seal time, the operator can shape the record nearly arbitrarily and almost nothing detects it. After seal time, the operator can delete or substitute a record wholesale but cannot alter it undetectably. The framework does not make the operator honest. It converts the operator's freedom from unlimited and invisible into bounded and dated.

Insiders and external parties. A party inside the operator acting against the operator is partially addressed, because the operator's own seals constrain that party the same way they constrain the operator. An external attacker with no operator privileges is largely OUT OF SCOPE, since AEF 1000 section 5 places security controls and identity infrastructure among the prerequisites the framework depends on and does not redesign.

5. How each threat is analyzed#

Each entry states the action a party takes, who can execute it, what in the aer detects it or the plain statement that nothing does, what the detection depends on with the failure consequence of each dependency per AEF 1000 principle 2, the residual risk after the defense, and a disposition.

Dispositions are IN SCOPE, meaning the framework defends against it; OUT OF SCOPE, meaning it is a prerequisite the framework depends on and does not redesign per AEF 1000 section 5; or CONCEDED, meaning it is within scope, undefended, and stated plainly.

6. Threats against the record#

6.1 Post-hoc alteration of a sealed record#

Action. The operator edits an aer after it has been sealed.

Who. Operator; implementer with storage access.

What detects it. The verifier. A seal binds the record's contents to a key, and altered contents fail verification. One flipped byte must fail.

What detection depends on. The signature scheme, in the FIPS 186-5 sense referenced by AEF 1001 section 5. If broken, forgery is undetectable and the framework collapses entirely. The key binding, meaning the reviewer's ability to establish that the verifying key belongs to the party claimed. If misplaced, the operator seals an altered record with a key it controls and the record verifies against the wrong key. The verifier's correctness. If wrong, alteration passes, which is section 11's subject.

Residual risk. The operator can alter the record and re-seal it, producing a valid record that differs from the original. Nothing in a single aer reveals that an earlier version existed. Detection requires an external index or a copy the reviewer already holds.

Disposition. IN SCOPE.

6.2 Selective deletion of entries within declared scope#

Action. The operator removes act log entries that fall inside the declared scope.

Who. Operator.

What detects it. After seal time, the verifier, because deletion is alteration. Before seal time, nothing. The record is emitted without the entries and is internally consistent.

What detection depends on. The same dependencies as 6.1, plus the location of seal time relative to the deletion.

Residual risk. Pre-seal deletion is complete and undetectable, and is indistinguishable from suppression at the source. The distinction between them matters for how an implementer builds and not at all for what a reviewer can conclude.

Disposition. IN SCOPE after seal time. CONCEDED before it.

6.3 Suppression at the source#

Action. The operator configures the capturing system not to emit a record of an act that falls within declared scope.

Who. Operator; implementer.

What detects it. Nothing. AEF 1000 section 4 states it plainly: an event never emitted leaves nothing to detect.

What detection depends on. Not applicable, since there is no detection.

Residual risk. Total with respect to the suppressed act. The aer remains complete in the sense AEF 1001 defines, because completeness is a claim about the declared scope and not about the run. A reviewer reading a conformant record has no signal that anything is missing.

Two things narrow the search without closing the gap, and both are reviewer procedures rather than properties of the record. The permission surface records what the agent could touch, and the gap between it and the act log is where an unrecorded act would have to live. Output artifacts are hash-bound, so an effect that landed in the world and appears in no record can be found by comparing the world to the record, if the reviewer can see the world independently.

Disposition. CONCEDED. This is the framework's largest single concession.

6.4 Truncation#

Action. The operator seals the record early, omitting acts that occurred later in the run.

Who. Operator.

What detects it. Nothing intrinsic to the record. A truncated aer is internally consistent and complete against a declared scope that ends where the record ends.

What detection depends on. Not applicable.

Residual risk. Total. Truncation is the cheapest of the pre-seal attacks because it requires no editing at all, only a decision about when to stop.

Implication for a later document. If declared scope were required to state a termination condition the verifier could check, truncation would become a detectable mismatch between the stated end and the recorded end. AEF 1300 should consider it.

Disposition. CONCEDED.

6.5 Reordering within the act log#

Action. The operator changes the order of entries before sealing, so that the sequence of acts misrepresents what preceded what.

Who. Operator.

What detects it. After seal time, the verifier. Before seal time, nothing, unless each entry binds the previous one so that order is part of what is sealed, or unless capture times come from a source the operator does not control.

What detection depends on. Entry chaining, if implemented. If absent, pre-seal order is the operator's assertion. An external time source, if in use. If the source is the operator's, recorded order and recorded time carry the same weight, which is none against a determined operator.

Residual risk. Ordering matters most where causation is in question, which is where a reviewer is most likely to care. Pre-seal reordering is undetectable absent chaining.

Implication for a later document. AEF 1300 should consider requiring act log entries to be chained.

Disposition. IN SCOPE after seal time. CONCEDED before it, absent chaining.

6.6 Replay against different work#

Action. The operator presents a genuine aer for one run as evidence about different work.

Who. Operator.

What detects it. Input state and output artifacts are bound to the record by cryptographic hash. A reviewer who holds the artifacts in question can compare hashes, and a replayed record fails to match.

What detection depends on. The reviewer's ability to obtain the artifacts from a source other than the operator. If the only source is the operator, the operator supplies artifacts that match the record it chose to supply, and replay succeeds completely.

Residual risk. Replay succeeds whenever the reviewer's knowledge of the work runs through the operator, which is the common case.

Disposition. IN SCOPE where the reviewer has an independent source for the artifacts. CONCEDED otherwise.

6.7 Substitution#

Action. The operator supplies a genuine aer for a different run in place of the one requested.

Who. Operator.

What detects it. Nothing, unless the reviewer can name the run they want independently of the operator's own index of runs. The framework proves things about records it is given. It says nothing about the population of records that exist.

What detection depends on. An external index, in the sense AEF 1000 section 4 uses when it notes that deletion of a whole record is not survived without one. AEF 1001 does not define external index, which is a finding recorded in section 16.

Residual risk. An operator asked for the record of a specific run selects which record answers the request. Every subsequent verification then proceeds correctly against the wrong record.

Disposition. CONCEDED in the general case. IN SCOPE where the reviewer can identify the run independently.

7. Threats against the boundary#

7.1 Adversarial scope declaration#

This is the threat the framework most deliberately does not prevent, and it deserves the fullest treatment, because AEF 1001 chose declaration over structural boundaries precisely on the grounds that declaration makes this visible rather than prevented.

Action. The operator declares a run boundary that excludes the work in question, then produces a record that is complete, conformant, and silent about it.

Who. Operator, since the declaration is the operator's by definition in AEF 1001 section 6.1.

What detects it. Nothing in the record. The aer is not defective in any respect. It is honest about a scope chosen to be uninformative.

What detection depends on. Not applicable.

Residual risk. Total with respect to the excluded work. A reviewer holding a verified aer and asking a question the declared scope does not reach gets a correct answer to a different question.

What declaration buys, stated precisely, because it is not nothing. The boundary is written down, dated, attributable to whoever declared it, and made before execution. That last property is the constraint. AEF 1000 principle 5 requires evidence to capture what was known at the time, and a boundary drawn to exclude a specific bad outcome must have been drawn before that outcome was known. An operator who narrows scope to hide a particular failure must therefore have anticipated it, which is a harder thing to do repeatedly than to do once. A reviewer with a series of declarations from the same operator can compare them, and a pattern of convenient narrowing is visible in a way that a structural boundary quietly re-architected is not.

That property depends entirely on the declaration actually preceding execution, which section 7.3 shows is not currently verifiable.

Implication for a later document. AEF 1300 will address boundary adequacy, which AEF 1001 open question 1 already records. Nothing in this analysis suggests adequacy can be made objective. It can plausibly be made comparable, which is a weaker and achievable goal.

Disposition. CONCEDED, deliberately.

7.2 Run splitting#

Action. The operator fragments one piece of work across many runs, so that no single aer describes it and no single aer is incomplete.

Who. Operator.

What detects it. Nothing within any record, by construction. Detection across records requires linkage between related runs, which nothing currently requires or defines.

What detection depends on. Not applicable at present.

Residual risk. Total. Run splitting is adversarial scope declaration applied serially, and it is worth stating plainly that declaration does not prevent it. AEF 1001 rejected structural boundaries on the grounds that splitting work across invocations defeats them. Splitting work across declarations defeats declaration in the same way. What differs is only that each narrow declaration is visible.

Implication for a later document. A linkage identifier joining related runs would make fragmentation visible as a shape rather than invisible as an absence. Linkage would itself be operator-declared and would inherit the same weakness, which is an argument for modest expectations rather than against the mechanism. AEF 1300.

Disposition. CONCEDED.

7.3 Scope amendment after execution#

Action. The operator revises the declared scope after seeing the outcome, and the record presents the revision as the original declaration.

Who. Operator.

What detects it. If the declaration is sealed and anchored before execution, amendment is alteration and is detected as in 6.1. If the declaration is captured only at seal time, which is the ordinary implementation, nothing distinguishes an original declaration from an amended one.

What detection depends on. Anchoring the declaration before execution against a time source outside the operator's control. If that anchor is absent, the requirement in AEF 1001 that a declaration precede execution is an assertion nobody can check.

Residual risk. This threat undermines section 7.1's only mitigation. Everything declaration buys rests on the declaration being made in ignorance of the outcome, and without pre-execution anchoring, a reviewer cannot establish that it was.

Implication for a later document. AEF 1400 will address time sources, and AEF 1300 will address whether a declaration must be separately sealed before a run begins. Until one of them does, AEF 1001's central defense against outcome-shaped boundaries is unverifiable.

Disposition. IN SCOPE where the declaration is anchored before execution. CONCEDED in the ordinary case.

8. Threats against the approval#

8.1 The approver is shown a different referent than the record claims#

Action. The approval record states what was in front of the approving signer. What was actually rendered to them differed.

Who. Operator; implementer.

What detects it. Nothing. AEF 1001 open question 3 records this as unresolved.

What detection depends on. Not applicable.

Residual risk. Total. AEF 1000 principle 6 holds that a signature requires a defined referent, and this threat means the referent is defined in the record rather than established by it.

Disposition. CONCEDED.

8.2 Collusion between operator and approving signer#

Action. The operator and the approving signer agree on an account that is false, and the record faithfully preserves it.

Who. Two coordinating parties, or one party holding both roles, which AEF 1001 section 7.1 identifies as collapsing the approval into a self-assertion.

What detects it. Nothing. AEF 1000 section 4 states the result: a faithful record of an approved lie.

What detection depends on. Not applicable.

Residual risk. Total. Where the roles are held by one party, AEF 1001 section 7.1 states that the combination MUST be visible in the aer, which lets a reviewer discount the approval accordingly. Disclosure is not defense, and nothing currently checks that the disclosure was made.

Disposition. CONCEDED.

8.3 Approval by a party without the standing or knowledge to approve#

Action. The operator routes approval to a person who cannot meaningfully evaluate the run.

Who. Operator.

What detects it. The aer records who approved and when. Whether that person was competent or authorized to approve is not in the record and is not derivable from it.

What detection depends on. Not applicable.

Residual risk. An approval record can be complete, verifiable, and worthless. This is a limit on the claim in AEF 1000 principle 6 that defining the referent makes sign-off meaningful. It makes sign-off checkable, which is less.

Disposition. CONCEDED.

9. Threats against the verifier#

9.1 A verifier that accepts what it should reject#

Action. The implementer ships a verifier with a defect, deliberate or otherwise, that passes records it ought to fail.

Who. Implementer. AEF 1001 section 7.1 notes that where the implementer of the agent system also authors the verifier, the verifier has no adversary in its history.

What detects it. Golden fixtures, in the sense AEF 1001 section 6.12 defines, including inputs that are required to fail.

What detection depends on. The adequacy of the fixture set. Nothing currently specifies adequacy, so a verifier can pass every fixture anyone wrote and fail on the case nobody wrote. If the fixture set is inadequate, the detection reports success and means nothing.

Residual risk. A verifier is credible to the extent it has rejected things, per AEF 1000 principle 4, and the population of things it has never been asked to reject is unbounded.

Implication for a later document. AEF 1201 will address how a verifier demonstrates that it verifies.

Disposition. IN SCOPE, weakly.

9.2 Golden fixtures with no required-to-fail cases#

Action. The implementer maintains a fixture set consisting only of records that should pass.

Who. Implementer.

What detects it. Inspection of the fixture set. AEF 1001 section 6.12 states that a fixture set MUST include inputs required to fail.

What detection depends on. Somebody inspecting. Nothing currently designates who, or where the inspection is recorded. Two honest readers can disagree about whether a fixture set is adequate with no way to settle it.

Residual risk. A verifier with a passing-only fixture set demonstrates that it accepts things, which was never in doubt.

Disposition. IN SCOPE nominally. Undefended in practice, and recorded in section 17.

9.3 Verifier substitution#

Action. The operator supplies the verifier, and the reviewer runs it.

Who. Operator.

What detects it. Nothing. The verification succeeds and reports what the operator's program reports.

What detection depends on. The reviewer obtaining a verifier independently.

Residual risk. This defeats AEF 1000 principle 2 directly, since verification then depends on the operator in the most complete way available. It is also the most likely real-world failure in this document, because it is the convenient path: the operator has a verifier, the reviewer does not, and running the supplied one is easier than building one.

Implication for a later document. AEF 1200 should require that a conformant verifier be independently obtainable and its build reproducible, so that a reviewer can run something whose provenance does not pass through the operator.

Disposition. CONCEDED until AEF 1200 addresses it.

9.4 Trust base substitution between verification and re-verification#

Action. A trust dependency is swapped between one verification and a later one, so that a record that verified before verifies now for different reasons, or fails for reasons unrelated to the record.

Who. Operator; whoever administers the trust dependency.

What detects it. Nothing, because a verification result does not currently record the trust base in force when it was produced.

What detection depends on. Not applicable.

Residual risk. Verification time is evidence that the record verified at that moment under the trust base then in force, per AEF 1001 section 9. If that trust base is not recorded, verification time is evidence of less than AEF 1001 claims, because the conditions of the check are unrecoverable.

Implication for a later document. A verification result should be a record naming its own trust base. AEF 1200, with the substance of what a trust base must contain in AEF 1101.

Disposition. CONCEDED.

10. Threats against keys and time#

10.1 Key compromise#

Action. A party other than the intended signer obtains the sealing key.

Who. Any party with sufficient access, including the operator asserting a compromise that did not occur.

What detects it. Nothing in an aer. After compromise, records sealed with that key are indistinguishable between genuine and forged, in both directions and for the entire history of that key.

What detection depends on. An independent key history establishing when the key was valid, and seal times anchored to a time source outside the operator's control. If either is absent, compromise reaches backward through every record the key ever sealed.

Residual risk. Records sealed before a compromise retain value only if seal time can be established independently. Absent that, a single compromise retroactively destroys an entire series, which is a large and underappreciated exposure.

Implication for a later document. AEF 1101 on establishing a key, AEF 1400 on anchoring seal time.

Disposition. IN SCOPE where key history and external seal time anchoring exist. CONCEDED otherwise.

10.2 Key rotation used to invalidate inconvenient history#

Action. The operator rotates keys and then declines to publish the retired public key, or asserts that the retired key was compromised, rendering earlier records unverifiable or repudiable at the operator's choosing.

Who. Operator.

What detects it. Nothing, absent an independent key history that records which keys were valid when, published somewhere the operator cannot retract.

What detection depends on. That key history. If it is the operator's, rotation becomes a repudiation tool, and the operator gains the ability to selectively unmake its own past attestations.

Residual risk. An operator that can repudiate history at will has an aer series worth nothing older than the current key.

Disposition. CONCEDED.

10.3 Operator-controlled time source#

Action. The operator supplies the clock that stamps capture time, seal time, and approval time.

Who. Operator.

What detects it. Nothing. Times are recorded and internally consistent.

What detection depends on. Not applicable.

Residual risk. All three times become the operator's assertion, and the record establishes ordering relative to itself and nothing about when anything happened. AEF 1000 section 4 already states that backdating is survived only against a time source the operator does not control.

Disposition. CONCEDED where the time source is the operator's. IN SCOPE otherwise, with AEF 1400 to state what otherwise requires.

10.4 Seal-time delay#

This threat did not appear in AEF 1000's list and the analysis surfaced it.

Action. The operator delays sealing, extending the window during which the record can be shaped.

Who. Operator.

What detects it. The gap between the earliest capture time and the seal time is visible in the record, so the window's size is apparent to a reviewer who looks. Nothing makes the window small.

What detection depends on. A time source outside the operator's control, without which both endpoints of the window are asserted and the gap can be reported as small while being large.

Residual risk. Every concession in section 6 grows with the length of this window, which gives an operator a single lever that widens the entire pre-seal defeat surface at once. An operator acting in bad faith seals as late as possible.

Implication for a later document. AEF 1400 should consider bounding the interval between capture and seal, and requiring the interval to be stated.

Disposition. CONCEDED. The window is visible; nothing constrains it.

11. Threats the framework depends on others to handle#

11.1 Selective non-production#

Action. The operator produces the aers that help and does not produce the ones that do not.

Who. Operator.

What detects it. Nothing within the framework. The records produced are genuine and verify correctly.

Residual risk. Complete, and it moots every defense in this document, since a defense that operates on records a reviewer never receives operates on nothing.

Why it is placed here rather than conceded. AEF 1000 section 2 identifies three conditions under which evidence requirements attach: a party able to detect harm, a party able to compel production, and production costing less than the harm. The framework addresses the third. Compulsion is the second and arrives from contract, examination authority, or a court, none of which a specification can create. Placing this OUT OF SCOPE is a claim about the division of labor rather than a dismissal, and section 18 records the argument that the placement is wrong.

Disposition. OUT OF SCOPE.

11.2 Loss or unavailability of retained records#

Action. Records exist at seal time and are unavailable at review time, through storage failure, retention policy, or ordinary neglect.

Who. Operator.

What detects it. Nothing distinguishes a record that was never made from one that was made and lost, absent an external index.

Disposition. OUT OF SCOPE as to storage and operational practice, which AEF 1000 section 5 places among the prerequisites. AEF 1400 will address retention as it bears on re-verification.

12. What the framework concedes#

Consolidated so a reviewer can read the defeat surface without assembling it.

Before seal time, the operator can suppress an act entirely, delete entries, truncate the record, reorder entries, and choose a scope that excludes the work in question, and none of these leave a trace in the record. The operator can split work across runs so that no record is individually incomplete and nothing describes the whole. The operator can amend the declared scope after seeing the outcome and present the amendment as the original, which defeats the one property that made declaration preferable to a structural boundary.

The operator can show the approving signer something other than what the approval record claims, can hold the approver role itself, and can route approval to someone with no capacity to evaluate the run. The record preserves all three faithfully.

The operator can supply the verifier the reviewer runs. Trust dependencies can be swapped between verifications without the change being recoverable. Where the key history is the operator's, key rotation becomes a way to repudiate inconvenient history. Where the clock is the operator's, every recorded time is an assertion.

The operator can choose which records to hand over.

What an aer is therefore worth. It is a strong constraint on revision and a weak constraint on construction. Once sealed, the record is fixed and any change is detectable. What went into it before that moment is the operator's account, and the framework's contribution is that the account is now dated, attributable, bounded by a written scope, and impossible to revise quietly afterward.

What it is not. It is not proof that the work was done as described, not proof that nothing else happened, and not proof that the record in front of you is the record you asked for.

13. The honest floor#

Given the concessions, a reviewer holding a verified aer can safely say this:

This record was sealed at a stated time under a key bound to a named party, has not changed since sealing, and is internally consistent with a scope its operator declared for the run.

They cannot say any of the following:

This is what happened. Nothing else happened. The approver understood what they were approving. No other record of this work exists. This is the record for the run I asked about. The declared scope was drawn before the outcome was known.

The last one is worth separating from the others, because it is the only item on that list that a later document can plausibly move. The rest are structural.

14. Implications for later documents#

Stated as implications, not requirements, per section 3.

AEF 1200 should require that a conformant verifier be independently obtainable with a reproducible build, and that a verification result record the trust base in force when it was produced. AEF 1201 should state how a verifier demonstrates that it rejects what it should. AEF 1300 should consider chained act log entries, a termination condition in declared scope, a linkage identifier across related runs, and separate sealing of the declaration before execution. AEF 1400 should state what a time source outside the operator's control requires, and should consider bounding and disclosing the interval between capture and seal. AEF 1101 should state what establishes a key and what an independent key history requires.

15. Threat count and disposition#

Twenty-three threats are analyzed. Sorting them into IN SCOPE and CONCEDED alone overstates the defense, because nine entries are defended only where a mechanism holds that no document has yet specified. Those are counted separately.

Defended, resting only on trust dependencies this framework already enumerates: one. Post-hoc alteration of a sealed record, which depends on the signature scheme, the key binding, and the verifier's correctness. This is the framework's core, and it is one threat.

Defended conditionally, where a mechanism nobody has specified yet is in place: nine. Selective deletion and reordering, both defended only after seal time. Replay, where the reviewer has an independent source for the artifacts. Substitution, where the reviewer can name the run independently. Scope amendment, where the declaration is anchored before execution. A defective verifier and inadequate fixtures, both resting on a fixture adequacy nobody defines. Key compromise, where an independent key history and anchored seal times exist. Operator-controlled time, where the time source is not the operator's.

Conceded outright: eleven. Suppression at the source, truncation, adversarial scope declaration, run splitting, referent mismatch, collusion, unqualified approval, verifier substitution, trust base substitution, key rotation as repudiation, and seal-time delay.

Out of scope: two. Selective non-production and record loss.

One threat of twenty-three is defended by what exists today. Nine more are defended by mechanisms that are on the roadmap and unwritten. Eleven are conceded permanently or near enough. Most of what a determined operator can do to an aer, it can do.

16. Terms used here that AEF 1001 does not define#

Recorded rather than coined silently, per the instruction that governs this series. Each belongs in AEF 1001's next version.

• Capturing system. The component that observes acts and emits act log entries. AEF 1001 section 9 uses the phrase in defining capture time without defining the thing.
• External index. A record, outside the operator's control, of which aers exist. AEF 1000 section 4 relies on it when noting that deletion of a whole record is not survived without one.
• Time source. The authority that supplies a recorded time. Referenced by AEF 1000 section 4 and AEF 1001 section 9, defined by neither.
• Key history. The record of which keys were valid over which intervals. Referenced by AEF 1000 section 4, defined nowhere.

Threat names introduced here, such as run splitting and seal-time delay, are labels for analysis in this document and are not proposed as vocabulary.

17. Detections with no observer#

The same defect class audited in AEF 1000, applied to this document. Each is a place where the analysis claims a detection that nobody is designated to perform, that produces no record, and that two honest readers could dispute without resolution.

Fixture adequacy in 9.2 depends on somebody inspecting, and nothing says who or where the inspection is recorded. Boundary adequacy in 7.1 has no criteria, so a reviewer's rejection of a scope is a judgment with no basis the framework supplies. The disclosure obligation in 8.2, which AEF 1001 section 7.1 states as a MUST, has nothing checking that it was met. Verifier correctness in 9.1 has no observer beyond the fixture set whose adequacy is itself unobserved. Whether a declaration preceded execution, in 7.3, is currently unobservable in the ordinary case, which makes it the most consequential entry on this list.

18. Open questions#

1. Boundary adequacy. Whether a declared scope can be tested rather than only rejected. AEF 1300. Already recorded as AEF 1001 open question 1.
2. Pre-execution anchoring of the declaration. What it takes to establish that a declaration preceded execution. AEF 1300 and AEF 1400.
3. Run linkage. Whether related runs can be joined in a way an operator cannot silently omit. AEF 1300.
4. Bounding capture-to-seal latency. Whether the interval can be constrained rather than only disclosed. AEF 1400.
5. Independent verifier distribution. How a reviewer obtains a verifier whose provenance does not run through the operator. AEF 1200.
6. Trust base recording. Whether a verification result must name the trust base in force. AEF 1200, with substance in AEF 1101.
7. Whether selective non-production belongs out of scope. AEF 1000 section 2 makes production cost the framework's stated job, which is an argument that a threat defeating production entirely is the framework's central concern rather than someone else's. No document assigned. It belongs in the 1000 block as a revision to the charter's scope, which the freeze in AEF 1000 section 9 does not obviously permit, and that tension is itself worth recording.

19. License and citation#

Licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).

Cite as:

Stellmacher, G. (2026). AEF 1100: Threat Model, v0.1. 11 August 2026. https://grantstell.com/aef/1100

Cite the version and date, always.