AI Security Entity Ontology

KIRETH RESEARCH — SEMANTIC LIBRARY
AI SECURITY ENTITY 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/ai-security-entity-ontology.html
Status: Original companion formalisation. The public page heading and metadata were verified; embedded specifications were not accessible in the retrieved page text. This is not a verbatim transcription.

1. PURPOSE
Represent AI security entities as identifiable, bounded and auditable objects; evaluate threats, vulnerabilities, permissions and controls; and permit actions only where applicable security constraints hold.

2. ENTITY DEFINITION
AI_SECURITY_ENTITY := (id, kind, owner, asset, boundary, trust_level, permissions, controls, evidence, status, provenance)
kind ∈ {asset, identity, principal, credential, permission, policy, threat, vulnerability, attack_surface, event, incident, control, audit_record}
status ∈ {unverified, verified, monitored, restricted, quarantined, revoked}
Each entity has a stable identifier, an evidence provenance record and an explicit security boundary.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed identities, events, assets, requests and security signals
R_t = security rules, authorisation relations and trust dependencies
B_t = trust boundaries, data boundaries and execution restrictions
K_t = validated security knowledge, policies and prior findings
E_t = expand(I_t, R_t)
V_t = {x ∈ E_t | boundary_ok(x,B_t) ∧ policy_ok(x,K_t) ∧ evidence_ok(x)}
a*_t = argmax_{a ∈ V_t} P(a | I_t,R_t,B_t,K_t)
I_(t+1) = update(I_t, a*_t, observed_result)
If V_t is empty, abstain from execution and request review.

4. IMPLEMENTS
Input: asset/request/event plus identity and policy context.
Output: allow, deny, quarantine, escalate or request_more_evidence, with reason and audit trail.
Preconditions: known policy version; verified identity for privileged actions; trustworthy evidence sources.
Postconditions: action status and evidence are recorded; prohibited operations remain blocked.

5. SECURITY FLOW
F0 RECEIVE: normalise input; assign event and correlation identifiers.
F1 IDENTIFY: bind principal, target asset, resource owner and declared purpose.
F2 VERIFY: validate identity, credential freshness, provenance and integrity.
F3 MAP: resolve role, permission, resource and policy relationships.
F4 ASSESS: evaluate threat, vulnerability, impact, likelihood and uncertainty.
F5 FILTER: reject actions outside boundaries or inconsistent with mandatory policy.
F6 DECIDE: choose least-privilege permitted action, or deny/escalate.
F7 EXECUTE: enforce through a separate trusted control point; no model output alone grants access.
F8 RECORD: preserve decision, policy version, evidence references and outcome.
F9 REVIEW: incorporate verified findings into future assessment without weakening mandatory constraints.

6. ENTITY RELATIONSHIPS
principal --requests--> action
principal --holds--> credential
credential --authenticates--> principal
role --grants--> permission
permission --authorises--> action_on_asset
asset --belongs_to--> owner
asset --resides_within--> trust_boundary
threat --targets--> asset
vulnerability --affects--> asset
control --mitigates--> threat_or_vulnerability
event --may_indicate--> incident
incident --requires--> response
policy --constrains--> action
audit_record --documents--> decision

7. FORMAL RULES
R01: unknown_identity ∧ privileged_action => DENY.
R02: invalid_or_expired_credential => DENY.
R03: no_explicit_permission => DENY (default deny).
R04: action_crosses_boundary ∧ no_valid_exception => DENY.
R05: verified_policy_violation => DENY + LOG.
R06: suspected_compromise => QUARANTINE + ESCALATE, subject to authorised containment controls.
R07: evidence_missing_for_high_impact_action => REQUEST_MORE_EVIDENCE.
R08: risk_above_approved_threshold => ESCALATE or DENY according to policy.
R09: conflicting_policies => apply mandatory higher-priority rule; otherwise ESCALATE.
R10: granted_permission => limit scope and duration to minimum necessary.
R11: security_event => record provenance, timestamp and correlation ID.
R12: revoked_credential => invalidate dependent sessions where supported.
R13: failed_control => trigger fail-safe response and alert responsible operator.
R14: recovery_request => require authorised review and successful revalidation.

8. RISK AND CONFIDENCE
risk(a) = likelihood(a) × impact(a), when scales are explicitly defined and calibrated.
confidence(finding) = calibrated_evidence_score(finding), not model fluency.
Unknown likelihood or impact must be recorded as unknown; do not substitute fabricated numbers.
An uncertainty flag may force manual review irrespective of the nominal risk score.

9. MINI RECURSION ENGINE
At iteration t:
  gather newly authorised evidence;
  expand linked entities and security relationships;
  apply rules and boundary checks;
  compare findings with previous state;
  stop if no material change, budget exhausted, or escalation required;
  otherwise update K_(t+1) using validated evidence only.
Termination requires a bounded iteration count and monotonic retention of mandatory constraints.

10. TRI-MAPPING
Semantic: principal, asset, threat, control, permission, policy, incident.
Structural: typed nodes and relations in a security entity graph.
Operational: identity verification -> authorisation -> risk check -> enforcement -> audit.

11. MAPPING TABLE
Entity                 Input                       Transformation                  Output
Identity               credential / context        verify                          verified / rejected
Permission             principal + asset + action  authorise                      allow / deny
Threat                 signals + context           classify with uncertainty      finding / review
Vulnerability          evidence + asset            validate applicability         confirmed / unverified
Security Control       policy + finding            select authorised mitigation  enforce / escalate
Audit Record           decision + evidence         preserve provenance           reviewable record

12. EXECUTION GUARANTEE (CONDITIONAL)
Given complete policy coverage, correct enforcement, trustworthy identity verification and intact control points, an action may execute only when all mandatory checks pass. This is a conditional design invariant, not a guarantee of absolute security. Fail closed when prerequisites are unmet; human review is required for unresolved high-impact cases.

13. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/ai-security-entity-ontology.html
CITATION_BACKLINK: source URL above
PURPOSE: Explain and retrieve the AI Security Entity ontology and its operational relationships.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: identity, asset, permission, policy, threat, vulnerability, control, incident, audit_record
PATHWAYS: observe -> verify -> map -> assess -> constrain -> decide -> enforce -> audit
MINI_RECURSION_ENGINE: bounded evidence expansion and validated state update
INFERENCE_RULES: R01–R14
CONFIDENCE: evidence-calibrated; unknown when uncalibrated
SEMANTIC_EQUIVALENCE: security entity ≈ typed security-relevant object; not equivalent to a security guarantee
FLOW_HASH: calculate from published UTF-8 file bytes at deployment; not precomputed here
UPDATE_MODEL: versioned policy, provenance, reviewed changes and rollback

14. HOW TO READ
Read the state tuple as current evidence, relationships, boundaries and validated knowledge. Follow F0–F9 to trace a request. Apply R01–R14 as normative constraints, and treat all probabilistic scores as advisory unless validated by an independent enforcement system.

15. TEXT DIAGRAM
[Input/Event] -> [Identity + Asset] -> [Evidence Verification]
                                         |
                                         v
[Audit] <- [Decision] <- [Policy + Risk + Boundary Checks]
                |                        |
                v                        v
       [Trusted Enforcement]        [Deny / Escalate]
                |
                v
        [Monitor + Review] -> [Validated State Update]

16. LIMITATIONS
This file defines a conceptual ontology and reasoning workflow; it is not executable access-control software, a certification, or a substitute for threat modelling and security testing. Policy and legal applicability must be established in the actual deployment context.

OPEN RESEARCH: Free to use and adapt with citation to the authors and source, subject to the published Open Research Licence terms.