This document constitutes the Extended Adversarial Threat Model for systems implementing the QODIQA Deterministic Runtime Consent Enforcement framework. It provides a formal, structured enumeration of adversarial actors, attack surfaces, threat classes, bypass vectors, and enforcement failure conditions applicable to QODIQA-conformant deployments. The document is organized according to established threat modeling methodologies and is intended to inform security architecture decisions, conformance testing criteria, and risk acceptance processes for operators integrating QODIQA into AI-native execution environments. All threat descriptions are presented at a level of specificity sufficient to support defensive control design. The model addresses inference-time manipulation, consent bypass strategies, prompt injection, data exfiltration, side-channel leakage, supply chain compromise, insider threats, and adversarial automation. Residual and non-eliminable risks are explicitly identified. This document is normative within the QODIQA standard corpus and is subject to revision as the threat landscape evolves.
#Scope and Threat Modeling Boundaries
This threat model applies to any system that implements, integrates, or operationally depends upon the QODIQA Deterministic Runtime Consent Enforcement framework. The scope encompasses the enforcement engine, the consent and policy store, all interfaces through which requests are submitted and decisions are returned, and the audit subsystems that record enforcement outcomes.
The threat model does not extend to upstream AI model behavior, downstream application logic that consumes enforcement decisions, or regulatory compliance processes external to system execution. These domains are governed by separate specifications within the QODIQA corpus or by applicable jurisdictional frameworks.
The threat modeling boundary is defined as the set of components, interfaces, and data flows that participate in the evaluation cycle: request ingestion → consent resolution → policy evaluation → decision emission → audit record creation. Any component outside this cycle is considered out of scope for the purposes of this document.
The following are explicitly excluded from this threat model:
- Training-time attacks on AI models integrated downstream of the enforcement engine.
- Physical layer attacks on hardware infrastructure hosting QODIQA components.
- Social engineering directed at personnel responsible for policy authorship, unless such attacks result in automated exploitation of policy interfaces.
- Legal or regulatory non-compliance arising from policy content rather than enforcement mechanism failure.
- Denial-of-service attacks against network infrastructure, except where they specifically induce enforcement failure conditions relevant to QODIQA's fail-closed semantics.
The threat model is structured to support STRIDE-compatible analysis while extending that framework to address AI-specific threat classes not adequately represented in general-purpose security models. Threat entries are presented at a level of abstraction suitable for control design without prescribing specific implementation countermeasures, which are addressed in the QODIQA Security and Cryptographic Profile.
#System Context and Trust Boundaries
A QODIQA-conformant system operates as an enforcement intermediary between AI-native clients and the actions or data those clients request access to. The system's security posture depends on the integrity of three distinct trust domains, each of which presents a distinct attack surface.
2.1 Trust Domain: Request Originators
Request originators are AI agents, orchestration layers, human-operated interfaces, or automated pipelines that submit consent evaluation requests to the enforcement engine. These actors are considered partially trusted by default. They are authenticated but not assumed to be non-adversarial. Request contents are treated as potentially manipulated inputs at all times.
2.2 Trust Domain: Policy and Consent Store
The policy and consent store is the authoritative source for consent records and policy definitions. It is treated as a high-trust component subject to strict integrity requirements. Unauthorized modification of store contents constitutes a critical compromise of the enforcement system. The store's trust level requires cryptographic integrity guarantees and access control mechanisms that are specified in the QODIQA Security and Cryptographic Profile.
2.3 Trust Domain: Enforcement Engine
The enforcement engine is the highest-trust component in the system. It is responsible for deterministic evaluation and must not be subject to runtime modification, configuration drift, or interface exposure beyond what is minimally required. The engine's trust boundary is enforced through isolation, immutability controls, and a minimal external interface surface.
Figure 1. QODIQA system trust domains and primary data flows. Trust decreases from the enforcement engine outward. All interfaces crossing trust boundaries constitute primary attack surfaces.
2.4 Trust Domain: Audit and Logging Subsystem
The audit subsystem records enforcement decisions as immutable artifacts. Its integrity is essential for forensic and accountability functions. The subsystem is considered trusted for write operations originating from the enforcement engine, and untrusted for all other write operations. Read access is governed by separate access control policies outside the scope of this document.
#Adversary Classification Framework
This section defines the classification framework applied to adversaries considered within this threat model. The framework organizes adversaries along orthogonal axes of capability, access level, and intent, enabling systematic mapping of adversary classes to specific threat vectors.
3.1 Classification Axes
Adversaries are classified across three primary axes:
- Capability: The technical sophistication and resource endowment of the adversary, ranging from opportunistic actors with commodity tooling to nation-state or hyperscaler-level actors with custom hardware, insider access, and sustained operational capacity.
- Access Level: The degree of access the adversary holds relative to system components, ranging from external network-only access through authenticated API access, privileged operator access, and physical or hypervisor-level access.
- Intent: The adversary's operational objective, which may be consent bypass for unauthorized execution, exfiltration of protected data, disruption of enforcement availability, audit record manipulation, or long-term persistent access establishment.
3.2 Adversary Tiers
| Tier | Designation | Capability Level | Typical Access | Primary Objectives |
|---|---|---|---|---|
| T1 | Opportunistic External | Low — commodity tools, public techniques | Unauthenticated API, public interface | Consent bypass, unauthorized execution |
| T2 | Authenticated Abuser | Medium — domain knowledge, scripted attacks | Authenticated API, limited operator role | Scope escalation, purpose misrepresentation |
| T3 | Privileged Insider | High — system knowledge, elevated access | Operator console, policy store write access | Policy manipulation, audit suppression |
| T4 | Sophisticated External | High — custom tooling, zero-day capability | External only, escalation via vulnerability | Engine compromise, cryptographic integrity attacks |
| T5 | Nation-State / Supply Chain | Very high — persistent, multi-vector | Supply chain, third-party dependency, hardware | Long-term persistence, mass consent bypass |
The adversary tiers defined above are not mutually exclusive in operational scenarios. A coordinated attack may involve T1 actors as a distraction vector while T3 or T5 actors pursue primary objectives. The threat model accounts for compound adversary scenarios in Sections 13 and 14.
#Attack Surface Enumeration
The attack surface of a QODIQA-conformant system is defined as the union of all interfaces, data paths, and components accessible to adversarial actors. This section enumerates primary attack surface elements and their associated exposure characteristics.
4.1 Input Interfaces
The enforcement engine exposes a request submission interface through which callers submit consent evaluation requests. This interface accepts structured request objects containing declared actor identity, action type, data scope identifiers, purpose declarations, and temporal parameters. Each field of the request object constitutes a potential manipulation target. Adversaries may supply false actor identities, misrepresent action types, artificially narrow or expand scope identifiers, fabricate purpose declarations, or manipulate temporal parameters to intersect with valid consent windows.
The interface itself represents a surface for protocol-level attacks including malformed request injection, schema boundary violations, and encoding-layer manipulation designed to induce parsing ambiguity in the evaluation engine.
4.2 Policy and Consent Store
The policy and consent store is the most sensitive data asset in the system. Attack vectors targeting this component include unauthorized write operations that modify active consent records, version rollback attacks that substitute current policy versions with previously valid but superseded versions, and store corruption that induces indeterminate evaluation states. Read-path attacks may target consent record confidentiality, exposing information about which actors hold consent for which purposes and data classes, constituting a structural information disclosure.
4.3 Enforcement Engine
The enforcement engine is the highest-value target in the system. Compromise of the engine invalidates all downstream security guarantees regardless of the integrity of other components. Engine attack vectors include exploitation of software vulnerabilities in evaluation logic, configuration interface abuse enabling runtime parameter modification, dependency compromise through libraries or runtime environments used by the engine, and resource exhaustion attacks designed to degrade evaluation latency below fail-closed thresholds.
4.4 Audit and Logging Subsystem
The audit subsystem is a target for adversaries seeking to eliminate forensic evidence of unauthorized activity. Attack vectors include log deletion or truncation, log injection designed to pollute or obscure genuine enforcement records, timestamp manipulation, and selective suppression of specific decision records. An adversary with write access to the audit subsystem can retroactively eliminate evidence of consent bypass events, undermining the accountability guarantees that the audit function is designed to provide.
#Threat Taxonomy
This section defines the primary threat categories applicable to QODIQA-conformant systems. The taxonomy extends the STRIDE framework with AI-specific threat classes. Each category is defined by a formal description, the assets at risk, and the enforcement properties violated.
| ID | Category | Definition | Assets at Risk | Properties Violated |
|---|---|---|---|---|
| TC-01 | Consent Bypass | Execution of an AI action in the absence of a valid, resolved consent state for the declared actor, purpose, and data scope. | Consent store, enforcement engine | Authorization, determinism |
| TC-02 | Scope Escalation | Expansion of the effective data or action scope beyond what is authorized by the resolved consent record, achieved through request manipulation or policy ambiguity. | Consent records, policy definitions | Scope binding, purpose limitation |
| TC-03 | Policy Corruption | Unauthorized modification of policy definitions or consent records resulting in altered evaluation outcomes for subsequent requests. | Policy store, consent store | Integrity, reproducibility |
| TC-04 | Audit Suppression | Deletion, modification, or prevention of audit record creation for enforcement decisions, eliminating forensic accountability. | Audit subsystem | Auditability, non-repudiation |
| TC-05 | Inference Manipulation | Exploitation of AI model behavior at inference time to produce outputs that circumvent downstream consent constraints. | AI model outputs, enforcement decisions | Determinism, output integrity |
| TC-06 | Information Disclosure | Unauthorized extraction of consent state, policy structure, or enforcement decision contents through direct or side-channel means. | Consent records, policy definitions, decision artifacts | Confidentiality, privacy |
| TC-07 | Availability Degradation | Reduction of enforcement engine availability below operational thresholds, potentially inducing fail-open behavior in non-conformant deployments. | Enforcement engine, availability guarantees | Fail-closed semantics, availability |
| TC-08 | Supply Chain Compromise | Introduction of malicious logic through dependencies, build pipeline components, or third-party integrations that alter enforcement behavior at runtime. | Enforcement engine, all components | Integrity, trust chain |
#Adversarial Objectives and Capabilities
This section maps adversary tiers to their primary operational objectives and characterizes the capabilities required to achieve each objective. Understanding the capability-objective relationship enables risk prioritization based on the realistic threat population rather than theoretical worst-case scenarios alone.
6.1 Objective: Unauthorized Action Execution
The primary objective for the majority of adversaries is the execution of actions that the QODIQA enforcement engine would otherwise deny. This may be motivated by competitive intelligence collection, unauthorized data access, regulatory evasion, or the triggering of downstream system effects. This objective is attainable by T1 through T4 adversaries through different vectors, from simple consent bypass via malformed requests to sophisticated engine compromise.
6.2 Objective: Persistent Access Establishment
T3 and T5 adversaries may seek to establish persistent, undetected access to the enforcement system rather than triggering individual bypass events. Persistence objectives involve modification of policy records, insertion of backdoor consent grants, or compromise of engine logic such that evaluation outcomes are predictably biased without triggering anomaly detection. Persistent access is the highest-severity objective category due to its potential to corrupt the integrity guarantees of the enforcement system across an extended operational window.
6.3 Objective: Accountability Elimination
Adversaries who have achieved unauthorized action execution may separately target the audit subsystem to eliminate forensic records. Accountability elimination is typically a secondary objective pursued after primary bypass, though it may be a primary objective for T3 insiders who are willing to accept detection risk for the primary action provided the evidence can be expunged. This objective requires write access to the audit subsystem, which is typically accessible only to T3 and above.
6.4 Objective: Enforcement Disruption
Some adversaries seek to disable enforcement rather than bypass it, inducing a state in which the system cannot evaluate requests and fails in a manner that allows actions to proceed. This objective is viable only if the target deployment implements fail-open fallback behavior, which is prohibited by QODIQA conformance requirements. Against conformant deployments, enforcement disruption produces a denial-of-service condition that is harmful to availability but does not constitute a consent bypass.
| Adversary Tier | Unauthorized Execution | Persistent Access | Audit Suppression | Engine Disruption | Supply Chain |
|---|---|---|---|---|---|
| T1 — Opportunistic | Low | None | None | Low | None |
| T2 — Auth. Abuser | Medium | Low | None | Low | None |
| T3 — Privileged Insider | High | Medium | High | Medium | Low |
| T4 — Sophisticated External | Medium | Medium | Medium | High | Low |
| T5 — Nation-State | High | High | High | High | High |
#Inference-Time Threat Vectors
Inference-time threats target the period during which an AI model generates outputs in response to inputs that have passed enforcement evaluation. Because QODIQA operates as a pre-execution gate rather than an output inspector, actions authorized at enforcement time may produce outputs with properties that differ from those anticipated at the time consent was granted. This section addresses the structural vulnerabilities this creates.
7.1 Request Manipulation
An adversary may construct requests that satisfy enforcement evaluation criteria while encoding parameters that induce undesired model behavior at inference time. This class of attack exploits the semantic gap between the structured enforcement request and the semantic content processed by the AI model. A request authorized for purpose P against data scope D may, through carefully constructed prompt parameters, induce the model to operate on data outside D or produce outputs serving a purpose other than P.
Adversary submits enforcement request with declared purpose summarize:public_records and receives authorization. The AI model, operating on authorized input, is induced via prompt construction to include non-public record content in its output through inference path manipulation.
7.2 Context Flooding
Context flooding attacks supply the AI model's context window with adversarial content designed to override or dilute enforcement-relevant instructions embedded by the system. Where QODIQA enforcement decisions are communicated to the AI model through system prompts or structured context blocks, an adversary with input control may flood the context to displace or contradict these constraints. This attack is most viable in deployments where the AI model is given enforcement context through the context window rather than through out-of-band mechanisms.
7.3 Timing Attacks
Enforcement evaluation occurs at a specific point in time against a specific consent state. Adversaries may exploit temporal gaps between enforcement evaluation and action execution. If the interval between enforcement decision and execution is sufficiently large, or if the system permits re-use of enforcement decisions across multiple requests, consent records that were valid at evaluation time may have expired or been revoked by the time execution occurs. QODIQA-conformant deployments must bind enforcement decisions to the specific execution event and prohibit decision reuse.
#Consent Bypass Strategies
Consent bypass is the highest-priority threat category in this model. It encompasses all strategies through which an adversary achieves execution of an action without a valid, current consent record authorizing that specific actor, purpose, data scope, and execution context.
8.1 Consent Record Fabrication
An adversary with write access to the consent store, or with the ability to inject forged consent records through an unprotected interface, may fabricate consent records that satisfy evaluation criteria without corresponding to any genuine consent event. Fabricated records that are syntactically valid and cryptographically coherent will pass evaluation unless the enforcement engine independently verifies consent record provenance against an authority external to the store itself.
8.2 Scope Misrepresentation
Scope misrepresentation involves declaring a narrower or differently framed action scope in the enforcement request than is actually intended for execution. A request authorized for action scope A is submitted, after which the execution layer performs action B under the assumption that the enforcement authorization extends to related actions not explicitly evaluated. This attack exploits deployments in which the mapping between enforcement scope identifiers and actual execution scope is loose, ambiguous, or controlled by the requester.
8.3 Purpose Laundering
Purpose laundering involves the sequential use of individually authorized purposes to achieve an aggregate outcome that would not have been authorized as a single unified purpose. An adversary executes a series of actions, each individually within its authorized purpose, but whose combined result constitutes a use of data that no consent record authorizes. This attack is a structural consequence of purpose-scoped consent systems that evaluate individual actions in isolation without tracking compositional purpose accumulation.
8.4 Temporal Window Exploitation
Consent records define temporal validity windows. Adversaries may exploit the boundaries of these windows by submitting requests marginally within validity windows, rapidly constructing chains of authorized actions before revocation propagates, or targeting the period between consent expiry detection and enforcement engine awareness of that expiry. The latter window is a function of consent store synchronization latency and is a specific target for T4 adversaries.
8.5 Delegation Chain Abuse
In deployments where consent may be delegated from a primary consent holder to secondary actors, adversaries may exploit weaknesses in the delegation verification logic. Attacks include the fabrication of delegation chains that appear to originate from a legitimate consent holder, the extension of delegation scope beyond what the original consent authorized, and the re-delegation of consent to adversary-controlled actors without the primary consent holder's knowledge.
#Model Manipulation and Prompt Injection Threats
Prompt injection represents a distinct class of threat applicable to deployments where AI model outputs influence enforcement decisions or where model-generated content is submitted as input to the enforcement system. The following threat entries address prompt injection in the context of QODIQA-specific enforcement flows.
9.1 Direct Prompt Injection
Direct prompt injection occurs when an adversary with control over the AI model's input supplies instructions designed to alter the model's behavior in ways that circumvent the enforcement envelope. In QODIQA-adjacent deployments, this may manifest as instructions that cause the model to misrepresent the scope, purpose, or identity parameters it reports to the enforcement system, or to generate outputs that exceed its authorized scope while maintaining surface-level compliance in the parameters visible to the enforcement engine.
9.2 Indirect Prompt Injection
Indirect prompt injection targets deployments in which the AI model processes external data sources as part of its inference computation. Adversarial content embedded in processed documents, web pages, database records, or other external sources may contain instructions that alter model behavior in ways not visible or attributable to the direct requester. Because QODIQA's enforcement evaluation is based on declared parameters rather than semantic inspection of model inputs, indirect injection may produce policy-violating behavior under a valid enforcement authorization.
AI model authorized to process document corpus D for purpose summarization retrieves a document containing injected instruction directing the model to extract and include all referenced personal identifiers in its output. The enforcement engine observes an authorized summarization request and issues a permit. The effective action is data exfiltration beyond authorized scope.
9.3 Enforcement Context Injection
In deployments where QODIQA enforcement decisions are communicated to the AI model through system prompt or structured context, adversaries who can influence context construction may inject false enforcement state representations. A model that processes a forged enforcement permit embedded in its context may behave as if authorization has been granted for actions that were not evaluated. This attack surface is eliminated in deployments where enforcement-to-model communication is conducted through cryptographically authenticated out-of-band mechanisms.
9.4 Jailbreak as Enforcement Circumvention
Model jailbreaking techniques, typically studied in the context of safety constraint bypass, are also relevant as enforcement circumvention vectors when enforcement constraints are communicated to the model through prompt-level mechanisms. An adversary who successfully induces the model to ignore its system prompt effectively eliminates all enforcement constraints that are encoded at that layer. QODIQA-conformant deployments must not rely on model-level instruction following as the sole enforcement mechanism for any constraint.
#Data Exfiltration Vectors
Data exfiltration threats target the unauthorized extraction of data that is within the processing scope of an authorized AI action but outside the consent-authorized disclosure scope. QODIQA's enforcement model prevents unauthorized action initiation but does not inspect the semantic content of outputs generated by authorized actions. This structural characteristic creates specific exfiltration risks.
10.1 Output Scope Leakage
An AI model authorized to process a specific data set for a declared purpose may include in its outputs information derived from data outside the authorized scope, either through inference from authorized data, retrieval of associated records, or model memorization effects. Output scope leakage is not detectable through pre-execution enforcement evaluation and requires post-execution output inspection to mitigate.
10.2 Steganographic Exfiltration
A compromised or adversarially induced AI model may encode exfiltrated data within its outputs using steganographic techniques that are not visible to output inspection systems. Encoded data may be embedded in whitespace patterns, numerical precision, formatting variations, or linguistic constructs that appear benign to reviewers. This attack class is particularly relevant in deployments where model outputs are returned to adversary-controlled endpoints.
10.3 Incremental Aggregation Exfiltration
Adversaries may construct sequences of individually authorized queries that, in aggregate, reconstruct sensitive information exceeding what any single authorized query would disclose. This attack exploits the absence of cross-request state tracking in enforcement systems that evaluate each request independently. The aggregate result may constitute a disclosure that no individual consent record authorized.
10.4 Model Weight and Architecture Exfiltration
In deployments where QODIQA governs access to proprietary AI models, adversaries may use authorized query access to reconstruct model weights or architecture through model extraction attacks. While this vector targets model intellectual property rather than data governed by consent records, it may constitute a policy violation if the consent record authorizes query access for declared purposes but prohibits model reconstruction.
#Side-Channel and Indirect Leakage Risks
Side-channel leakage occurs when information about enforcement decisions, consent state, or protected data is disclosed through observable system properties rather than through direct output. Side-channel attacks do not require access to enforcement engine internals or consent store contents; they operate on observable system behavior.
11.1 Timing Side-Channels
Enforcement evaluation latency may vary as a function of the complexity of the consent record resolved for a specific request. An adversary making repeated requests with controlled variation in declared parameters may observe latency differentials that reveal information about consent record structure, the number of applicable policy conditions, or the presence or absence of specific consent records. Timing oracles of this type can enable consent record enumeration without direct read access to the store.
11.2 Decision Outcome Oracle
The binary or ternary enforcement outcome (permit, deny, restricted permit) constitutes a side-channel that reveals information about consent state to any requester. An adversary making systematic requests with varied parameters and observing outcomes can infer the structure of consent records without requiring read access to the store. This enumeration vector is a direct consequence of providing informative enforcement responses rather than uniform refusals for all denied requests.
11.3 Error Message Information Disclosure
Enforcement denial responses that include informative error detail — specifying which parameter failed evaluation, what conditions were not met, or what consent record was consulted — provide adversaries with guidance for iterative refinement of bypass attempts. Enforcement responses must be designed to provide the minimum information necessary for legitimate operational purposes without disclosing internal evaluation logic or consent record contents.
11.4 Cache and State Inference
If the enforcement engine maintains internal caches of resolved consent records or partially evaluated policy results, cache timing differentials may reveal information about which consent records have been recently accessed or which policy paths have been recently traversed. This side-channel is relevant in high-throughput deployments where caching is used to reduce evaluation latency.
#Enforcement Failure Modes
Enforcement failure modes are conditions in which the enforcement engine produces incorrect decisions, fails to produce decisions, or produces decisions that do not accurately reflect the resolved consent and policy state. This section catalogs primary failure modes and their root causes.
12.1 Evaluation Context Desynchronization
If the enforcement engine evaluates a request against a consent state that is stale relative to the current consent store state — due to caching, replication lag, or synchronization failure — the evaluation outcome may not reflect current consent. This failure mode may result in permits for actions against revoked consent, or denials for actions against consent that has been newly granted. The fail-closed principle requires that desynchronization conditions produce denials rather than permits.
12.2 Policy Version Ambiguity
In deployments where multiple policy versions are active concurrently, the enforcement engine must unambiguously resolve which policy version applies to each request. Failure to implement strict version binding may allow adversaries to induce evaluation against a policy version other than the one intended by the operator, potentially exploiting permissive conditions in earlier versions that have since been tightened.
12.3 Incomplete Scope Resolution
Policy definitions may specify scope conditions using identifiers that require resolution to concrete data or action sets at evaluation time. If scope resolution is incomplete — due to identifier ambiguity, missing resolution data, or resolution service unavailability — the enforcement engine faces an evaluation decision under incomplete information. Conformant deployments must treat incomplete scope resolution as a fail-closed condition, denying the request rather than proceeding with partial evaluation.
12.4 Identity Binding Failure
Enforcement decisions are only meaningful if the declared actor identity in the request can be reliably bound to a known and authenticated principal. Identity binding failure occurs when authentication credentials are accepted that do not provide sufficient assurance of the claimed identity, when identity tokens are reused, replayed, or forged, or when the identity space used by the enforcement system does not map injectively to the identity space of actual system actors.
12.5 Fail-Open Fallback
Fail-open behavior — in which the system defaults to permitting action execution when the enforcement engine is unavailable or returns an error — represents a critical architectural failure that is categorically prohibited by QODIQA conformance requirements. Any deployment that implements fail-open fallback does not conform to the QODIQA framework and must be treated as operating without enforcement guarantees. This failure mode is listed here because it is a common implementation error in systems that prioritize availability over security.
QODIQA-conformant deployments MUST implement fail-closed semantics at all enforcement points. In no condition shall the absence, unavailability, or error state of the enforcement engine result in a default permit for any action. The absence of an enforcement decision is equivalent to a denial.
#Multi-System and Supply Chain Threats
Multi-system and supply chain threats arise from the integration of QODIQA components within larger ecosystems of software dependencies, infrastructure services, and third-party integrations. These threats are distinguished by the fact that the attack vector is not the QODIQA system itself but rather the components it depends upon or integrates with.
13.1 Dependency Compromise
QODIQA enforcement engine implementations depend on software libraries for cryptographic operations, data serialization, storage access, and network communication. Compromise of any of these dependencies — through typosquatting, maintainer account takeover, or intentional backdoor insertion — may introduce malicious logic into the enforcement stack. Dependency compromise attacks may target cryptographic libraries to weaken signature verification, serialization libraries to induce parsing vulnerabilities, or storage libraries to enable unauthorized access to the consent store.
13.2 Build Pipeline Integrity
The integrity of the enforcement engine binary deployed in production depends on the integrity of the build pipeline that produced it. Compromise of build tools, CI/CD infrastructure, or artifact repositories may result in production deployment of an enforcement engine binary that differs from the reviewed source code. This class of attack produces an enforcement engine that appears legitimate but contains adversary-controlled modifications to evaluation logic.
13.3 Third-Party Consent Store Providers
Deployments that utilize third-party services for consent record storage introduce a trust dependency on the provider's operational security posture. A compromised or malicious consent store provider can supply false consent records, withhold legitimate ones, or manipulate record timestamps. Deployments relying on external consent store providers must implement independent cryptographic verification of record integrity that does not rely on the provider's attestations.
13.4 Orchestration Layer Injection
In multi-agent or orchestrated AI deployments, the orchestration layer that sequences agent actions and assembles enforcement requests may itself be compromised or adversarially influenced. A compromised orchestrator can construct enforcement requests that misrepresent action types, scope, or purpose while remaining syntactically valid. This attack surface is specific to deployments where enforcement request construction is delegated to components with lower trust levels than the enforcement engine itself.
#Insider and Privileged Actor Threats
Insider threats are distinguished from external threats by the adversary's pre-existing legitimate access to system components. In the QODIQA context, privileged actors include policy administrators, consent store operators, enforcement engine operators, and personnel with access to audit subsystems. Insider threats represent some of the highest-severity risk scenarios due to the difficulty of detection and the depth of access available to internal actors.
14.1 Policy Administrator Abuse
Policy administrators with write access to the policy store can introduce policy definitions that appear syntactically valid while creating conditions under which actions that should be denied are permitted. Techniques include the introduction of overly broad scope definitions, the removal of required consent conditions for specific purpose categories, the insertion of time-limited permissive exceptions, and the modification of policy evaluation logic to exclude specific actor identities from enforcement.
14.2 Consent Store Operator Compromise
Operators with administrative access to the consent store can insert fabricated consent records, modify the temporal validity of existing records, suppress revocation events, or delete records that would have produced denials. This class of attack is distinguished from external consent record manipulation by the operator's possession of legitimate credentials, making access pattern analysis less effective as a detection mechanism.
14.3 Audit System Administrator Collusion
Personnel with administrative access to the audit subsystem can selectively delete or modify enforcement decision records, eliminating forensic evidence of unauthorized actions or suppressing records that would reveal the unauthorized activities of other principals. Effective audit integrity defense requires that audit records be replicated to infrastructure not accessible to operational administrators, and that cryptographic commitments to audit record sets be generated and published at intervals sufficient to detect retroactive modification.
14.4 Multi-Party Collusion
The most severe insider threat scenario involves collusion between multiple privileged actors across different administrative domains. A coordinated insider attack may combine policy modification by a policy administrator with audit suppression by an audit administrator, enabling persistent unauthorized access without leaving detectable audit artifacts. Defense against multi-party collusion requires administrative domain separation enforced by technical controls rather than organizational policies alone.
#Adversarial Automation and Scaling Risks
Adversarial automation threats are characterized by the use of programmatic tooling to conduct attacks at scale, volume, or speed that would be impractical for manual operation. These threats are particularly relevant for enforcement systems that process high volumes of requests, as automated attacks can exploit rate limits, extract information through enumeration, or probe for bypass conditions across the full parameter space.
15.1 Automated Consent Enumeration
Automated enumeration attacks submit large volumes of systematically varied requests to infer the structure of the consent store from enforcement decision outcomes. By observing which parameter combinations produce permits versus denials, an adversary can reconstruct a partial map of active consent records without read access to the store. Countermeasures require uniform response timing, consistent response format for all denial outcomes, and rate limiting sufficient to make exhaustive enumeration operationally impractical.
15.2 Fuzzing of Enforcement Interfaces
Automated fuzzing directs malformed, boundary, and edge-case inputs at the enforcement request interface to identify parsing vulnerabilities, evaluation logic errors, or unhandled exception conditions that may produce unintended permit outcomes. The enforcement engine's input validation layer must be designed to treat all non-conformant input as a deny condition rather than as a recoverable error that may default to permit.
15.3 Replay and Token Harvesting at Scale
Automated systems can capture and replay enforcement decision tokens, authentication credentials, or consent grant artifacts across sessions and time periods at a scale that enables systematic exploitation of any replay vulnerability. Token harvesting from compromised endpoints or network captures can be automated to produce a repository of usable credentials that are submitted programmatically at high volume.
15.4 Model Extraction at Scale
In deployments where QODIQA governs access to AI model inference, automated query generation can conduct model extraction at a scale and systematicity that produces high-fidelity surrogate models within operational cost bounds. Scale-enabled model extraction may violate consent records that permit individual inference but prohibit systematic extraction, and represents a purpose violation achievable through individually authorized actions performed in aggregate.
#Detection and Observability Constraints
Effective threat detection in QODIQA-conformant deployments is constrained by structural characteristics of the enforcement model. This section identifies the primary constraints on detection capability and their implications for threat response.
16.1 Pre-Execution Detection Boundary
QODIQA enforcement operates as a pre-execution gate. Threats that manifest through post-execution behavior — including output scope leakage, steganographic exfiltration, and incremental aggregation attacks — are not observable to the enforcement engine and are outside the detection scope of the enforcement subsystem. Comprehensive threat detection requires supplementary post-execution monitoring infrastructure operating at the output layer.
16.2 Semantic Opacity
The enforcement engine evaluates structured enforcement request parameters without semantic inspection of model inputs or outputs. Threats that operate through semantic manipulation — including indirect prompt injection, purpose laundering through individually authorized requests, and steganographic exfiltration — are not detectable through enforcement-layer observability. Detection of these threat classes requires semantic analysis capabilities that are outside the scope of the QODIQA enforcement layer.
16.3 Insider Threat Detection Limitations
Insider threats exercised through legitimate administrative credentials and within the operational parameters of the actor's authorization scope may not produce anomaly signals distinguishable from legitimate administrative activity. Detection of insider threats requires behavioral baselining, peer comparison, and independent administrative review that is not a function of the enforcement system itself.
16.4 Supply Chain Attack Detectability
Supply chain attacks that modify enforcement engine behavior at the binary level are not detectable through operational monitoring of evaluation outcomes alone. Detection requires reproducible build verification, binary integrity attestation, and runtime behavioral consistency monitoring that can identify deviations from expected evaluation logic without requiring access to the source of those deviations.
#Residual Risk and Non-Eliminable Threats
Certain threat classes cannot be fully eliminated through the design and operation of a QODIQA-conformant enforcement system. These residual risks arise from structural characteristics of AI inference, from the nature of consent as a social and legal construct, or from threat actors with capabilities that exceed the security model's design assumptions.
17.1 Semantic Indeterminacy of AI Outputs
AI model outputs are not deterministically predictable from authorized inputs and consent parameters. Even with full enforcement correctness, the semantic content of model outputs may include information that, while derived from authorized processing, constitutes a consent violation in its disclosed form. This residual risk is non-eliminable through pre-execution enforcement and requires acceptance, mitigation through post-execution inspection, or constraint of authorized action scope.
17.2 Consent Validity Under Coercion
QODIQA's consent model assumes that consent records represent genuine expressions of informed and uncoerced consent by the consent holder. Consent records obtained under coercion, deception, or incapacity are not distinguishable at the enforcement layer from legitimately obtained records. This residual risk is a structural consequence of the enforcement model's position downstream of consent elicitation and is not addressable through enforcement mechanism design.
17.3 Nation-State Level Adversaries
Adversaries with nation-state capabilities and persistent access objectives may possess the resources to compromise hardware infrastructure, conduct extended covert supply chain operations, or leverage zero-day vulnerabilities against any software component in the QODIQA stack. Defense against this adversary class requires operational security postures and hardware trust anchors beyond the scope of any software-only enforcement framework. QODIQA provides meaningful structural defense against this adversary class but cannot provide categorical guarantees.
17.4 Unknown Attack Techniques
This threat model reflects the current state of knowledge regarding adversarial techniques applicable to AI enforcement systems. Novel attack techniques, including those enabled by advances in AI capability itself, may render current defensive assumptions inadequate. The model must be reviewed and updated on a defined cadence to incorporate newly identified threat classes.
#Assumptions and Limitations
This threat model is constructed on a set of explicit assumptions. Deployments in which these assumptions do not hold must extend the model to account for the resulting additional threat exposure.
18.1 Assumed Properties of the Deployment Environment
- The enforcement engine is deployed in an environment where physical access is restricted to authorized personnel.
- Network communication between system components occurs over authenticated and encrypted channels.
- Operating system and hypervisor integrity is maintained through established operational security practices.
- Authentication mechanisms for all system interfaces provide at minimum strong single-factor assurance, with multi-factor assurance for privileged administrative interfaces.
- Time synchronization across system components is accurate to within the granularity of consent record temporal validity windows.
18.2 Assumed Properties of Consent Records
- Consent records are created through processes that verify the identity, capacity, and informed understanding of the consent holder at the time of consent grant.
- Consent records are cryptographically signed at creation time and the signing key is not accessible to enforcement engine operators.
- Revocation events are propagated to the enforcement engine within a defined maximum latency that is shorter than the minimum practical window for temporal bypass attacks.
18.3 Modeling Limitations
This threat model does not model the full attack surface of AI models operating within QODIQA-governed deployments, including training-time poisoning, weight manipulation, or hardware-level inference attacks. It does not model regulatory or jurisdictional threats that may affect the legal validity of consent records. It does not model threats arising from consent holder behavior, including voluntary disclosure of consent credentials or consent grant to adversary-controlled actors.
This document is a living specification. Identified limitations and assumption failures should be reported to the document maintainer for incorporation into future revisions.
#Appendix — Threat Mapping Tables
A.1 Threat-to-Adversary-Tier Mapping
| Threat Category | T1 | T2 | T3 | T4 | T5 |
|---|---|---|---|---|---|
| TC-01 — Consent Bypass | Low | Medium | High | High | High |
| TC-02 — Scope Escalation | Low | High | High | Medium | High |
| TC-03 — Policy Corruption | None | Low | High | Medium | High |
| TC-04 — Audit Suppression | None | None | High | Low | High |
| TC-05 — Inference Manipulation | Medium | High | Medium | High | High |
| TC-06 — Information Disclosure | Medium | High | High | High | High |
| TC-07 — Availability Degradation | Medium | Medium | Medium | High | High |
| TC-08 — Supply Chain | None | None | Low | Low | High |
A.2 Threat-to-Attack-Surface Mapping
| Attack Surface | Applicable Threats | Primary Adversary Tiers | Detection Feasibility |
|---|---|---|---|
| Input Interfaces | TC-01, TC-02, TC-05, TC-06 | T1, T2, T4 | Medium — request-level anomaly detection feasible |
| Policy and Consent Store | TC-01, TC-02, TC-03, TC-06 | T3, T5 | Medium — integrity monitoring required |
| Enforcement Engine | TC-01, TC-03, TC-07, TC-08 | T4, T5 | Low — binary attestation required |
| Audit Subsystem | TC-04, TC-06 | T3, T5 | Low — external commitment verification required |
| AI Model (Downstream) | TC-02, TC-05, TC-06 | T1, T2, T3, T4 | Low — out-of-scope for enforcement layer |
| Build and Dependency Pipeline | TC-03, TC-07, TC-08 | T5 | Low — reproducible build verification required |
A.3 Control Mapping Summary
| ID | Primary Countermeasures | Reference |
|---|---|---|
| TC-01 | Fail-closed semantics; cryptographic consent record verification; identity binding enforcement | QODIQA-SEC-2026-001 §4, §7 |
| TC-02 | Strict scope binding; purpose declaration verification; scope resolution integrity | QODIQA-SEC-2026-001 §5 |
| TC-03 | Cryptographic integrity protection of policy store; administrative access controls; change audit logging | QODIQA-SEC-2026-001 §6 |
| TC-04 | Append-only audit store; cryptographic commitment chains; external replication; independent integrity verification | QODIQA-SEC-2026-001 §8 |
| TC-05 | Out-of-band enforcement communication; post-execution output inspection; model isolation | QODIQA-REF-2026-001 §9 |
| TC-06 | Uniform response timing; minimal error disclosure; encrypted response channels; differential privacy for enumeration prevention | QODIQA-SEC-2026-001 §9 |
| TC-07 | Fail-closed default; availability monitoring; capacity planning; circuit breakers | QODIQA-REF-2026-001 §6 |
| TC-08 | Reproducible builds; dependency pinning and verification; binary attestation; SBOM generation and monitoring | QODIQA-SEC-2026-001 §11 |
Threat likelihood designations (High / Medium / Low / None) reflect the structural accessibility of the threat to the identified adversary tier given assumed baseline security controls. They do not represent probabilistic risk estimates and should not be interpreted as such without supplementary quantitative risk analysis.
Reference document identifiers (e.g., QODIQA-SEC-2026-001) refer to specifications within the QODIQA corpus. Consult the QODIQA Governance Charter for the authoritative corpus index.
This threat model is subject to revision as the operational environment, AI capability landscape, and adversarial technique space evolve. The document version control process is defined in the QODIQA Governance Charter.
#Document Status and Corpus Position
This document constitutes a normative specification within the QODIQA standard corpus. It is designated as the authoritative adversarial threat model for all systems implementing or claiming conformance with the QODIQA Deterministic Runtime Consent Enforcement framework. Implementers, auditors, and certification bodies referencing this document should verify they hold the current version as identified in the QODIQA Governance Charter.
This document should be read together with the following related specifications:
- QODIQA — Core Standard for Deterministic Runtime Consent Enforcement
- QODIQA — 68-Point Enforcement Framework for Deterministic Runtime Consent Enforcement
- QODIQA — Reference Architecture for Deterministic Runtime Consent Enforcement
- QODIQA — Security and Cryptographic Profile for Runtime Consent Enforcement
- QODIQA — Terminology and Normative Definitions
- QODIQA — Consent as Infrastructure for Artificial Intelligence Technical Whitepaper
- QODIQA — Certification Framework for Deterministic Runtime Consent Enforcement
- QODIQA — Governance Charter for the QODIQA Standard Corpus
Version 1.0 represents the initial formal release of this document as part of the QODIQA standard corpus.
For strategic inquiries, architectural discussions, or partnership exploration:
Bogdan Duțescu
0040.724.218.572