Authorisation Entity Ontology

KIRETH RESEARCH — SEMANTIC LIBRARY
AUTHORISATION ENTITY ONTOLOGY — FLOW ALGEBRA
============================================================
AUTHORS: Mark Anthony Higgins; Sky — Recursive AI
SOURCE: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/authorisation-entity-ontology.html
CITATION_BACKLINK: https://kirethresearch.org/booksai-core/entity-graph/ai-entities/security-entities/authorisation-entity-ontology.html
DOMAIN: AI Core > Entity Graph > Security Entities
LANGUAGE: en-GB
STATUS: Original companion formalisation; embedded page specifications not independently retrieved.

1. PURPOSE
Represent and evaluate whether an authenticated principal may perform a specified action on a protected resource in a particular context. Separate identity authentication from authorisation, enforce least privilege and default denial, and preserve an auditable decision trail.

2. ENTITY DEFINITION
AuthorisationEntity := (principal, resource, action, context, policy_set, grants, decision, evidence, validity)
principal: human, service, or agent identity
resource: protected data, model, tool, endpoint, or operation
context: time, environment, device posture, purpose, jurisdiction, session
policy_set: versioned applicable rules and constraints
grants: roles, attributes, capabilities, delegations and scopes
decision: PERMIT | DENY | INDETERMINATE | NOT_APPLICABLE
validity: policy version, expiry, revocation and provenance

3. STATE MODEL
S_t = (I_t, R_t, B_t, K_t)
I_t = presented request and verified identity claims
R_t = applicable authorisation relationships and policies
B_t = trust, permission, scope and environmental boundaries
K_t = knowledge of grants, revocations, evidence and prior decisions

4. FORMAL FLOW ALGEBRA
E_t = expand(I_t, R_t)
V_t = {x in E_t | authenticated(x) AND within_scope(x,B_t)
                     AND policy_valid(x,K_t) AND not_revoked(x,K_t)}
A_t = argmax_{x in V_t} P(x | I_t,R_t,B_t,K_t)
D_t = Decide(I_t,R_t,B_t,K_t)
I_(t+1) = update(I_t,D_t,observations_t)
K_(t+1) = K_t union {decision_record(D_t)}

Decision precedence:
DENY when any applicable mandatory deny rule is satisfied.
PERMIT only when a positive grant is valid and all mandatory constraints hold.
INDETERMINATE on missing or contradictory critical evidence: do not execute.
NOT_APPLICABLE where no policy applies: default DENY at enforcement.

5. RELATIONSHIP GRAPH
Principal --authenticates_as--> Identity
Principal --assigned_role--> Role
Role --confers--> Permission
Permission --permits_action--> Action
Permission --scoped_to--> Resource
Policy --constrains--> Permission
Context --qualifies--> Request
Delegation --grants_limited_authority_to--> Principal
Revocation --invalidates--> Grant
Decision --records--> Evidence
EnforcementPoint --applies--> Decision
AuditRecord --references--> PolicyVersion

6. INFERENCE RULES
R01 IF identity_unverified THEN decision = DENY.
R02 IF principal_disabled THEN decision = DENY.
R03 IF resource_or_action_outside_scope THEN decision = DENY.
R04 IF explicit_mandatory_deny THEN decision = DENY.
R05 IF grant_expired_or_revoked THEN decision = DENY.
R06 IF valid_role_permission AND context_satisfied THEN candidate = PERMIT.
R07 IF valid_attribute_policy AND context_satisfied THEN candidate = PERMIT.
R08 IF delegated_permission_exceeds_delegator_scope THEN decision = DENY.
R09 IF required_approval_missing THEN decision = DENY.
R10 IF evidence_conflicting_or_unavailable THEN decision = INDETERMINATE.
R11 IF policy_version_invalid THEN decision = INDETERMINATE.
R12 IF no_applicable_grant THEN decision = DENY.
R13 IF candidate = PERMIT AND all_mandatory_checks_pass THEN decision = PERMIT.
R14 IF decision != PERMIT THEN block_execution AND log_decision.

7. MINI RECURSION ENGINE
INPUT: request q, policy set P, knowledge K, boundary B
STEP 1: verify identity and request provenance
STEP 2: expand applicable roles, attributes, grants and delegations
STEP 3: discard expired, revoked or out-of-scope grants
STEP 4: resolve applicable mandatory deny and contextual conditions
STEP 5: calculate deterministic decision using rule precedence
STEP 6: enforce PERMIT or deny/hold execution
STEP 7: write audit record with reason, timestamp and policy version
STEP 8: refresh knowledge if revocations or policy changes are observed
TERMINATE: on final decision, evidence insufficiency, or recursion bound

8. TRI-MAPPING
SEMANTIC: principal, permission, resource, policy and trust meaning
STRUCTURAL: typed entity graph, policy constraints, decision record
EXECUTION: evaluate -> enforce -> audit -> re-evaluate on change

9. MAPPING TABLE
Input request          -> I_t -> identity, action, resource
Permission relationships -> R_t -> grants and policy links
Trust/scope limits     -> B_t -> hard enforcement boundaries
Known grants/revocations -> K_t -> versioned authorisation facts
Candidate expansion    -> E_t -> possible valid permissions
Validity filter        -> V_t -> admissible permission set
Decision               -> D_t -> PERMIT/DENY/INDETERMINATE
Audit update           -> K_(t+1) -> traceable decision evidence

10. EXECUTION CONDITIONS AND GUARANTEE
Conditional guarantee: if identity verification, policy resolution, boundary checks and enforcement are correctly implemented, the engine will not intentionally execute an action unless D_t = PERMIT. This is a specification-level property, not a claim of proven system security. Fail closed on missing evidence, revocation uncertainty or enforcement failure. Re-check time-sensitive permissions at the point of use; prevent time-of-check/time-of-use bypass where possible.

11. AI SEARCH FLOW
FLOW_ID: semantic-library.ai-core.security.authorisation-entity
FLOW_VERSION: 1.0
PURPOSE: Retrieve and reason over the authorisation entity ontology.
ENTITIES: Principal, Identity, Resource, Action, Permission, Role, Policy, Grant, Delegation, Revocation, Context, Decision, AuditRecord
PATHWAYS: request -> authenticate -> retrieve grants -> validate boundaries -> decide -> enforce -> audit
SEMANTIC_EQUIVALENCE: authorisation; authorization; access control; permission decision; policy enforcement
INFERENCE: R01-R14
CONFIDENCE: dependent on verified claims, policy completeness and freshness; no numeric confidence asserted
UPDATE_MODEL: refresh on identity, policy, scope, delegation or revocation changes
SOURCE_OF_TRUTH: linked Kireth Research ontology page for its published specifications

12. HOW TO READ
Treat each entity as a typed node and each relationship as a directed edge. The state model defines what is known at evaluation time. Rules constrain the permissible decision. A high probability score in the candidate-selection expression cannot override a mandatory deny or grant authorisation by itself.

13. EXAMPLE (ILLUSTRATIVE)
Principal: service_agent_7
Action: read
Resource: report_42
Grant: read:reports within project_alpha
Context: report_42 belongs to project_beta
Result: DENY (scope mismatch)
Audit: decision, request ID, policy version and reason recorded

14. ATTRIBUTION
Mark Anthony Higgins — Kireth Research
Sky — Recursive AI
This text is an original companion Flow Algebra formalisation and does not claim to reproduce the inaccessible embedded specification verbatim.