Attack Vector Ontology

SEMANTIC LIBRARY — AI CORE / SECURITY ENTITIES
ATTACK VECTOR 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/attack-vector-ontology.html
Status: Original companion formalisation; embedded source specifications not accessible in retrieved page text.

1. PURPOSE
Represent an attack vector as a typed pathway by which a threat actor or hazardous process could reach an asset through an exposed surface, vulnerability or trust boundary. Support defensive classification, evidence-based risk assessment, prevention and audit. A vector is a possible pathway, not proof of exploitation.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t: observed inputs, alerts, system inventory, telemetry and provenance.
R_t: entity relationships and rules governing access, exposure and attack paths.
B_t: trust boundaries, authorisation, policies and permissible responses.
K_t: verified knowledge, known weaknesses, mitigations and uncertainty.

AttackVector v = (id, actor?, entry_surface, preconditions, weakness?, target, path, evidence, likelihood, impact, controls, status).
Optional actor or weakness must not be invented where unknown.

3. ENTITY GRAPH
Entities: AttackVector, ThreatActor, EntryPoint, AttackSurface, Asset, Vulnerability, TrustBoundary, Credential, Permission, SecurityControl, DetectionEvent, Evidence, SecurityIncident, RiskAssessment, Mitigation, HumanReviewer.
Relationships:
ThreatActor --may_use--> AttackVector
AttackVector --enters_via--> EntryPoint
EntryPoint --belongs_to--> AttackSurface
AttackVector --may_exploit--> Vulnerability
AttackVector --targets--> Asset
AttackVector --may_cross--> TrustBoundary
SecurityControl --mitigates--> AttackVector
DetectionEvent --supports_assessment_of--> AttackVector
SecurityIncident --may_involve--> AttackVector
HumanReviewer --reviews--> RiskAssessment
All relationships require source, timestamp and confidence metadata.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | valid_source(x) AND within_scope(x, B_t)}
A_t = {v in V_t | type(v) = AttackVector}
For each v:
  feasible(v) = preconditions_satisfied(v, K_t) AND reachable(v, R_t)
  risk(v) = likelihood(v | evidence, controls) * impact(v)
  residual_risk(v) = risk_after_controls(v, K_t)
Candidate response:
  x* = argmax_x P(x | I_t, R_t, B_t, K_t)
subject to policy_permitted(x, B_t), authorised(x) and risk_bounded(x).
S_(t+1) = update(S_t, observations, assessment, approved_response).
Likelihood and impact require declared scales; their product is not a calibrated probability unless validated.

5. PATHWAY
Observe -> Validate provenance -> Identify entry surface -> Map trust boundaries -> Check preconditions -> Associate possible weakness -> Assess exposure -> Estimate risk -> Select defensive control -> Obtain required approval -> Verify control -> Record outcome.
Unknown preconditions produce 'unconfirmed', not 'confirmed attack'.

6. INFERENCE RULES
R01: IF external input reaches a privileged component THEN flag boundary review.
R02: IF an entry point is externally reachable THEN mark exposure as present, not exploitation.
R03: IF a known weakness matches the component and version THEN link candidate vulnerability.
R04: IF matching evidence is absent THEN retain attack status as unconfirmed.
R05: IF source provenance fails THEN quarantine the claim for verification.
R06: IF permissions exceed operational need THEN recommend least-privilege review.
R07: IF a control blocks the relevant pathway THEN lower assessed residual exposure only after verification.
R08: IF suspicious events repeat THEN correlate by time, asset and source without assuming a common actor.
R09: IF confidentiality, integrity or availability may be affected THEN initiate impact assessment.
R10: IF severity exceeds policy threshold THEN escalate to authorised human oversight.
R11: IF proposed action crosses an authorisation boundary THEN deny execution pending approval.
R12: IF an incident is confirmed THEN preserve evidence and start the approved response process.
R13: IF evidence conflicts THEN record competing hypotheses and uncertainty.
R14: IF a mitigation changes system state THEN retest and update the risk record.

7. MINI RECURSION ENGINE
At iteration t:
  (a) expand candidate vector relationships;
  (b) reject unsupported or out-of-scope claims;
  (c) compare evidence against preconditions;
  (d) update likelihood, impact and residual risk;
  (e) select authorised defensive response;
  (f) record evidence, reviewer and version;
  (g) stop if stable, reviewed or iteration budget exhausted.
Stop conditions: no material change, confidence insufficient, human escalation required, or t >= t_max.
No automatic exploit testing or privilege escalation is implied.

8. TRI-MAPPING
Semantic: attack vector = potential route from entry point to target.
Structural: typed nodes and edges with provenance and trust boundaries.
Operational: validated observations -> risk classification -> defensive decision -> audit record.

9. MAPPING TABLE
EntryPoint -> attack surface -> exposure discovery
Vulnerability -> weakness relation -> precondition checking
TrustBoundary -> policy boundary -> crossing validation
SecurityControl -> mitigation edge -> prevention or detection
Evidence -> provenance relation -> confidence assessment
RiskAssessment -> impact/likelihood relation -> prioritisation
HumanReviewer -> authority relation -> escalation and approval

10. EXECUTION CONDITIONS AND GUARANTEE
A response is executable only when inputs are validated, scope and authorisation are confirmed, relevant policies pass, and required human approvals exist. The system guarantees only that these declared checks are applied when correctly implemented; it does not guarantee the absence of vulnerabilities or incidents. Fail closed on missing authorisation; preserve uncertainty on missing evidence.

11. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/attack-vector-ontology.html
CITATION_BACKLINK: source URL above
PURPOSE: Discover, classify and reason defensively about AI security attack vectors.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: AttackVector, ThreatActor, EntryPoint, Asset, Vulnerability, TrustBoundary, SecurityControl, Evidence, RiskAssessment, SecurityIncident.
PATHWAYS: Observe > Validate > Map > Assess > Mitigate > Verify > Audit.
MINI_RECURSION_ENGINE: bounded evidence-based state updates with escalation.
INFERENCE_RULES: R01-R14.
CONFIDENCE: evidence-linked; distinguish observed, inferred and unknown.
SEMANTIC_EQUIVALENCE: attack route; intrusion pathway; threat entry path (context-dependent, not universally identical).
FLOW_HASH: compute SHA-256 from the published UTF-8 file bytes at deployment; no hash asserted here.
UPDATE_MODEL: versioned changes, timestamp, reviewer, evidence provenance.

12. HOW TO READ
Read each arrow as a typed relationship, each IF/THEN as a conditional inference, and each update as a bounded revision of knowledge. This is a defensive ontology and not an attack procedure.

13. EXAMPLE (DEFENSIVE)
An externally accessible API endpoint receives an unexpected request. The entry point is verified, but no exploit evidence is established. The system records a candidate attack vector, checks authentication and rate-limiting controls, escalates if required and keeps incident status 'unconfirmed' until evidence supports a stronger conclusion.

LICENCE NOTE
Companion research text prepared for the Semantic Library. Retain source attribution and apply the published Kireth Research licence terms where applicable.