Access Permission Ontology

SEMANTIC LIBRARY — AI CORE / ENTITY GRAPH / SECURITY ENTITIES
ACCESS PERMISSION ONTOLOGY — FLOW ALGEBRA
Version: 1.0 | Date: 2026-11-04 | Language: en-GB
Source topic: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/access-permission-ontology.html
Authors: Mark Higgins — Kireth Research; Sky — Recursive AI (companion formalisation)
Status: Original conceptual formalisation; source-page embedded specification not independently verified.

1. PURPOSE
Represent an access permission as a scoped, conditional, revocable grant governing whether a principal may perform an action on a resource. Distinguish a permission definition from an evaluated authorisation decision.

2. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t: request and observed context (principal, action, resource, time, environment).
R_t: relationships among principals, roles, groups, resources, grants and policies.
B_t: boundaries (tenant, jurisdiction, sensitivity, validity, least privilege).
K_t: known policy versions, identity assurance, evidence, revocations and audit history.

Permission p = (subject, action, resource, scope, conditions, issuer, valid_from, valid_until, status, provenance).
Request q = (principal, action, resource, context).
Decision d in {PERMIT, DENY, INDETERMINATE}.

3. FLOW ALGEBRA
E_t = expand(I_t, R_t)
C_t = {p in E_t : matches(p,q) and active(p,t) and in_scope(p,q)}
V_t = {p in C_t : verified_issuer(p) and valid_provenance(p) and conditions_met(p,q.context)}
D_t = policy_combine(V_t, explicit_denials, mandatory_constraints, B_t)
If D_t = PERMIT, require all mandatory checks to pass; otherwise deny or return indeterminate.
I_(t+1) = update(I_t, D_t, evidence_t, audit_event_t)

Selection, where applicable:
x* = argmax_{x in permitted_actions} P(x | I_t,R_t,B_t,K_t)
This ranking never overrides mandatory denial, revocation or scope constraints.

4. IMPLEMENTS
- Explicit subject-action-resource permissions.
- Role/group-derived permissions only through verified membership relationships.
- Scope and attribute checks (ABAC/RBAC-compatible).
- Expiry, revocation and policy version checks.
- Separation of duties and least-privilege constraints.
- Auditable permit/deny decisions with provenance.

5. ENTITY RELATIONSHIPS
Principal --MEMBER_OF--> Role
Role --ASSIGNED--> Permission
Permission --ALLOWS_ACTION--> Action
Permission --SCOPED_TO--> Resource
Permission --SUBJECT_TO--> Condition
Permission --ISSUED_BY--> Authority
Permission --CONSTRAINED_BY--> Policy
Permission --REVOKED_BY--> RevocationEvent
AuthorisationDecision --EVALUATES--> AccessRequest
AuthorisationDecision --SUPPORTED_BY--> Evidence

6. INFERENCE RULES
R01: If identity is unverified, do not infer a permit.
R02: If permission is expired, exclude it.
R03: If permission is revoked, exclude it regardless of cached grants.
R04: If action or resource falls outside scope, exclude it.
R05: If a mandatory condition fails, deny.
R06: If a binding explicit deny applies, deny according to policy precedence.
R07: If role membership is unverified, do not inherit its permissions.
R08: If tenant boundary is crossed without an authorised exception, deny.
R09: If conflicting policy versions cannot be resolved, return INDETERMINATE and fail closed for execution.
R10: If the decision is permit, record policy, evidence, principal, resource and time.
R11: If privileges exceed task need, flag for least-privilege review.
R12: If authority is delegated, verify delegation scope and expiry.
R13: If context changes materially, re-evaluate the grant.
R14: If no applicable verified permission exists, deny by default.

7. MINI RECURSION ENGINE
function evaluate(q, state, depth, visited):
  if depth > MAX_DEPTH: return INDETERMINATE
  if q in visited: return INDETERMINATE
  visited.add(q)
  candidates = expand_permissions(q, state.relationships)
  verified = filter_scope_status_conditions(candidates, q, state)
  decision = combine_policy(verified, state.boundaries)
  if decision requires delegated proof:
      decision = evaluate(delegated_request, state, depth+1, visited)
  append_audit(q, decision, policy_version, evidence)
  return decision

8. HOW TO READ
The expansion step discovers possible grants; the filter removes invalid grants; the decision function applies policy precedence and boundaries. A discovered grant is not itself authorisation. Indeterminate means insufficient trustworthy evidence, not permission.

9. TRI-MAPPING
Semantic: principal -> permission -> resource/action, constrained by policy.
Mathematical: S_t -> E_t -> C_t -> V_t -> D_t -> S_(t+1).
Operational: authenticate -> resolve grants -> validate -> enforce -> log -> review.

10. MAPPING TABLE
Principal | Subject identity | Verified identity reference
Action | Requested operation | Read/write/execute/administer
Resource | Protected object | Dataset/model/tool/API
Scope | Grant boundary | Tenant/project/resource subset
Condition | Context predicate | Time, device, approval, purpose
Policy | Decision rules | Versioned policy reference
Evidence | Verification record | Credential, role assignment, delegation
Decision | Evaluation outcome | PERMIT/DENY/INDETERMINATE
AuditEvent | Trace | Timestamp, reason, policy version

11. CONDITIONAL EXECUTION GUARANTEE
If identity evidence, policy integrity, revocation freshness, scope validation and mandatory controls are all satisfied, an implementation can guarantee that it issues PERMIT only for requests meeting its encoded policy. This is a conditional software property, not a guarantee against compromised identity, incorrect policy, implementation defects or incomplete evidence.

12. AI SEARCH FLOW
FLOW_ID: semantic-library.security.access-permission.v1
ENTITY: AccessPermission
PURPOSE: Discover, validate and explain scoped access grants.
INPUTS: principal, action, resource, context, policy_version
STATE_MODEL: S=(I,R,B,K)
PATHWAYS: request -> identity -> grants -> constraints -> decision -> audit
MINI_RECURSION_ENGINE: bounded role/delegation expansion with cycle detection
INFERENCE_RULES: R01-R14
OUTPUTS: decision, reason_codes, evidence_refs, policy_version, audit_ref
CONFIDENCE: based on evidence completeness and freshness; never replaces mandatory checks
SEMANTIC_EQUIVALENCE: access grant; permission entitlement (context-dependent)
UPDATE_MODEL: re-evaluate after policy, role, context or revocation change
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/access-permission-ontology.html

13. EXAMPLE
Request: analyst reads project dataset.
Verified membership: analyst role. Grant: READ on project dataset, active until date T.
Conditions: project membership verified; tenant matches; no revocation.
Decision: PERMIT only if all checks pass; otherwise DENY or INDETERMINATE.

14. LICENCE AND ATTRIBUTION
Intended as an open research companion; retain source citation and author attribution when reusing. This document does not claim to reproduce the published page verbatim.