Defence Mechanism Ontology

SEMANTIC LIBRARY — AI CORE — SECURITY ENTITIES
DEFENCE MECHANISM 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/defence-mechanism-ontology.html
Status: Original companion formalisation; source page title and attribution verified, embedded specifications unavailable in retrieved text.

1. PURPOSE
Represent a defence mechanism as a verifiable security control that reduces the likelihood or impact of a threat to an AI system. Distinguish designed controls, deployed controls and controls with demonstrated effectiveness.

2. ENTITY AND STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observations, threat signals, requests, telemetry, assessment evidence.
R_t = security policies, authorisation rules, control dependencies and response rules.
B_t = trust boundaries, permitted operations, risk tolerances and intervention limits.
K_t = known assets, threats, vulnerabilities, control inventory, provenance and audit history.
D = (id, type, owner, target_asset, threat_scope, trigger, action, verification, status, version).
status in {proposed, tested, deployed, degraded, disabled, retired}.

3. CORE FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | permitted(x, B_t) AND supported(x, K_t)}
D*_t = argmax_{d in V_t} Utility(d | I_t, R_t, B_t, K_t)
Utility(d) = expected_risk_reduction(d) - deployment_cost(d) - operational_harm(d)
I_(t+1) = update(I_t, observed_outcome(D*_t), audit_evidence)
K_(t+1) = reconcile(K_t, validated_evidence, control_version)
If V_t is empty, return HOLD_AND_ESCALATE; never infer that an untested control guarantees protection.

4. DEFENCE MECHANISM CLASSES
Preventive: access restriction, input validation, isolation, least privilege.
Detective: anomaly detection, integrity checks, security monitoring.
Responsive: quarantine, session revocation, rate limiting, incident containment.
Recovery: verified rollback, credential rotation, restoration from trusted state.
Assurance: audit logging, testing, independent review and periodic reassessment.
A mechanism may span classes, but each claimed function requires evidence.

5. ENTITY RELATIONSHIPS
DefenceMechanism --protects--> Asset
DefenceMechanism --mitigates--> Threat
Threat --exploits--> Vulnerability
DefenceMechanism --enforces--> SecurityControl
DefenceMechanism --operatesWithin--> SecurityBoundary
DefenceMechanism --requires--> Permission
DefenceMechanism --produces--> SecurityEvidence
DefenceMechanism --isEvaluatedBy--> SecurityAssessment
DefenceMechanism --mayTrigger--> SecurityIncidentResponse
DefenceMechanism --isAccountableTo--> SystemOwner

6. INFERENCE RULES
R01: IF threat credible AND asset exposed THEN assess applicable controls.
R02: IF control scope excludes asset THEN mark NOT_APPLICABLE.
R03: IF policy denies action THEN deny irrespective of estimated utility.
R04: IF required permission absent THEN block control execution and escalate.
R05: IF evidence unverified THEN do not assert control effectiveness.
R06: IF control test fails THEN set status=degraded and initiate review.
R07: IF monitoring detects a threshold breach THEN invoke approved response.
R08: IF response could cause greater harm THEN require authorised review.
R09: IF a trust boundary is crossed THEN revalidate identity and permission.
R10: IF control configuration changes THEN invalidate stale test attestations.
R11: IF incident is confirmed THEN preserve evidence and record containment.
R12: IF mitigation succeeds THEN measure residual risk, not zero risk.
R13: IF a dependency fails THEN evaluate fallback controls and safe state.
R14: IF a control is retired THEN remove its claimed coverage from assessments.

7. MINI RECURSION ENGINE
repeat until convergence or iteration_limit:
  observe current threats and control health
  expand applicable defensive candidates
  filter by boundaries, policy, permissions and evidence
  select approved action or HOLD_AND_ESCALATE
  execute only through authorised operational systems
  verify observed outcome; record provenance
  update risk estimate and control state
Stop on unsafe uncertainty, conflicting rules, exhausted budget or human stop request.

8. TRI-MAPPING
Conceptual: threat -> defence mechanism -> protected asset.
Formal: (Threat, Asset, Control) -> eligibility -> action -> evidence -> residual risk.
Operational: detect -> validate -> authorise -> apply -> verify -> log -> review.

9. MAPPING TABLE
Input observation       | I_t | telemetry, requests, alerts
Security rule           | R_t | policy and enforcement logic
Trust boundary          | B_t | limits on action and authority
Security knowledge      | K_t | assets, controls and evidence
Candidate control       | E_t | expanded defensive options
Permitted control       | V_t | admissible and supported option
Selected control        | D*_t | best approved response
Evidence update         | K_(t+1) | verified audit outcome

10. CONDITIONAL EXECUTION GUARANTEE
A control action is eligible only if its policy, permission, boundary and dependency predicates are satisfied. This is a logical eligibility condition, NOT a guarantee of real-world security or successful mitigation. Assurance requires independently observed tests and operational monitoring.

11. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/defence-mechanism-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/defence-mechanism-ontology.html
PURPOSE: Find, relate and evaluate AI defence mechanisms and their evidence.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: DefenceMechanism, Threat, Vulnerability, Asset, SecurityControl, SecurityBoundary, Permission, SecurityEvidence, SecurityAssessment, SecurityIncident, SystemOwner.
PATHWAYS: observe > classify > match > authorise > act > verify > update.
MINI_RECURSION_ENGINE: bounded observe/filter/act/verify cycle.
INFERENCE_RULES: R01-R14.
CONFIDENCE: derived from test quality, provenance, recency and environmental fit; unknown when evidence absent.
SEMANTIC_EQUIVALENCE: defence mechanism ~ defensive control when context matches; not identical to a guarantee of safety.
FLOW_HASH: compute SHA-256 from final UTF-8 publication bytes; not precomputed.
UPDATE_MODEL: version changes require reassessment of scope, evidence and residual risk.

12. HOW TO READ / IMPLEMENTS
Treat each entity as a typed node and each relation as a validated edge. Implement rules as explicit predicates, preserve denied/unknown outcomes, and log provenance. The equations define a conceptual selection process rather than executable software. This file does not itself deploy or test a security control.

13. ATTRIBUTION AND SCOPE
Original Flow Algebra companion text, not a verbatim transcription of embedded page specifications. Open research sharing with source citation requested.