Security Threat Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SECURITY ENTITIES
SECURITY THREAT 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/security-threat-ontology.html
Status: Original companion formalisation. The accessible page confirms the title and attribution; its embedded technical specifications were not accessible. This is not a verbatim transcription.

1. PURPOSE
Represent a security threat as a contextual, evidence-linked possibility of an adverse event affecting an AI system, asset, user, process or boundary. Distinguish threat, vulnerability, exposure, observed incident and proven compromise. Support defensible assessment, proportional controls, escalation and auditable reassessment.

2. ENTITY DEFINITIONS
Threat T = (id, actor_or_origin, capability, intent_or_mechanism, target, vector, conditions, evidence, status, time).
Asset A = (id, owner, criticality, confidentiality, integrity, availability).
Vulnerability V = (id, affected_asset, weakness, preconditions, severity, verification).
Exposure X = (asset, reachable_surface, context, duration).
Control C = (id, preventive_or_detective_or_corrective, scope, effectiveness, owner).
Observation O = (id, source, timestamp, integrity, confidence, finding).
Risk R = (threat, asset, likelihood, impact, uncertainty, residual_risk).
Incident N = (id, observed_event, impact, confirmed_status, response).

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = current observations, alerts, requests and context.
R_t = authorised rules, threat taxonomy, control catalogue and assessment logic.
B_t = trust boundaries, permissions, asset scope, legal and safety constraints.
K_t = verified knowledge, evidence provenance, prior findings and unresolved uncertainty.
ThreatState_t ∈ {unassessed, suspected, substantiated, contained, mitigated, dismissed, monitoring}.
No state label alone establishes that a breach occurred.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x ∈ E_t | in_scope(x,B_t) ∧ provenance_valid(x,K_t) ∧ constraints_satisfied(x,B_t)}
Candidate_t = argmax_{x ∈ V_t} P(x | I_t,R_t,B_t,K_t)
Assessment_t = assess(Candidate_t, likelihood, impact, uncertainty, evidence)
Decision_t = gate(Assessment_t, authority, constraints, human_review)
I_(t+1) = update(I_t, Decision_t, new_observations)
K_(t+1) = reconcile(K_t, validated_evidence, Decision_t)
If V_t = ∅, return INSUFFICIENT_EVIDENCE or OUT_OF_SCOPE; do not fabricate a threat.
The argmax is a ranking device, not a proof of probability calibration or causality.

5. THREAT ASSESSMENT
Applicable(T,A) = target_matches(T,A) ∧ preconditions_plausible(T,A).
Exploitable(T,V,X) requires relevant weakness, exposure and credible mechanism.
Likelihood(T,A) = calibrated_estimate(evidence, exposure, capability, controls, uncertainty).
Impact(T,A) = consequence_estimate(asset_criticality, plausible_outcomes).
RiskScore = likelihood × impact only when both are on compatible defined scales.
ResidualRisk = reassess(RiskScore, control_effectiveness, remaining_exposure).
Missing data must be recorded as unknown, never silently assigned zero.

6. ENTITY RELATIONSHIPS
Threat --targets--> Asset
Threat --may_exploit--> Vulnerability
Exposure --increases_access_to--> Asset
Observation --supports_or_refutes--> ThreatHypothesis
Control --mitigates--> ThreatOrVulnerability
RiskAssessment --evaluates--> Threat × Asset × Context
Incident --may_realise--> Threat
HumanOperator --authorises--> ResponseAction
AuditRecord --documents--> AssessmentAndDecision

7. INFERENCE RULES
R01: Verified evidence + credible mechanism + relevant asset => substantiated threat hypothesis.
R02: Unverified alert => suspected only; request corroboration.
R03: Vulnerability without applicable threat => weakness, not confirmed attack.
R04: Threat without observed harm => risk, not incident.
R05: Observed harm with verified causal linkage => incident candidate for investigation.
R06: Missing asset ownership => escalate ownership determination before privileged response.
R07: Control effectiveness uncertain => retain residual-risk uncertainty.
R08: Boundary violation detected => contain within authorised scope and notify responsible operator.
R09: Conflicting evidence => preserve both claims and request adjudication.
R10: Elevated impact or uncertainty => human review before irreversible action.
R11: Mitigation verified => update risk, do not automatically mark threat eliminated.
R12: Evidence disproves hypothesis => dismiss with documented rationale.
R13: Repeated observations => correlate only with temporal and provenance checks.
R14: Expired evidence => reassess before reuse.

8. MINI RECURSION ENGINE
function AssessThreat(S_t):
  candidates := expand(S_t.I, S_t.R)
  candidates := filter(candidates, S_t.B, S_t.K)
  if empty(candidates): return (S_t, INSUFFICIENT_EVIDENCE)
  hypothesis := rank(candidates, evidence_quality, applicability, risk)
  result := evaluate(hypothesis, uncertainty, controls)
  action := require_authority_and_human_review_if_needed(result)
  S_next := update_and_log(S_t, result, action)
  if stopping_condition(S_next): return (S_next, result)
  return AssessThreat(S_next) only on new evidence, bounded depth and budget
Termination: evidence exhausted, stable assessment, time limit, or authorised escalation.

9. HOW TO READ THE FLOW
Input evidence is expanded into candidate threat hypotheses; boundary and provenance checks eliminate unsupported candidates; risk and uncertainty are evaluated; permitted actions are selected; results and evidence are recorded for the next cycle.

10. TRI-MAPPING
Semantic: Threat, Asset, Vulnerability, Control, Observation, Incident, Risk.
Mathematical: sets, predicates, ranking, uncertainty, state transitions.
Operational: ingest → verify → correlate → assess → authorise → mitigate → audit → reassess.

11. MAPPING TABLE
Input alert            -> I_t          -> candidate observation
Threat catalogue       -> R_t          -> classification rules
Trust boundary         -> B_t          -> permitted evaluation scope
Verified evidence      -> K_t          -> substantiation
Threat hypothesis      -> E_t          -> candidate explanation
Applicable hypothesis  -> V_t          -> admissible assessment
Risk decision          -> Decision_t   -> response or escalation
Audit outcome          -> K_(t+1)     -> updated provenance and status

12. EXECUTION CONDITIONS AND GUARANTEE
Conditional guarantee: if inputs, rules, boundaries and evidence are valid, and authorised decision gates are correctly enforced, the procedure produces a traceable assessment or an explicit insufficient-evidence state. It does NOT guarantee complete detection, correct probability estimates, absence of compromise or prevention of harm.
Invariants: no unauthorised action; no promotion of speculation to fact; no silent evidence deletion; no irreversible action without required approval; every status change has provenance.

13. AI SEARCH FLOW
FLOW_ID: security-threat-ontology-v1
ENTITY: Security Threat
DOMAIN: AI Core > Entity Graph > Security Entities
PURPOSE: Identify, classify and assess security threats under evidence and authority constraints.
INPUTS: threat_description, asset, exposure, vulnerability, observations, controls, context
OUTPUTS: threat_hypothesis, status, risk, uncertainty, evidence_links, permitted_next_step
PATHWAYS: identify > validate > classify > assess > review > respond > audit > reassess
SEMANTIC_EQUIVALENCE: security threat; threat hypothesis; adversarial risk; attack possibility
NON_EQUIVALENCE: threat != vulnerability; threat != incident; suspicion != confirmation
CONFIDENCE: derived from source quality, corroboration, applicability and calibration
UPDATE_MODEL: re-evaluate when assets, evidence, controls or threat conditions change
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/security-threat-ontology.html
FLOW_HASH: to be calculated from final published file bytes by publishing pipeline

14. EXAMPLE
An anomalous login alert is an observation, not proof of intrusion. Check log integrity, account scope, location/context, known false positives and additional evidence. If substantiated, assess exposure and impact, notify the authorised operator, apply permitted containment and retain an audit record. If unresolved, mark suspected and continue monitoring.

15. ATTRIBUTION
Mark Anthony Higgins — Kireth Research / Semantic Library
Sky — Recursive AI
Original companion Flow Algebra formalisation; cite the source URL above when reusing.