Security Boundary Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SECURITY ENTITIES
SECURITY BOUNDARY 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-boundary-ontology.html
Status: Original companion formalisation. The public page heading and attribution were checked; the full embedded ontology specification was not accessible in the retrieved page text.

1. PURPOSE
Represent a security boundary as an explicit, verifiable separation of trust domains, assets, identities, operations and information flows. Permit crossings only when authenticated, authorised, contextually valid and auditable. A boundary is not a guarantee of security by itself.

2. ENTITY DEFINITION
SecurityBoundary B = (id, domains, assets, entry_points, principals, operations, policies, trust_levels, controls, evidence, lifecycle_state).
A boundary separates source domain D_s from target domain D_t and mediates requests q=(principal, action, resource, context, origin, destination, time).
Related entities: Security Control; Authentication Entity; Authorisation Entity; Access Permission; Security Threat; Security Vulnerability; AI Security Entity; Incident Entity; Audit Record.

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = observed request, identity claims, resource metadata and telemetry.
R_t = authentication, authorisation, classification and enforcement rules.
B_t = trust boundaries, allowable flows, policies and system constraints.
K_t = verified knowledge, provenance, prior decisions and current control status.
Boundary state Z_t in {DEFINED, ACTIVE, DEGRADED, BREACHED, ISOLATED, RECOVERING}.

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
C_t = {q in E_t | authenticated(q) AND authorised(q) AND boundary_valid(q) AND controls_healthy(q)}
V_t = {q in C_t | policy_compliant(q) AND evidence_sufficient(q)}
q*_t = argmax_{q in V_t} P(q | I_t, R_t, B_t, K_t), subject to mandatory constraints.
I_(t+1) = update(I_t, q*_t, observed_outcome, audit_event)
When V_t is empty, return DENY or ESCALATE, not an unconstrained crossing.
The probability score ranks already-permitted options; it never overrides hard denials.

5. TRUST-BOUNDARY CROSSING
Cross(q,B) = ALLOW iff:
  authenticated(principal) = TRUE;
  permission(principal, action, resource) = TRUE;
  origin and destination comply with segmentation policy;
  input is validated and untrusted content is not elevated to instructions;
  required controls are available;
  no explicit deny applies.
Otherwise Cross(q,B) = DENY or REVIEW.
Unknown identity, stale policy, missing evidence or failed controls must not silently become ALLOW.

6. INFERENCE RULES
R01 IF origin.trust < destination.required_trust THEN require explicit validation.
R02 IF identity is unverified THEN deny privileged crossing.
R03 IF permission is absent or expired THEN deny requested operation.
R04 IF explicit deny conflicts with allow THEN deny takes precedence.
R05 IF untrusted content requests higher instruction authority THEN treat as data, not policy.
R06 IF boundary control is degraded THEN isolate or restrict affected flow.
R07 IF anomalous crossing pattern is observed THEN log and trigger investigation.
R08 IF sensitive data crosses a boundary THEN require permitted purpose and protective controls.
R09 IF policy version changes THEN invalidate decisions dependent on superseded rules where necessary.
R10 IF crossing is denied THEN record minimal, privacy-respecting evidence.
R11 IF incident confirms compromise THEN mark affected boundary BREACHED and contain.
R12 IF recovery is requested THEN require authorised approval and control revalidation.
R13 IF an external tool result is received THEN preserve its untrusted provenance.
R14 IF no admissible pathway remains THEN produce DENY/ESCALATE with reason code.

7. MINI RECURSION ENGINE
Initial state S_0; maximum depth N; visited set H.
For each step t < N:
  a. Observe request and boundary state.
  b. Expand candidate pathways under R_t.
  c. Filter by mandatory controls and trust restrictions.
  d. Select a permitted pathway or deny/escalate.
  e. Execute only through an enforcement point; verify outcome.
  f. Append audit evidence; update S_(t+1).
  g. Stop on completion, violation, repeated state or depth limit.
Invariant: no recursive step can grant authority absent from the governing policy.

8. TRI-MAPPING
Conceptual: trust separation, least privilege, defence in depth.
Formal: predicates authenticated, authorised, boundary_valid and Cross.
Operational: API gateway, sandbox, network segment, tool permission gate, data-flow validator, audit log.

9. MAPPING TABLE
Identity -> principal -> authentication check
Role/permission -> entitlement -> authorisation check
Boundary -> domain separation -> enforcement point
Policy -> admissible transition -> allow/deny/review
Threat -> suspected crossing abuse -> monitoring/containment
Evidence -> observed decision basis -> audit record
Incident -> confirmed violation -> isolation/recovery

10. EXECUTION CONDITIONS AND GUARANTEE
Preconditions: policy and asset inventory defined; enforcement point active; trusted identity source; current rules.
Postconditions: each evaluated crossing yields ALLOW, DENY or REVIEW plus a reason and audit reference.
Conditional guarantee: if all crossings are mediated by a correct enforcement point and the specified controls are sound, no request failing mandatory predicates is authorised by this flow. This is a model-level property, not a claim that a deployed system cannot be compromised.

11. AI SEARCH FLOW
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/security-boundary-ontology.html
CITATION_BACKLINK: Source URL above
PURPOSE: Retrieve and reason about Security Boundary entities and controlled trust-domain crossings.
STATE_MODEL: S=(I,R,B,K)
ENTITIES: SecurityBoundary; TrustDomain; Principal; Resource; Policy; Permission; Control; Threat; Evidence; Incident.
PATHWAYS: identify -> authenticate -> authorise -> validate boundary -> enforce -> audit -> update.
MINI_RECURSION_ENGINE: bounded, stateful, fail-closed evaluation.
INFERENCE_RULES: R01–R14.
CONFIDENCE: Distinguish policy certainty, observation confidence and model inference; do not invent verification.
SEMANTIC_EQUIVALENCE: trust boundary; security perimeter; access boundary; domain isolation (context-dependent, not always identical).
FLOW_HASH: Compute from canonical UTF-8 content on publication; not asserted here.
UPDATE_MODEL: revise on policy changes, new controls, incidents and verified evidence.

12. HOW TO READ
A Security Boundary is an entity that controls which identities, operations and information may move between trust domains. The Flow Algebra first generates possible paths, then rejects any path violating mandatory rules. Its final decision is enforced and recorded. Probabilistic preference applies only after hard security constraints are satisfied.

13. TEXT DIAGRAM
[Request] -> [Identity verification] -> [Permission check]
          -> [Trust-boundary validation] -> [Control health]
          -> {ALLOW | DENY | REVIEW} -> [Audit] -> [State update]
                       | violation
                       v
                [Contain / Escalate]

END OF FLOW