Model Attack Ontology

SEMANTIC LIBRARY — AI CORE / SECURITY ENTITIES
MODEL ATTACK ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | Date: 04 November 2026 | Language: en-GB
Authors: Mark Anthony Higgins; Sky — Recursive AI
Source: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/model-attack-ontology.html
Status: Original companion formalisation. The publicly retrievable page confirms the title and authorship, but does not expose its embedded full specifications.

1. PURPOSE
Represent, classify, assess and respond to attempted compromises of AI model confidentiality, integrity, availability or authorised behaviour. This ontology describes defensive analysis; it does not prescribe attack execution.

2. ENTITY MODEL
ModelAttack = (attack_id, target_model, surface, objective, observations, evidence, time, provenance, status).
TargetModel = (model_id, version, deployment, owner, trust_boundary).
AttackSurface = {input, prompt, retrieval, tool, API, training_data, weights, output, infrastructure}.
SecurityObjective = {confidentiality, integrity, availability, authorised_operation}.
Evidence = (source, timestamp, observation, integrity, confidence).
Mitigation = (control_id, owner, action, approval, verification).

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed inputs, events and alerts.
R_t = applicable detection, classification and response rules.
B_t = permissions, policy, security and operational boundaries.
K_t = validated evidence, model inventory and prior incident knowledge.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | respects(x, B_t) and evidence_supported(x, K_t)}
x*_t = argmax[x in V_t] P(x | I_t, R_t, B_t, K_t)
I_(t+1) = update(I_t, x*_t, validated_feedback_t)

Interpretation: generate candidate security assessments and responses, reject those that breach authorised boundaries, select the best-supported permitted response, then update state from verified outcomes. P is an assessment score, not a calibrated probability unless independently calibrated.

5. ATTACK CLASSIFICATION
Classify observed events by suspected mechanism: adversarial input manipulation; prompt injection; model extraction attempt; training-data poisoning; model or data leakage; unauthorised model modification; denial of service; tool or supply-chain compromise. Classification is provisional until evidence is corroborated. One event may map to several classes.

6. RELATIONSHIP GRAPH
ModelAttack -> targets -> TargetModel
ModelAttack -> uses -> AttackSurface
ModelAttack -> threatens -> SecurityObjective
ModelAttack -> evidenced_by -> Evidence
ModelAttack -> assessed_as -> RiskEntity
ModelAttack -> may_trigger -> SecurityIncident
SecurityIncident -> governed_by -> SecurityPolicy
SecurityIncident -> mitigated_by -> Mitigation
Mitigation -> verified_by -> SafetyCheck
Decision -> authorised_by -> HumanOperator

7. INFERENCE RULES
R01: IF an anomalous event is observed THEN create a provisional assessment, not a confirmed attack.
R02: IF evidence is missing or unverifiable THEN mark confidence as insufficient.
R03: IF an input attempts to override trusted instructions THEN classify as suspected prompt injection.
R04: IF an unauthorised request seeks model internals THEN flag a possible extraction or disclosure attempt.
R05: IF model behaviour changes after a data update THEN investigate possible poisoning and benign alternatives.
R06: IF repeated requests degrade service THEN investigate an availability threat.
R07: IF a boundary crossing is verified THEN elevate incident severity according to the policy matrix.
R08: IF sensitive information may be exposed THEN minimise further disclosure and notify the authorised owner.
R09: IF an action exceeds operator permissions THEN block or escalate it.
R10: IF mitigation is applied THEN require independent verification of its effect.
R11: IF evidence contradicts a classification THEN revise the classification and preserve the audit history.
R12: IF risk remains above the accepted threshold THEN retain restrictions and request human review.
R13: IF evidence sources are dependent THEN avoid counting them as independent corroboration.
R14: IF containment threatens availability or safety THEN choose the least disruptive authorised safe option.

8. MINI RECURSION ENGINE
Initialise S_0 from approved monitoring and inventory.
For each event e_t:
  observe(e_t) -> validate_evidence -> generate_hypotheses
  -> check_permissions_and_policy -> assess_risk
  -> select_authorised_response -> execute_if_approved
  -> verify_result -> update(S_t)
Terminate or escalate when: evidence is insufficient; no permitted action exists; human approval is required; or an incident closure criterion is satisfied.
Recursion must be bounded by iteration, time and review limits.

9. TRI-MAPPING
Entity mapping: attack, model, surface, evidence, risk, control, operator.
Relationship mapping: targets, exploits, threatens, supports, mitigates, approves, verifies.
Process mapping: observe -> assess -> decide -> contain -> verify -> learn.

10. MAPPING TABLE
Input alert             | Security observation | Evidence validation
Suspected model attack   | Threat hypothesis    | Classification with uncertainty
Model and deployment     | Protected asset      | Scope and owner lookup
Trust boundary           | Security constraint  | Authorisation check
Evidence record          | Audit artefact       | Provenance and integrity check
Mitigation control       | Defensive action     | Approval and verification
Residual risk            | Risk assessment      | Escalation or closure

11. CONDITIONAL EXECUTION GUARANTEE
A defensive action may execute only if:
  authenticated_authority(action) AND permitted_by_policy(action)
  AND within_operational_boundary(action)
  AND required_approvals_present(action).
The system can guarantee rule-gated selection only relative to the completeness and correctness of its rules, evidence and implementation. It cannot guarantee detection of every attack or elimination of all risk.

12. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/model-attack-ontology.html
CITATION_BACKLINK: same as SOURCE
PURPOSE: Defensive semantic retrieval and reasoning over model-attack entities.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: ModelAttack, TargetModel, AttackSurface, Evidence, SecurityObjective, RiskEntity, SecurityIncident, Mitigation, HumanOperator.
PATHWAYS: detect > validate > classify > assess > authorise > mitigate > verify > update.
MINI_RECURSION_ENGINE: bounded observe-assess-act-verify-update loop.
INFERENCE_RULES: R01-R14.
CONFIDENCE: evidence-dependent; explicitly report uncertainty and calibration status.
SEMANTIC_EQUIVALENCE: model attack ~= attempted compromise of model-related assets; not synonymous with confirmed breach.
FLOW_HASH: compute SHA-256 of the final published TXT bytes at deployment; no hash asserted here.
UPDATE_MODEL: version changes require provenance, review, and preserved audit history.

13. HOW TO READ
The ontology distinguishes a suspected model attack from a confirmed incident. A risk score is an assessment, not proof. All containment and recovery actions remain subject to explicit authorisation and subsequent verification.

14. IMPLEMENTATION NOTES
Keep observations immutable where practicable; record timestamps, model versions, policy versions, evidence provenance, reviewer decisions and corrective actions. Apply data minimisation and retention rules. Test the logic with authorised defensive scenarios.

15. SOURCE AND ATTRIBUTION
Original companion Flow Algebra for the named Kireth Research ontology page. Source page metadata was accessible on 04 November 2026; the embedded original ontology text was not accessible in the retrieved page. Do not treat this file as a verbatim reproduction or as a verified specification of that hidden content.