Adversarial Attack Ontology

SEMANTIC LIBRARY — AI CORE / SECURITY ENTITIES
ADVERSARIAL 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/adversarial-attack-ontology.html
Status: Original companion formalisation; the page's embedded specifications were not available in the retrieved text.

1. PURPOSE
Represent adversarial attacks against AI systems as typed entities with explicit threat objectives, attack surfaces, observable evidence, constraints, defensive decisions and accountable outcomes. This ontology supports defensive analysis, not attack execution.

2. ENTITY MODEL
AdversarialAttack = (id, actor, target, surface, objective, vector, evidence, severity, confidence, status, time, provenance)
Related entities: SecurityThreat, AdversarialExample, Vulnerability, Model, Dataset, Input, Prompt, Tool, AccessControl, SafetyPolicy, SecurityControl, Incident, AuditRecord, HumanOperator.
Relationships:
  targets(Attack, System)
  exploits(Attack, Vulnerability)
  traverses(Attack, Surface)
  attempts(Attack, Objective)
  observedBy(Attack, Evidence)
  mitigatedBy(Attack, Control)
  escalatedTo(Attack, HumanOperator)
  recordedAs(Attack, Incident)

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t: observed inputs, telemetry, alerts, model responses and reports.
R_t: verified entity relationships and inference rules.
B_t: security boundaries, permissions, constraints and uncertainty limits.
K_t: trusted knowledge, validated threat patterns and prior incident records.
Attack lifecycle: suspected -> triaged -> investigated -> confirmed | rejected | unresolved -> contained -> reviewed -> closed.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | valid(x, B_t) AND provenance_ok(x)}
A_t = {a in V_t | matches_attack_indicators(a, K_t)}
Score(a) = w1*evidence_strength(a) + w2*impact(a) + w3*exposure(a) - w4*uncertainty(a)
a* = argmax_{a in A_t} P(a | I_t, R_t, B_t, K_t)
Decision_t = PolicyGate(a*, Score(a*), B_t)
I_(t+1) = update(I_t, Decision_t, new_evidence_t)
These scores are illustrative; calibration and thresholds must be established for each deployment.

5. ATTACK CLASSIFICATION
Classes: adversarial input manipulation; prompt injection; training-data poisoning; model extraction attempt; evasion attempt; tool-output manipulation; privilege-boundary violation; model supply-chain compromise.
Classification must distinguish attempted, observed and confirmed effects. A suspicious input alone is not proof of malicious intent.

6. DEFENSIVE PATHWAYS
Observe -> normalise -> establish provenance -> classify indicators -> check trust boundary -> estimate impact -> apply permitted controls -> preserve evidence -> review -> update safeguards.
Permitted responses: flag, rate-limit, isolate untrusted input, block unsafe action, require approval, quarantine affected artefacts, escalate, log and monitor.

7. INFERENCE RULES
R01: IF input crosses a trust boundary THEN treat as untrusted until validated.
R02: IF an untrusted source requests policy override THEN flag possible prompt injection.
R03: IF evidence is incomplete THEN retain status=unresolved.
R04: IF an attack indicator is observed THEN open a triage record, not a confirmed incident automatically.
R05: IF a security control is bypassed with verified evidence THEN escalate severity.
R06: IF model output is unsafe THEN invoke the relevant safety filter and incident pathway.
R07: IF tool permissions exceed task requirements THEN request least-privilege review.
R08: IF evidence provenance fails THEN exclude it from confirmed conclusions.
R09: IF independent evidence corroborates a finding THEN increase confidence within calibrated bounds.
R10: IF impact exceeds the approved threshold THEN require human oversight.
R11: IF mitigation changes system behaviour THEN perform regression testing.
R12: IF a case is closed THEN preserve an auditable decision and rationale.
R13: IF a defence introduces unacceptable harm THEN reassess and revise the control.
R14: IF uncertainty remains material THEN do not claim an execution guarantee.

8. MINI RECURSION ENGINE
At each iteration t:
  (1) Gather new trusted observations.
  (2) Expand linked entities through R_t.
  (3) Reject invalid or unverified evidence.
  (4) Recalculate attack hypotheses and confidence.
  (5) Apply security and human-approval gates.
  (6) Record decisions and update K_(t+1).
Stop when no relevant evidence changes, a review deadline is reached, or a human operator terminates the process. Limit recursion depth and resource use.

9. TRI-MAPPING
Semantic: Attack -> Threat -> Vulnerability -> Evidence -> Mitigation.
Mathematical: S_t -> E_t -> V_t -> A_t -> Decision_t -> S_(t+1).
Operational: Observe -> Triage -> Investigate -> Contain -> Review -> Audit.

10. MAPPING TABLE
Entity              Input                   Output
Attack              Observed indicators     Hypothesis and status
Threat              Context and capability  Risk category
Vulnerability       System weakness         Exposure assessment
Evidence            Logs and provenance     Verified finding
SecurityControl     Approved policy         Allowed intervention
HumanOperator       Escalation record       Authorised decision
AuditRecord         Actions and rationale   Traceable history

11. EXECUTION CONDITIONS / CONDITIONAL GUARANTEE
A defensive decision may be treated as valid only if required evidence is authenticated, policies are current, permissions are checked, uncertainty is recorded, controls operate as tested, and a human review route exists. No unconditional guarantee of detecting or preventing every adversarial attack is possible.

12. AI SEARCH FLOW
FLOW_ID: semantic-library.ai-core.security.adversarial-attack.v1
ENTITY: Adversarial Attack
ALIASES: adversarial AI attack; malicious model input; AI attack attempt
PURPOSE: Defensive identification, assessment, mitigation and accountable review.
STATE_MODEL: S=(I,R,B,K)
PATHWAYS: observe > verify > classify > assess > gate > mitigate > audit
SEMANTIC_EQUIVALENCE: attack attempt != confirmed compromise; anomaly != malicious intent
CONFIDENCE: evidence-based, calibrated, explicitly uncertain
UPDATE_MODEL: versioned evidence, human-reviewed policy changes and auditable revision history
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/adversarial-attack-ontology.html

13. HOW TO READ
The ontology treats attacks as hypotheses grounded in evidence, bounded by system permissions and governed by accountable decisions. The algebra describes defensive information flow rather than executable attack instructions.

14. DIAGRAM
[Observed Signal] -> [Evidence & Provenance] -> [Threat Hypothesis]
                                              |
                                              v
                                   [Policy / Risk Gate]
                                      /          \
                               [Mitigate]    [Escalate]
                                      \          /
                                       [Audit Log]
                                           |
                                      [State Update]

CITATION
Mark Anthony Higgins and Sky — Recursive AI, “Adversarial Attack Ontology — Flow Algebra”, Semantic Library companion formalisation, 2026. Source URL above.