Threat Actor Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SECURITY ENTITIES
THREAT ACTOR ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | 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/threat-actor-ontology.html
Status: Original companion formalisation. The page title and attribution are visible; embedded specifications were not retrievable, so this is not a verbatim transcription.

1. PURPOSE
Represent a threat actor as an evidence-grounded security entity with possible intent, capability, opportunity, access, observed behaviour and uncertainty. Support defensive detection, attribution caution, risk evaluation and accountable response.

2. ENTITY AND STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed indicators and source records at time t
R_t = typed relations between actors, assets, events and controls
B_t = trust, policy, temporal and evidential boundaries
K_t = validated knowledge, hypotheses and confidence metadata

ThreatActor A = (actor_id, actor_type, intent_hypotheses, capability_hypotheses, access_scope, activity, attribution_confidence, provenance, status)
Actor types may include individual, group, automated agent or unknown. Labels are hypotheses unless corroborated.

3. ENTITY GRAPH
Nodes: ThreatActor, IdentityClaim, Behaviour, SecurityEvent, Indicator, TargetAsset, Vulnerability, AttackSurface, Credential, SecurityControl, Incident, Evidence, Source, RiskAssessment, ResponseAction, HumanReviewer.
Relations:
ThreatActor --may_target--> TargetAsset
ThreatActor --may_exploit--> Vulnerability
ThreatActor --associated_with--> SecurityEvent
SecurityEvent --has_indicator--> Indicator
Indicator --supported_by--> Evidence
Evidence --originates_from--> Source
SecurityControl --mitigates--> RiskAssessment
HumanReviewer --reviews--> AttributionClaim
ResponseAction --requires_authorisation--> HumanReviewer
All attribution edges carry confidence, timestamp and provenance.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | valid_source(x) AND within_scope(x) AND policy_permits(x)}
H_t = generate_actor_hypotheses(V_t, K_t)
Q_t(h) = evidence_support(h) - contradiction_penalty(h) - uncertainty_penalty(h)
h*_t = argmax_{h in H_t} Q_t(h), subject to B_t
D_t = choose_defensive_action(h*_t, risk_t, B_t)
I_{t+1} = update(I_t, verified_observations(D_t))
K_{t+1} = revise(K_t, V_t, reviewer_feedback)
No hypothesis is treated as established identity solely because it has the highest score.

5. INFERENCE RULES
R01: If an indicator lacks provenance, mark it unverified.
R02: If several indicators share one original source, do not count them as independent corroboration.
R03: If behaviour matches a known technique, infer a technique hypothesis, not actor identity.
R04: If evidence contradicts attribution, reduce confidence and preserve the contradiction.
R05: If a credential is used unexpectedly, investigate compromise without presuming the account owner is the actor.
R06: If observed access crosses a trust boundary, raise the event for security review.
R07: If a vulnerability is relevant and reachable, assess exposure; do not presume exploitation.
R08: If intent cannot be observed directly, record it as a hypothesis.
R09: If impact is high and evidence is uncertain, permit proportionate protective controls while withholding definitive attribution.
R10: If containment changes evidence, preserve an audit record before and after the change where feasible.
R11: If personal information is involved, apply privacy and retention constraints.
R12: If a response action exceeds delegated authority, require human approval.
R13: If indicators are later invalidated, retract dependent conclusions.
R14: If risk is controlled and closure criteria are met, close the incident while retaining traceability.

6. MINI RECURSION ENGINE
At each iteration:
(a) ingest authorised evidence;
(b) validate timestamps, provenance and integrity;
(c) expand related events and assets;
(d) update actor hypotheses;
(e) assess likelihood, impact and uncertainty;
(f) propose defensive action;
(g) apply policy and authorisation gates;
(h) record results and stop on stability, budget limit or human stop.
Stop condition: delta(K_t, K_{t+1}) <= epsilon OR iterations >= N OR authorisation revoked.

7. TRI-MAPPING
Semantic: actor, motive hypothesis, capability, evidence, target and response.
Structural: typed graph nodes, relations, provenance and constraint boundaries.
Operational: ingest -> validate -> correlate -> assess -> review -> mitigate -> audit.

8. MAPPING TABLE
Concept | Graph representation | Operational test
Threat actor | ThreatActor node | unique scoped identifier
Indicator | Indicator -> Evidence | integrity and provenance verified
Attribution | AttributionClaim edge | independent corroboration and reviewer status
Capability | CapabilityHypothesis | observed support and uncertainty
Target | TargetAsset node | ownership and asset inventory match
Risk | RiskAssessment node | likelihood/impact with assumptions
Control | SecurityControl node | measured effectiveness
Response | ResponseAction node | approval and audit trail

9. EXECUTION CONDITIONS AND GUARANTEE
A defensive decision is executable only if: sources are admissible; constraints hold; requested access is authorised; policy permits the action; and required human review is complete.
Guarantee is conditional: the flow guarantees traceable rule evaluation when its preconditions and implementation checks hold. It does NOT guarantee correct actor attribution, complete threat detection or zero security risk.

10. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/threat-actor-ontology.html
CITATION_BACKLINK: source URL above
PURPOSE: evidence-grounded threat actor modelling for defensive security reasoning
STATE_MODEL: S_t=(I_t,R_t,B_t,K_t)
ENTITIES: ThreatActor; SecurityEvent; Indicator; Evidence; TargetAsset; Vulnerability; SecurityControl; HumanReviewer
PATHWAYS: observe > validate > correlate > hypothesise > assess > approve > respond > audit
MINI_RECURSION_ENGINE: iterate evidence validation and hypothesis revision until stable or halted
INFERENCE_RULES: R01-R14
CONFIDENCE: calibrated per claim; unknown where evidence is insufficient
SEMANTIC_EQUIVALENCE: adversary entity / suspected threat actor / security actor hypothesis (context-dependent, not always identical)
FLOW_HASH: compute SHA-256 from final deployed UTF-8 file; no hash asserted here
UPDATE_MODEL: versioned changes, timestamped evidence, reviewer-approved corrections

11. HOW TO READ
Read the state tuple as current knowledge and boundaries. Follow graph edges from observations to evidence before assessing hypotheses. Treat all actor attribution as provisional unless independently established. Execute only defensive actions permitted by policy.

12. TEXT DIAGRAM
[Observations] -> [Evidence validation] -> [Event correlation]
                                              |
                                              v
                                      [Actor hypotheses]
                                              |
                                      [Risk assessment]
                                              |
                                     [Policy / human gate]
                                              |
                                      [Defensive response]
                                              |
                                      [Audit and update]

LICENCE NOTE
Prepared as a companion to Kireth Research's open research work. Retain attribution and source backlink when redistributing; consult the published licence for exact terms.