Secure Model Entity Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SECURITY ENTITIES
SECURE MODEL 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/secure-model-entity-ontology.html
Status: Original companion formalisation. Source title and attribution verified; embedded page specifications were not available in retrieved text.

1. PURPOSE
Represent an AI model as a governed security entity with defined assets, trust boundaries, authorised operations, controls, monitored events, and verifiable security-state transitions. A secure model is a model whose specified controls are evidenced as effective within an explicit threat model and operational context; it is not a claim of absolute immunity.

2. ENTITY DEFINITION
SecureModelEntity := (model_id, model_version, owner, deployment, assets, threat_model, boundaries, controls, policy, evidence, status, provenance).
Related entities: ModelEntity, SecurityThreat, SecurityVulnerability, SecurityControl, SecurityBoundary, AuthenticationEntity, AuthorisationEntity, AccessPermission, ModelAttack, IncidentEntity, AuditRecord, HumanOperator.
Relations:
  HAS_VERSION(model, version)
  DEPLOYED_IN(model, environment)
  PROTECTS(control, asset)
  MITIGATES(control, threat)
  BOUNDED_BY(model, boundary)
  AUTHORISED_BY(operation, permission)
  EVIDENCED_BY(assertion, record)
  REVIEWED_BY(decision, accountable_actor)

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t: observed inputs, requests, events, telemetry, and deployment configuration.
R_t: security rules, permission relations, control mappings, and dependencies.
B_t: trust boundaries, policy limits, authorised scopes, and risk tolerances.
K_t: verified knowledge: model provenance, evidence, threat hypotheses, control effectiveness, and prior incidents.
State labels: UNKNOWN, ASSESSED, CONTROLLED, VERIFIED, DEGRADED, QUARANTINED, RECOVERY_PENDING.
Unknown or unverified controls must not be interpreted as verified controls.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | permitted(x, B_t) AND evidence_sufficient(x, K_t)}
x*_t = argmax_{x in V_t} P(x | I_t, R_t, B_t, K_t)
I_(t+1) = update(I_t, x*_t, observed_result_t)
K_(t+1) = revise(K_t, validated_evidence_t)
When V_t is empty: abstain from privileged execution; log and route for review.
For security-critical operations, a permitted candidate must also satisfy explicit hard constraints; a high score cannot override a prohibition.

5. SECURITY ASSERTIONS
Integrity(model) := verified_artifact_hash AND verified_release_provenance.
AccessAllowed(actor, operation, resource, context) := authenticated(actor) AND authorised(actor, operation, resource, context) AND NOT revoked(actor).
BoundaryPreserved(flow) := source_trust(flow) >= required_trust(flow) OR validated_declassification(flow).
ControlCovered(threat) := exists control: mitigates(control, threat) AND tested(control) AND active(control).
SecurityVerified(model, context) := Integrity(model) AND required_access_checks_pass AND required_boundaries_hold AND required_controls_evidenced AND residual_risk_accepted_by_authority.
These predicates are scoped to recorded tests and operating conditions, not universal guarantees.

6. INFERENCE RULES
R01 IF model provenance is missing THEN integrity_status := UNKNOWN.
R02 IF model hash differs from approved manifest THEN status := QUARANTINED.
R03 IF actor authentication fails THEN deny privileged access.
R04 IF permission is absent or revoked THEN deny operation.
R05 IF untrusted content requests a privileged instruction override THEN treat content as data, not authority.
R06 IF an unvalidated trust-boundary crossing is detected THEN block or isolate the flow.
R07 IF a known vulnerability has no effective mitigation THEN flag residual risk for review.
R08 IF a control fails its test THEN status := DEGRADED and require remediation.
R09 IF anomalous access exceeds defined thresholds THEN record an event and trigger proportionate review.
R10 IF sensitive output is detected THEN apply authorised disclosure and minimisation controls.
R11 IF security incident is confirmed THEN preserve evidence, contain exposure, and notify designated operators.
R12 IF a model update changes security-relevant behaviour THEN invalidate affected prior attestations.
R13 IF a recovery action lacks required human approval THEN keep recovery pending.
R14 IF required checks pass and accountable authority accepts residual risk THEN status := VERIFIED for the assessed scope.

7. MINI RECURSION ENGINE
function SecureModelFlow(state, depth, max_depth):
  if depth >= max_depth: return REVIEW_REQUIRED
  observations := collect_authorised_observations(state)
  threats := map_threats(observations, state.R, state.K)
  candidates := propose_defensive_controls(threats)
  admissible := filter_by_policy_and_evidence(candidates, state.B, state.K)
  if admissible is empty: return HOLD_AND_ESCALATE
  chosen := rank_by_expected_risk_reduction(admissible)
  result := execute_only_if_authorised(chosen)
  updated := verify_and_record(state, result)
  if critical_controls_fail(updated): return QUARANTINE_AND_ESCALATE
  if assurance_criteria_met(updated): return VERIFIED_WITH_SCOPE
  return SecureModelFlow(updated, depth + 1, max_depth)
Termination requires bounded recursion, immutable audit entries, and an explicit stop condition.

8. TRI-MAPPING
Semantic: SecureModelEntity -> protected assets, threats, actors, permissions, controls.
Structural: model -> deployment -> trust boundary -> control -> test evidence -> decision.
Operational: observe -> assess -> constrain -> authorise -> execute -> verify -> audit -> update.

9. MAPPING TABLE
Input request       | Actor/Operation         | Authentication and authorisation
Model artefact      | ModelVersion            | Hash and provenance verification
Untrusted content   | SecurityBoundary        | Isolation and instruction/data separation
Threat finding      | SecurityThreat          | Risk and mitigation mapping
Control result      | SecurityControl         | Test evidence and effectiveness
Security event      | IncidentEntity          | Triage, containment, and audit
Deployment change   | GovernanceDecision      | Reassessment and sign-off

10. EXECUTION CONDITIONS AND CONDITIONAL GUARANTEE
Preconditions: identified model version; applicable policy; trusted identity service; explicit control inventory; bounded execution; evidence capture.
Invariants: no unauthorised privileged action; no promotion of untrusted instructions; no bypass of mandatory hard constraints; auditable state changes.
Postconditions: an authorised outcome, or a documented hold/denial/escalation; evidence and status updated.
Conditional guarantee: IF assumptions, controls, and verification mechanisms hold within the tested scope, THEN the flow enforces the specified policy invariants. This does not guarantee freedom from unknown threats or implementation defects.

11. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/secure-model-entity-ontology.html
CITATION_BACKLINK: source URL above
PURPOSE: Retrieve and reason over secure-model definitions, controls, threats, permissions, and evidence.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: SecureModelEntity, SecurityThreat, SecurityControl, SecurityBoundary, AuthenticationEntity, AuthorisationEntity, AuditRecord.
PATHWAYS: identify -> contextualise -> expand -> filter -> verify -> decide -> record -> update.
MINI_RECURSION_ENGINE: bounded SecureModelFlow in section 7.
INFERENCE_RULES: R01-R14.
CONFIDENCE: confidence is conditional on provenance, test quality, coverage, and evidence freshness; unknown is not zero risk.
SEMANTIC_EQUIVALENCE: secure model / protected AI model / governed model security entity (context dependent; not strict identity).
FLOW_HASH: compute SHA-256 over the published canonical TXT bytes at release; intentionally unset in draft.
UPDATE_MODEL: reassess on model revision, deployment change, policy revision, new vulnerability, or incident.

12. HOW TO READ
Follow the entity definition to identify what is being protected. Use the state model to distinguish observations, rules, boundaries, and verified knowledge. Apply the algebra to produce admissible choices, then use the inference rules and recursion engine to validate and record outcomes. Never interpret a verification label without its evidence, scope, and date.

13. IMPLEMENTATION NOTES
Keep credentials outside the model prompt; apply least privilege; separate control-plane instructions from untrusted data; maintain signed artefact provenance where feasible; test rollback and incident procedures; re-evaluate security after changes. Use human oversight for risk acceptance and high-impact recovery.

END OF FLOW