Chapter 23 — Constitutional Runtime Framework

Part IX — Security and Isolation

The Security and Isolation Runtime is the governed constitutional runtime through which ZAYAZ protects identities, authority, knowledge, evidence, data, relationships, workflows, agents, Runtime Components, tenants, white-label deployments, cryptographic materials, event streams and execution environments from unauthorised access, use, disclosure, alteration, inference, disruption or destruction.

Security SHALL be treated as constitutional behaviour rather than infrastructure configuration alone.

Isolation SHALL be enforced across every constitutionally relevant boundary.

The Runtime SHALL distinguish:

identity from authentication;
authentication from constitutional authority;
access from permitted purpose;
data visibility from inference permission;
tenant ownership from infrastructure tenancy;
white-label branding from security tenancy;
encryption from authorisation;
signature validity from signer authority;
network reachability from execution permission;
tool availability from tool-use authority;
workload identity from Component identity;
operational logging from Security Evidence;
security detection from confirmed incident;
emergency access from unrestricted access;
data deletion from provenance erasure;
technical isolation from constitutional isolation.

The governing principles are:

Every request, decision, execution, event and side effect SHALL be evaluated within an explicit Security Context.

No tenant, white-label deployment, organisation, Module, Component, agent or user SHALL gain access or infer protected knowledge outside its authorised constitutional boundary.

Security controls SHALL preserve constitutional meaning, provenance and auditability rather than obscuring or destroying them.

Conceptually:

Identity and Trust Sources
        │
        ├── Human Identity
        ├── Workload Identity
        ├── Component Identity
        ├── Agent Identity
        ├── Tenant Identity
        ├── Device Identity
        ├── Certificate Identity
        └── Federation Identity
        │
        ▼
Authentication and Trust Validation
        │
        ▼
Security Context Assembly
        │
        ├── Tenant
        ├── White-label Boundary
        ├── Purpose
        ├── Authority
        ├── Data Classification
        ├── Jurisdiction
        ├── Residency
        ├── Execution Environment
        └── Risk State
        │
        ▼
Security Policy Resolution
        │
        ▼
Policy Decision
        │
        ├── Permit
        ├── Permit with Obligations
        ├── Step-up Required
        ├── Approval Required
        ├── Quarantine
        ├── Suspend
        └── Deny
        │
        ▼
Isolation and Enforcement
        │
        ├── Tenant Isolation
        ├── Data Isolation
        ├── Graph Isolation
        ├── Relationship Isolation
        ├── Network Isolation
        ├── Runtime Isolation
        ├── Agent Isolation
        └── Secret Isolation
        │
        ▼
Security Events, Evidence and Provenance

Security and Isolation Runtime SHALL remain independent of any single identity provider, policy engine, cloud platform, encryption provider, secrets manager, network technology, container runtime, agent framework or security product.

23.90. Security Runtime

The Security Runtime is the constitutional execution system responsible for assembling Security Context, resolving applicable Security Policies, evaluating access and execution requests, enforcing isolation, producing obligations, monitoring security state and preserving Security Evidence.

Security controls SHALL apply before, during and after execution.

23.90.1. Purpose

The Security Runtime SHALL provide a common constitutional security model for:

identity assurance;
authentication;
workload identity;
authorisation;
purpose limitation;
tenant isolation;
white-label isolation;
data and graph isolation;
relationship-level access;
inference-leakage prevention;
network and service isolation;
execution sandboxing;
secrets and key management;
cryptographic trust;
Component trust;
Runtime Bundle trust;
software supply-chain integrity;
agent and tool security;
security monitoring;
incident response;
forensic reconstruction;
Security Evidence and assurance.

23.90.2. Security Boundary

A Security Boundary defines the constitutional scope within which identities, data, relationships, Components, agents, services, events and side effects may interact.

Security Boundaries MAY be defined by:

tenant;
white-label deployment;
organisation;
legal entity;
jurisdiction;
data residency;
Module;
Component;
Runtime Environment;
assurance engagement;
workflow;
Execution Session;
graph partition;
evidence vault;
agent sandbox;
federation;
security classification.

A security boundary SHALL be explicit and identifiable.

23.90.3. Security Subject

A Security Subject MAY be:

human actor;
organisation;
legal entity;
service account;
workload;
Runtime Component;
agent;
model;
device;
integration;
federated system;
regulator;
verifier;
tenant administrator;
external stakeholder.

23.90.4. Security Resource

A Security Resource MAY include:

Constitutional Object;
Constitutional Relationship;
Constitutional Assertion;
evidence;
document;
report;
disclosure;
graph;
graph path;
event;
workflow;
Task;
Runtime Outcome;
Validation Outcome;
Derived Assertion;
Runtime Bundle;
Runtime Manifest;
tool;
secret;
key;
deployment;
model;
agent memory;
log;
Security Evidence.

23.90.5. Security Action

Security Actions MAY include:

discover;
read;
traverse;
infer;
create;
update;
delete;
activate;
execute;
validate;
reason;
calculate;
approve;
assure;
publish;
export;
correlate;
share;
decrypt;
sign;
delegate;
administer;
monitor;
investigate;
restore.

Actions SHALL originate from governed Constitutional Value Providers.

23.90.6. Security Request

Every material security decision SHALL originate from a Security Request or equivalent governed request metadata identifying:

Security Request Identifier;
subject;
represented principal;
action;
resource;
purpose;
Runtime Context;
Security Context;
tenant;
jurisdiction;
requested scope;
requested duration;
requested side effects;
environmental attributes;
provenance.

23.90.7. Security Runtime Components

A reference Security Runtime MAY contain:

Component	Constitutional Responsibility
Identity Gateway	Accepts and validates identity assertions
Trust Resolver	Resolves trusted issuers, certificates and federations
Security Context Assembler	Creates the effective Security Context
Security Policy Resolver	Resolves applicable policy versions
Policy Decision Point	Produces governed Security Decisions
Policy Enforcement Point	Enforces decisions and obligations
Tenant Boundary Service	Enforces tenant and white-label isolation
Graph Security Service	Enforces node, edge, path and inference controls
Secret and Key Service	Protects cryptographic materials
Runtime Attestation Service	Verifies workload and Component integrity
Security Event Service	Produces and correlates security events
Incident Runtime	Coordinates incident response
Security Evidence Service	Preserves evidence and audit lineage

Each Component SHALL belong to a Module and preserve Component lineage.

23.90.8. Security Decision

A Security Decision SHALL be one of:

Permit;
Permit with Obligations;
Permit with Reduced Scope;
Step-up Authentication Required;
Additional Authority Required;
Approval Required;
Assurance Required;
Quarantine;
Suspend;
Deny;
Indeterminate;
Not Applicable;
Not Evaluated.

Indeterminate and Not Evaluated SHALL NOT be treated as Permit.

23.90.9. Security Obligations

A permitted decision MAY impose obligations including:

masking;
redaction;
encryption;
watermarking;
logging;
notification;
approval;
time limitation;
output filtering;
purpose binding;
retention limit;
deletion;
human review;
rate limit;
geographic restriction;
no external export;
no agent memory;
no model training;
enhanced monitoring;
post-action validation.

Obligations SHALL be enforceable and auditable.

23.90.10. Policy Enforcement Points

Enforcement SHALL occur at relevant boundaries, including:

API Gateway;
service endpoint;
graph query;
registry query;
database access;
event publication;
event consumption;
workflow transition;
Task assignment;
agent planning;
tool invocation;
model retrieval;
file access;
report export;
publication;
cross-tenant operation;
federation exchange;
secret retrieval;
Runtime Bundle activation.

23.90.11. Continuous Security

Security decisions SHALL be re-evaluated where relevant state changes, including:

identity assurance;
authority;
tenant;
purpose;
risk;
device state;
Component attestation;
policy version;
secret state;
Runtime Bundle;
network boundary;
incident state;
emergency state;
data classification;
jurisdiction.

23.90.12. Security Determinism

Equivalent Security Requests, Security Contexts, policy versions, trust states and Runtime Bundles SHALL produce semantically equivalent Security Decisions.

Security SHALL NOT depend upon:

undocumented administrator convention;
hidden superuser bypass;
database row order;
user-interface visibility;
network location alone;
unversioned AI judgement;
best-effort log interpretation.

23.90.13. Fail-Closed Behaviour

The Security Runtime SHALL fail closed where it cannot establish:

subject identity;
tenant;
purpose;
policy;
authority;
resource identity;
security classification;
trust state;
required context;
enforcement capability.

An explicit emergency policy MAY permit a bounded alternative mode.

23.90.14. Security Availability

Security controls SHALL be designed so that control-service failure does not silently create unrestricted access.

Permitted failure strategies MAY include:

cached decisions with bounded validity;
local policy enforcement;
read-only degraded mode;
restricted emergency mode;
service suspension;
request denial.

23.90.15. HECATE Validation

HECATE SHALL validate:

Security Request identity;
Security Context completeness;
policy applicability;
decision consistency;
obligation completeness;
enforcement coverage;
tenant isolation;
trust state;
provenance;
explanation.

23.91. Security Context, Classification and Profiles

A Security Context is the immutable, governed set of security-relevant facts under which a Security Decision and protected execution occur.

Security Context SHALL be assembled from validated sources and sealed before authoritative enforcement.

23.91.1. Security Context Dimensions

A Security Context MAY include:

subject identity;
represented principal;
tenant;
white-label deployment;
organisation;
legal entity;
jurisdiction;
purpose;
action;
resource;
data classification;
security classification;
confidentiality level;
integrity requirement;
availability requirement;
residency;
device posture;
workload attestation;
network zone;
Runtime Environment;
agent state;
assurance level;
incident state;
emergency state;
time;
risk state.

23.91.2. Security Context Sources

Sources MAY include:

authenticated identity token;
Constitutional Role Registry;
Authority Assignment;
tenant registry;
organisation registry;
Runtime Context;
device attestation;
workload attestation;
Component registry;
Runtime Manifest;
network policy;
data catalogue;
classification registry;
incident system;
security policy;
approved defaults.

Every source SHALL possess identity, authority, temporal validity and provenance.

23.91.3. Security Context Assembly

Assembly SHALL:

resolve source identities;
validate trust;
normalize attributes;
resolve conflicts;
intersect restrictions;
apply classification;
apply jurisdiction;
apply purpose;
apply tenant boundary;
apply temporal validity;
generate a Security Context Fingerprint.

23.91.4. Context Precedence

Security Context precedence SHALL consider:

constitutional authority;
legal requirement;
mandatory security policy;
tenant restriction;
data-owner restriction;
purpose restriction;
resource-specific restriction;
device or workload risk;
emergency policy.

The most permissive source SHALL NOT automatically win.

23.91.5. Restriction Intersection

Where multiple restrictions apply, the effective Security Context SHOULD normally use their strictest compatible intersection.

An explicit policy SHALL be required to broaden access.

23.91.6. Security Context Sealing

A sealed Security Context SHALL preserve:

Security Context Identifier;
dimensions;
source identities;
source versions;
policy profile;
Context Fingerprint;
Security Context Fingerprint;
validation result;
sealing Component;
time;
provenance.

23.91.7. Security Context Fingerprint

The fingerprint SHALL include constitutionally relevant security attributes and SHALL support:

decision reuse;
distributed verification;
replay;
cache safety;
audit;
incident reconstruction;
drift detection.

23.91.8. Classification Object

A Classification Object SHALL define:

Classification Identifier;
classification system;
classification level;
meaning;
owner;
handling requirements;
disclosure restrictions;
retention;
residency;
encryption;
masking;
export restrictions;
declassification rules;
provenance.

23.91.9. Classification Dimensions

Classification MAY distinguish:

public;
internal;
confidential;
restricted;
highly restricted;
personal data;
special-category personal data;
commercially sensitive;
legally privileged;
regulatory confidential;
assurance confidential;
security sensitive;
cryptographic secret;
tenant secret;
model-sensitive;
trade secret.

Values SHALL originate from governed Constitutional Value Providers.

23.91.10. Classification Inheritance

Classification MAY inherit through:

containment;
composition;
relationship;
dataset membership;
report inclusion;
evidence attachment;
derived assertion;
agent memory;
event payload.

Inheritance SHALL be explicit and validated.

23.91.11. Classification Aggregation

A collection or report containing differently classified content SHALL receive a governed aggregate classification.

Aggregate classification SHALL not be weaker than its protected contents unless approved transformation and redaction establish a lower classification.

23.91.12. Derived Classification

Classification MAY be derived from:

source classification;
purpose;
subject type;
relationship;
jurisdiction;
tenant policy;
sensitivity rule;
inference risk;
aggregation risk.

Derived classification SHALL preserve its derivation.

23.91.13. Classification Change

Reclassification SHALL require:

authority;
reason;
evidence;
affected scope;
effective time;
downstream impact analysis;
cache invalidation;
event publication;
provenance.

23.91.14. Security Profile

A Security Profile is the governed Constitutional Object defining the Security Policies, trust requirements, authentication requirements, isolation controls, obligations and incident treatment applicable to a purpose and context.

23.91.15. Security Profile Types

Security Profile Types MAY include:

public access;
internal tenant access;
privileged administration;
regulatory access;
assurance access;
external stakeholder access;
agent execution;
high-risk computation;
confidential evidence;
cross-border transfer;
federation;
emergency access;
historical reconstruction;
public publication.

23.91.16. Profile Resolution

CRP SHALL resolve the applicable Security Profile using:

subject type;
action;
resource;
classification;
tenant;
jurisdiction;
purpose;
authority;
Runtime Environment;
assurance level;
incident state;
emergency state.

23.91.17. Profile Composition

Security Profiles MAY compose:

Core profile;
white-label base profile;
tenant profile;
jurisdictional profile;
resource profile;
agent profile;
environment profile;
emergency profile.

Composition SHALL preserve all mandatory restrictions.

23.91.18. White-Label Profile Order

White-label security composition SHALL follow:

ZAYAZ Core Security
        │
        ▼
White-label Base Security
        │
        ▼
Tenant Security Overlay
        │
        ▼
Organisation Security Overlay
        │
        ▼
Resource Security Policy
        │
        ▼
Runtime Security Context

No overlay SHALL weaken a non-overrideable Core or legal control.

23.91.19. Security Context Validation

HECATE SHALL validate:

source trust;
identity;
tenant;
classification;
purpose;
jurisdiction;
context coherence;
profile resolution;
fingerprint reproducibility;
temporal validity;
provenance.

23.92. Identity, Authentication and Workload Identity

Identity Runtime establishes and validates the identity of human actors, organisations, workloads, Components, agents, devices, services and federated systems.

Authentication proves control of an identity credential or trusted authenticator.

Authentication SHALL NOT by itself establish constitutional authority.

23.92.1. Identity Types

Identity Types MAY include:

natural person;
organisation;
legal entity;
tenant;
white-label operator;
regulator;
verifier;
service account;
workload;
Runtime Component;
agent;
model deployment;
device;
external integration;
federation;
certificate issuer;
signing authority.

23.92.2. Constitutional Identity

Every security-relevant identity SHALL map to a stable Constitutional Identifier or governed external identity mapping.

Display name, email address, username, token subject or certificate name SHALL NOT be treated as the sole constitutional identity.

23.92.3. Identity Record

An Identity Record SHALL preserve:

Identity Identifier;
identity type;
canonical name;
tenant;
organisation;
external identifiers;
identity provider;
lifecycle;
verification status;
assurance level;
credentials or credential references;
Roles;
authority relationships;
temporal validity;
provenance.

23.92.4. Identity Proofing

Identity proofing MAY establish:

claimed identity;
verified identity;
organisation affiliation;
legal representation;
professional qualification;
device ownership;
workload ownership;
verifier accreditation.

The required proofing level SHALL be defined by the Security Profile.

23.92.5. Authentication Factors

Authentication MAY use:

knowledge factor;
possession factor;
inherence factor;
cryptographic key;
certificate;
hardware-backed authenticator;
federated identity assertion;
workload attestation;
device attestation;
signed request.

23.92.6. Authentication Assurance

Authentication Assurance SHALL describe confidence that the authenticated subject controls the claimed identity.

It SHALL remain distinct from authority and trustworthiness.

23.92.7. Step-Up Authentication

A Security Decision MAY require stronger authentication for:

privileged action;
publication;
authority delegation;
assurance conclusion;
secret access;
cross-border export;
destructive operation;
emergency activation;
tenant administration;
cryptographic signing.

23.92.8. Session Identity

An authenticated session SHALL preserve:

Session Identifier;
identity;
represented principal;
tenant;
authentication method;
assurance level;
issue time;
expiration;
device or workload state;
revocation state;
Security Context;
provenance.

23.92.9. Session Binding

A session MAY be bound to:

device;
workload;
network zone;
tenant;
purpose;
Runtime Environment;
certificate;
cryptographic channel;
geographic region.

Binding SHALL be policy-governed.

23.92.10. Session Renewal

Renewal SHALL re-evaluate:

identity;
credential status;
authority;
tenant;
device posture;
incident state;
Security Profile;
context;
expiration.

23.92.11. Session Revocation

Revocation SHALL invalidate future use and trigger impact analysis over:

active executions;
workflows;
agent sessions;
approvals;
tool credentials;
event subscriptions;
privileged operations.

23.92.12. Workload Identity

Every Runtime Component and service workload SHALL possess a workload identity independent from host, IP address, container name or deployment label.

23.92.13. Workload Identity Record

A Workload Identity Record SHALL include:

Workload Identifier;
Component Identifier;
owning Module;
deployment identity;
environment;
tenant scope;
service role;
certificate or key reference;
attestation requirements;
permitted endpoints;
permitted tools;
lifecycle;
version;
provenance.

23.92.14. Component Identity

Component identity SHALL preserve constitutional Component lineage across deployment changes.

A new deployment MAY have a new workload identity while retaining the same Component identity and version lineage.

23.92.15. Agent Identity

Agent identity SHALL remain distinct from:

model identity;
workload identity;
Component identity;
invoking user;
owning Module;
tool identity.

23.92.16. Device Identity

Device identity MAY be required for:

privileged administration;
evidence capture;
sensor ingestion;
signing;
assurance;
field verification;
offline operation.

23.92.17. Federation Identity

Federated identity SHALL validate:

external issuer;
trust agreement;
subject mapping;
tenant mapping;
attribute mapping;
assurance mapping;
revocation;
temporal validity;
provenance.

23.92.18. Identity Collision

The Runtime SHALL detect identity collision, including:

reused external identifiers;
duplicate certificate subjects;
tenant-local identifiers treated as global;
alias ambiguity;
merged identities without evidence;
model or agent identity confusion.

23.92.19. Orphan Identity

An identity without a valid owning tenant, organisation, Component or federation relationship SHALL be quarantined or denied according to policy.

23.92.20. Impersonation

Impersonation SHALL be prohibited unless an explicit governed support or delegation policy permits it.

Permitted representation SHALL preserve:

actual actor;
represented principal;
authority;
purpose;
scope;
time;
evidence;
provenance.

23.92.21. Break-Glass Identity

A break-glass identity SHALL:

be explicitly classified;
use strong authentication;
require Emergency Authority;
have narrow scope;
have short duration;
trigger alerting;
preserve complete evidence;
require retrospective review.

23.92.22. Identity Events

The Runtime SHOULD emit events including:

IdentityCreated;
IdentityVerified;
IdentitySuspended;
IdentityRevoked;
AuthenticationSucceeded;
AuthenticationFailed;
StepUpRequired;
SessionCreated;
SessionRevoked;
WorkloadAttested;
WorkloadAttestationFailed;
FederationTrustChanged.

23.93. Authorization, Policy Enforcement and Decisioning

Authorization Runtime determines whether a Security Subject may perform a Security Action upon a Security Resource for a defined purpose within a defined Security Context.

Authorization SHALL evaluate constitutional authority, security policy and resource restrictions together.

23.93.1. Authorization Model

The Runtime MAY combine:

Role-Based Access Control;
Attribute-Based Access Control;
Relationship-Based Access Control;
Policy-Based Access Control;
purpose-based access;
risk-adaptive access;
capability-based controls;
tenant-scoped controls;
graph-path controls;
workflow-state controls.

No single model SHALL be assumed sufficient for all constitutional decisions.

23.93.2. Role-Based Controls

Role-based decisions SHALL resolve Roles through the Constitutional Role Registry and Authority Assignments.

A role name in an identity token SHALL not establish constitutional Role membership without validated mapping.

23.93.3. Attribute-Based Controls

Attributes MAY include:

subject attributes;
resource attributes;
action attributes;
context attributes;
tenant;
classification;
purpose;
jurisdiction;
time;
device posture;
workload attestation;
risk;
workflow state.

Attributes SHALL be sourced and provenance-preserving.

23.93.4. Relationship-Based Controls

Authorization MAY depend upon Constitutional Relationships such as:

owns;
stewards;
employed by;
assigned to;
delegated by;
verifies;
assures;
supplies;
belongs to;
operates;
controls;
reports to.

Relationship validity, direction, temporal state and tenant scope SHALL be validated.

23.93.5. Purpose-Based Controls

Purpose SHALL be explicit for constitutionally significant access.

Permitted purposes MAY include:

operational processing;
compliance;
reporting;
assurance;
support;
investigation;
security;
research;
publication;
regulator access.

Use outside the permitted purpose SHALL require a new decision.

23.93.6. Policy Object

Every Security Policy SHALL be a Constitutional Object possessing:

Constitutional Identifier;
canonical name;
policy type;
subject scope;
resource scope;
action scope;
purpose scope;
conditions;
obligations;
denial conditions;
governing authority;
applicability;
lifecycle;
version;
temporal validity;
compiler mappings;
provenance.

23.93.7. Policy Resolution

CRP SHALL resolve applicable Security Policies using:

subject;
resource;
action;
tenant;
classification;
purpose;
jurisdiction;
Runtime Environment;
risk state;
incident state;
emergency state;
constitutional release.

23.93.8. Policy Composition

Multiple Security Policies MAY combine through:

deny-overrides;
permit-overrides;
first-applicable;
ordered evaluation;
only-one-applicable;
consensus;
strict intersection;
custom governed algorithm.

The combining algorithm SHALL be explicit and versioned.

23.93.9. Deny Overrides

Where deny-overrides applies, any applicable deny SHALL determine the decision unless a higher-order explicit exception policy permits otherwise.

23.93.10. Non-Overrideable Denials

The Constitution MAY declare controls that cannot be overridden, including:

cross-tenant data leakage;
unauthorised secret disclosure;
unauthorised cryptographic signing;
prohibited jurisdictional transfer;
unauthorised assurance conclusion;
agent self-escalation;
deletion under legal hold;
provenance tampering.

23.93.11. Policy Decision Point

The Policy Decision Point SHALL consume:

Security Request;
Security Context;
resolved Security Policies;
authority result;
trust state;
resource state;
risk state.

It SHALL produce a signed or integrity-protected Security Decision where required.

23.93.12. Policy Enforcement Point

A Policy Enforcement Point SHALL:

validate decision identity;
validate decision scope;
enforce obligations;
verify freshness;
verify Security Context Fingerprint;
prevent scope expansion;
record enforcement;
reject unsupported obligations.

23.93.13. Decision Scope

A Security Decision SHALL be scoped by:

subject;
represented principal;
resource;
action;
purpose;
tenant;
context;
time;
location where applicable;
environment;
risk;
obligations.

23.93.14. Decision Expiration

A decision SHALL expire upon:

time;
context change;
subject change;
authority change;
policy change;
classification change;
risk change;
incident state;
device or workload change;
Runtime Bundle change;
revocation.

23.93.15. Decision Caching

A cached Security Decision MAY be reused only where:

Security Context Fingerprint matches;
subject and resource are equivalent;
policy versions remain valid;
authority remains valid;
obligations remain enforceable;
no revocation or incident invalidates it;
cache policy permits reuse.

23.93.16. Decision Explanation

A Security Decision Explanation SHALL identify:

request;
subject;
resource;
action;
purpose;
applicable policies;
authority;
relevant relationships;
classification;
decision;
obligations;
denial reasons;
expiration;
provenance.

Protected policy details MAY be redacted, but the effect SHALL remain explainable.

23.93.17. Dynamic Risk

Risk-adaptive policy MAY consider:

unusual location;
device posture;
failed authentication;
anomalous volume;
unusual graph traversal;
agent behaviour;
secret-access pattern;
data export;
incident state;
threat intelligence.

Risk scoring SHALL not silently replace constitutional policy.

23.93.18. Rate and Volume Controls

Policies MAY constrain:

request rate;
graph traversal depth;
row count;
document count;
export volume;
event volume;
tool-call count;
model context size;
recipient count;
time window.

23.93.19. Bulk Operations

Bulk access or mutation SHALL require explicit policy evaluation for:

population scope;
classification;
tenant;
purpose;
authority;
rate;
export;
rollback;
provenance.

Permission to access one object SHALL not imply permission to access a population.

23.93.20. Authorization Replay

Historical authorization replay SHALL use historical:

identity state;
authority;
relationships;
policies;
classifications;
Security Context;
risk state;
incident state;
Runtime Bundle.

23.94. Tenant, White-Label and Organisational Isolation

Tenant Isolation prevents one tenant’s identities, data, relationships, events, secrets, configurations, agents, models, workflows and outcomes from being accessed, inferred, modified or influenced by another tenant without explicit governed authority.

White-label deployments SHALL preserve tenant isolation even where they share platform infrastructure.

23.94.1. Tenant Identity

Every tenant SHALL possess a stable Constitutional Identifier.

Tenant identity SHALL remain distinct from:

domain name;
brand;
customer account;
deployment;
organisation;
legal entity;
billing account;
database schema;
cloud subscription.

23.94.2. White-Label Identity

A white-label operator MAY manage one or more tenants.

White-label identity SHALL not collapse subordinate tenant boundaries.

23.94.3. Isolation Dimensions

Tenant isolation SHALL apply to:

identity;
authority;
data;
graph nodes;
graph relationships;
graph paths;
events;
workflows;
Tasks;
agent instances;
agent memory;
tools;
models;
secrets;
keys;
caches;
indexes;
vector stores;
search results;
logs;
backups;
analytics;
exports;
telemetry;
support access;
test environments.

23.94.4. Tenant Binding

Every tenant-bound object, event, request, session, workflow, Task, agent, secret and Runtime Outcome SHALL possess tenant identity or an explicit shared-scope classification.

23.94.5. Shared Core Knowledge

ZAYAZ Core constitutional knowledge MAY be shared across tenants.

Shared Core knowledge SHALL be:

explicitly classified as shared;
separated from tenant-specific overlays;
immutable to tenants unless extension points permit;
provenance-preserving;
versioned;
protected from tenant contamination.

23.94.6. Tenant Overlay

A Tenant Overlay MAY extend:

classifications;
Roles;
policies;
workflows;
schemas;
Value Providers;
validation profiles;
reasoning profiles;
security profiles;
reports;
UI projections.

An overlay SHALL not mutate another tenant’s overlay or Core constitutional meaning.

23.94.7. Tenant Context Propagation

Tenant identity SHALL propagate through:

API calls;
service calls;
events;
workflows;
Tasks;
graph queries;
database operations;
caches;
logs;
agent plans;
tool calls;
model retrieval;
exports.

Loss of tenant context SHALL fail closed.

23.94.8. Cross-Tenant Access

Cross-tenant access SHALL be prohibited by default.

Permitted cross-tenant access SHALL require:

explicit purpose;
legal or contractual basis;
authority;
participating tenant approval where applicable;
data classification review;
disclosure profile;
minimisation;
time limit;
audit;
provenance.

23.94.9. Tenant Administration

Tenant administrators SHALL possess authority only within their tenant scope unless explicit higher-order authority exists.

Platform administration SHALL not automatically grant access to tenant content.

23.94.10. Support Access

Support access SHALL be:

purpose-bound;
time-bound;
ticket-bound or incident-bound;
approved where required;
least privileged;
visible to the tenant where policy requires;
fully logged;
revocable;
retrospectively reviewable.

23.94.11. Impersonation Controls

Support impersonation SHALL preserve:

actual support actor;
represented tenant actor;
purpose;
approval;
scope;
start and end time;
actions;
evidence;
provenance.

Credential sharing SHALL be prohibited.

23.94.12. Tenant Data Stores

Tenant isolation MAY use:

separate databases;
separate schemas;
separate tables with enforced tenant keys;
row-level security;
graph partitions;
object-store prefixes;
separate encryption keys;
separate search indexes;
separate vector collections;
hybrid controls.

The constitutional requirement is isolation, not one mandatory implementation.

23.94.13. Tenant Query Enforcement

Every tenant-bound query SHALL include or derive tenant scope before execution.

Post-query filtering SHALL NOT be the sole protection for high-risk tenant data.

23.94.14. Tenant Cache Isolation

Caches SHALL be scoped by constitutionally relevant keys including:

tenant;
Security Context Fingerprint;
purpose;
classification;
resource version;
policy version.

Cross-tenant cache collision SHALL be treated as a critical security incident.

23.94.15. Tenant Search Isolation

Full-text, semantic and vector search SHALL enforce tenant isolation at retrieval time.

A shared embedding model SHALL not imply shared retrieval scope.

23.94.16. Tenant Analytics

Cross-tenant analytics MAY use:

anonymised data;
aggregated data;
differentially protected data;
explicitly consented data;
regulator-authorised data;
platform-security telemetry.

The permitted basis and disclosure risk SHALL be governed.

23.94.17. Tenant Model Use

Tenant data SHALL not be used for model training, fine-tuning, evaluation or prompt enrichment unless the tenant policy and legal basis explicitly permit it.

23.94.18. Tenant Export

Exports SHALL preserve tenant scope and prevent:

mixed-tenant files;
mixed-tenant report caches;
mixed-tenant event batches;
mixed-tenant model context;
mixed-tenant backup restoration.

23.94.19. Tenant Backup and Restore

Backups SHALL preserve tenant isolation, key separation, retention and restoration scope.

A tenant restore SHALL not overwrite or expose another tenant.

23.94.20. Tenant Deletion

Tenant deletion SHALL distinguish:

active data deletion;
legal hold;
retained audit evidence;
shared Core knowledge;
anonymised analytics;
backup expiration;
key destruction;
provenance retention.

23.94.21. Tenant Migration

Migration SHALL preserve:

tenant identity;
data integrity;
graph relationships;
keys;
policies;
workflows;
events;
Runtime Bundles;
agent memory policy;
audit;
provenance.

23.94.22. White-Label Custom Domain

A custom domain SHALL not be treated as the security boundary by itself.

Requests SHALL resolve and validate the expected white-label and tenant identity independently.

23.94.23. Organisational Isolation

Within a tenant, organisations and legal entities MAY require additional boundaries.

Organisational access SHALL be resolved through explicit scope and relationships.

23.94.24. Isolation Validation

HECATE SHALL validate:

tenant binding;
overlay order;
query scope;
cache scope;
index scope;
agent memory scope;
event scope;
key scope;
export scope;
backup scope;
support access;
provenance.

23.95. Data, Graph, Relationship and Inference Isolation

Security SHALL protect not only stored values but also graph structure, relationship existence, path reachability, derived knowledge, aggregate information and inferences.

A denied object SHALL not become discoverable through an authorised relationship unless policy permits that disclosure.

23.95.1. Data Security Object

A protected data resource SHALL preserve:

resource identity;
tenant;
owner;
steward;
classification;
purpose restrictions;
jurisdiction;
residency;
retention;
encryption;
masking policy;
export policy;
lifecycle;
provenance.

23.95.2. Property-Level Security

Security MAY apply to individual Constitutional Properties.

Property-level policy SHALL define:

readable values;
writable values;
mask format;
redaction;
inference restrictions;
purpose;
authority;
retention;
audit.

23.95.3. Field Masking

Masking MAY include:

full redaction;
partial masking;
tokenisation;
pseudonymisation;
generalisation;
range representation;
hash representation;
synthetic substitution.

Masking SHALL not be represented as source truth.

23.95.4. Row and Object Security

Object-level policy SHALL evaluate:

tenant;
ownership;
Role;
relationship;
classification;
lifecycle;
purpose;
jurisdiction;
time;
workflow state.

23.95.5. Relationship-Level Security

A Constitutional Relationship MAY have its own:

classification;
owner;
tenant;
authority;
visibility;
purpose restrictions;
temporal validity;
provenance.

Access to both endpoints SHALL not automatically imply access to the relationship.

23.95.6. Relationship Existence Leakage

Where relationship existence is sensitive, denial responses SHALL avoid revealing:

whether the relationship exists;
target identity;
count;
direction;
timestamp;
confidence;
provenance.

23.95.7. Graph Node Security

Node access SHALL evaluate:

node identity;
node type;
tenant;
classification;
purpose;
authority;
context;
temporal state.

23.95.8. Graph Edge Security

Edge access SHALL evaluate:

Relationship Type;
source role;
target role;
classification;
tenant;
direction;
temporal validity;
inference risk;
provenance.

23.95.9. Graph Path Security

A permitted start node and permitted end node SHALL not automatically permit traversal of the path between them.

Path policy MAY constrain:

Relationship Types;
maximum depth;
intermediate-node visibility;
tenant continuity;
jurisdiction continuity;
temporal continuity;
purpose;
aggregation;
explanation.

23.95.10. Hidden Intermediate Nodes

Where a path is permitted but an intermediate node is protected, the Runtime SHALL apply an explicit policy such as:

deny path;
return redacted path;
return abstract relationship;
return aggregate result;
require additional authority.

23.95.11. Graph Query Rewriting

A Graph Security Service MAY rewrite queries to enforce:

tenant predicates;
classification filters;
relationship restrictions;
temporal filters;
path limits;
result limits;
purpose obligations.

Rewriting SHALL be deterministic and auditable.

23.95.12. Graph Result Filtering

Post-query filtering MAY supplement but SHALL NOT replace secure query planning where protected graph structure could leak during execution or aggregation.

23.95.13. Aggregate Security

Aggregates MAY reveal protected information.

Aggregate policy SHALL consider:

population size;
minimum group threshold;
differencing risk;
repeated-query risk;
outliers;
linkage risk;
tenant mix;
temporal granularity;
geographic granularity.

23.95.14. Differencing Attack Prevention

The Runtime SHOULD prevent inference through repeated overlapping aggregate queries.

Controls MAY include:

query budgets;
minimum cohort size;
noise;
rounding;
result suppression;
temporal delay;
query-history analysis.

23.95.15. Search Isolation

Search SHALL protect:

document existence;
title;
snippet;
ranking;
embedding;
metadata;
facets;
counts;
spelling suggestions;
related-item suggestions.

23.95.16. Vector Retrieval Isolation

Vector retrieval SHALL enforce policy before protected content enters the model context.

Post-generation redaction SHALL not be the sole control.

23.95.17. Embedding Security

Embeddings SHALL be treated as potentially sensitive derived data.

Policies SHALL govern:

tenant scope;
model;
storage;
export;
retention;
deletion;
re-embedding;
inversion risk;
provenance.

23.95.18. Derived Assertion Security

A Derived Assertion SHALL inherit or resolve security classification from:

premises;
reasoning profile;
output type;
purpose;
tenant;
inference risk.

A lower-classified output SHALL require validated declassification logic.

23.95.19. Validation Finding Security

Validation Findings MAY reveal protected defects, evidence or subjects.

Finding access SHALL be independently governed.

23.95.20. Explanation Security

Explanations SHALL avoid revealing:

protected premises;
hidden relationships;
secret policy conditions;
confidential evidence;
private agent memory;
cross-tenant information;
security-sensitive infrastructure.

The explanation SHALL still disclose that protected material influenced the decision where permitted.

23.95.21. Event Security

Event policy SHALL govern:

Event Type visibility;
payload;
subject;
tenant;
correlation;
causation;
retention;
replay;
consumer scope.

23.95.22. Log Security

Logs SHALL not become an uncontrolled copy of protected data.

Logging policy SHALL govern:

field inclusion;
redaction;
tokenisation;
retention;
tenant;
access;
export;
legal hold;
integrity.

23.95.23. Inference Leakage

The Runtime SHALL protect against inference from:

error differences;
timing;
result count;
response size;
cache behaviour;
search ranking;
graph path length;
model response;
agent refusal detail;
event frequency;
identifier patterns.

23.95.24. Data Minimisation

Every access and execution SHOULD use the minimum constitutionally sufficient data.

Minimisation SHALL consider:

properties;
rows;
nodes;
relationships;
time period;
geography;
subject population;
evidence;
model context;
retention.

23.95.25. Purpose Limitation

Data obtained for one purpose SHALL not be reused for another purpose without a new Security Decision and lawful or constitutional basis.

23.95.26. Data Residency

Residency policy SHALL govern:

storage;
processing;
backups;
model invocation;
support access;
logging;
telemetry;
federation;
disaster recovery.

23.95.27. Cross-Border Transfer

A cross-border transfer SHALL preserve:

source jurisdiction;
destination jurisdiction;
legal basis;
tenant policy;
classification;
transfer mechanism;
encryption;
recipient;
purpose;
time;
evidence;
provenance.

23.95.28. Retention and Deletion

Retention policy SHALL apply across:

primary stores;
graph stores;
caches;
search indexes;
vector stores;
logs;
events;
backups;
agent memory;
temporary files;
analytics.

Deletion SHALL not silently destroy required constitutional provenance.

23.95.29. Legal Hold

Legal hold SHALL override ordinary deletion where authorised.

The Runtime SHALL preserve:

hold scope;
authority;
start;
end;
affected resources;
access restrictions;
provenance.

23.95.30. Security Validation

HECATE SHALL validate:

classification;
property-level policy;
object policy;
relationship policy;
path policy;
aggregate policy;
inference controls;
search isolation;
vector isolation;
event policy;
retention;
residency;
provenance.

23.96. Network, Service and Execution Isolation

Network, Service and Execution Isolation constrains communication and execution so that Runtime Components, agents, tools, workloads and external systems interact only through approved channels and environments.

Network reachability SHALL not imply constitutional permission.

23.96.1. Network Security Context

Network decisions MAY consider:

source workload;
destination workload;
Component identity;
Module;
tenant;
environment;
protocol;
port;
service identity;
encryption;
purpose;
data classification;
jurisdiction;
attestation;
incident state.

23.96.2. Service Identity

Service-to-service communication SHALL authenticate workload identity.

IP address, hostname or network segment SHALL not be the sole identity control.

23.96.3. Mutual Authentication

High-trust service communication SHOULD use mutual authentication with validated workload identity and revocation.

23.96.4. Network Segmentation

Segmentation MAY isolate:

public edge;
application services;
constitutional graph;
data stores;
evidence vaults;
key services;
build systems;
observability;
agent sandboxes;
model gateways;
assurance environments;
tenant-dedicated environments;
administrative control plane.

23.96.5. Micro-Segmentation

Micro-segmentation MAY enforce Component-to-Component communication rules.

Policies SHALL be generated or traceable to constitutional Component relationships and runtime needs.

23.96.6. Egress Control

Outbound network access SHALL be denied by default for high-risk Runtime Components and agents unless explicit policy permits it.

Egress policy SHALL govern:

destination;
protocol;
purpose;
data classification;
tenant;
jurisdiction;
volume;
credentials;
logging.

23.96.7. Ingress Control

Ingress policy SHALL govern:

source;
identity;
endpoint;
tenant;
request type;
rate;
payload size;
schema;
authentication;
replay protection;
provenance.

23.96.8. External Endpoint Registry

External endpoints SHALL be registered with:

Endpoint Identifier;
owner;
purpose;
domain;
jurisdiction;
trust profile;
data classification;
authentication;
certificate policy;
availability;
version;
provenance.

23.96.9. Service-to-Service Authorization

Every material service call SHALL preserve:

caller identity;
called Component;
action;
tenant;
purpose;
Security Context;
policy decision;
time;
outcome;
provenance.

23.96.10. Environment Isolation

Environments MAY include:

development;
test;
integration;
staging;
production;
assurance;
forensic;
replay;
simulation;
emergency.

Production data SHALL not enter lower-trust environments without governed transformation and authority.

23.96.11. Test Data

Test data SHALL be:

synthetic;
anonymised;
pseudonymised;
explicitly approved;
tenant-scoped;
time-limited.

Use of production data in test SHALL require explicit authority and evidence.

23.96.12. Runtime Sandbox

A sandbox SHALL define:

filesystem scope;
process scope;
network scope;
environment variables;
secrets;
system calls;
packages;
compute resources;
execution time;
output channels;
persistent storage;
tenant;
provenance.

23.96.13. Code Execution Isolation

Dynamic code execution SHALL require:

approved execution profile;
trusted code source or controlled generation;
sandbox;
resource limits;
network restrictions;
filesystem restrictions;
secret restrictions;
output validation;
audit;
termination control.

23.96.14. Agent Sandbox

Agent execution SHALL isolate:

prompts and instructions;
tenant data;
memory;
tools;
credentials;
files;
network;
model context;
outputs;
logs.

23.96.15. Model Gateway

External and internal model calls SHOULD pass through a governed Model Gateway enforcing:

model allowlist;
tenant policy;
data classification;
residency;
prompt filtering;
secret detection;
response validation;
rate limits;
logging;
provenance.

23.96.16. Browser and Retrieval Isolation

Browser, search and retrieval tools SHALL operate within explicit:

domain allowlists or policies;
tenant;
purpose;
download controls;
content classification;
malware scanning;
instruction isolation;
credential isolation;
retention.

23.96.17. File Isolation

File operations SHALL govern:

path;
tenant;
owner;
classification;
allowed file type;
size;
malware state;
execution permission;
retention;
external sharing;
provenance.

23.96.18. Container and Process Isolation

Runtime isolation MAY use:

containers;
virtual machines;
micro-virtual machines;
language sandboxes;
operating-system controls;
hardware enclaves;
serverless isolation;
dedicated hosts.

The selected mechanism SHALL match risk and assurance requirements.

23.96.19. Resource Quotas

Quotas MAY limit:

CPU;
memory;
storage;
network;
process count;
execution time;
event rate;
tool calls;
model tokens;
graph traversal;
database operations.

23.96.20. Denial-of-Service Protection

Controls MAY include:

rate limiting;
quotas;
circuit breakers;
queue limits;
workload shedding;
priority classes;
tenant fairness;
backpressure;
isolation pools;
emergency suspension.

23.96.21. Tenant Noisy-Neighbour Isolation

Shared infrastructure SHALL prevent one tenant from materially degrading another tenant’s:

availability;
latency;
queue capacity;
cache capacity;
model capacity;
graph capacity;
event processing;
assurance workload.

23.96.22. Administrative Plane Isolation

Administrative control planes SHALL be separated from ordinary tenant and application access.

Privileged changes SHALL require stronger identity, authority, evidence and approval.

23.96.23. Build and Runtime Separation

Build systems SHALL be isolated from production Runtime Components.

Production credentials SHALL not be available to ordinary build jobs.

23.96.24. Forensic Isolation

Forensic environments SHALL preserve evidence integrity and prevent contamination of production state.

23.96.25. Execution Isolation Validation

HECATE SHALL validate:

service identity;
network policy;
egress;
ingress;
environment;
sandbox;
resource quotas;
tenant scope;
model gateway;
tool connectivity;
administrative-plane controls;
provenance.

23.97. Secrets, Keys, Cryptographic Trust and Attestation

Cryptographic security SHALL be governed through explicit identity, purpose, lifecycle, authority, storage, rotation, revocation and evidence requirements.

Possession of a cryptographic key SHALL not by itself establish constitutional authority to use it.

23.97.1. Secret Object

A Secret Object SHALL possess:

Secret Identifier;
secret type;
owner;
tenant;
purpose;
authorised consumers;
storage location;
creation time;
expiration;
rotation policy;
revocation policy;
classification;
provenance.

Secret values SHALL not be stored directly in constitutional documentation or ordinary logs.

23.97.2. Secret Types

Secret Types MAY include:

API credential;
database credential;
signing key;
encryption key;
certificate private key;
federation secret;
webhook secret;
model-provider credential;
agent tool credential;
recovery secret;
emergency credential;
tenant-specific secret.

23.97.3. Secret Access

Secret access SHALL require:

authenticated workload or actor;
authority;
purpose;
tenant;
Runtime Environment;
attestation where required;
time limit;
audit;
provenance.

23.97.4. Secret Delivery

Secrets SHOULD be delivered:

just in time;
task-bound;
workload-bound;
short-lived;
in memory where possible;
without prompt or log exposure;
through authenticated channels.

23.97.5. Secret Rotation

Rotation SHALL define:

rotation interval;
trigger conditions;
overlapping validity;
consumer update;
failure handling;
revocation;
evidence;
provenance.

23.97.6. Secret Revocation

Revocation SHALL trigger impact analysis over:

active sessions;
workloads;
integrations;
agents;
tools;
events;
pending transactions;
disaster recovery.

23.97.7. Key Object

A Cryptographic Key Object SHALL preserve:

Key Identifier;
key type;
algorithm;
size or parameters;
owner;
tenant;
purpose;
permitted operations;
storage or module reference;
activation;
expiration;
rotation;
revocation;
destruction;
provenance.

23.97.8. Key Separation

Different purposes SHOULD use separate keys, including:

data encryption;
signing;
authentication;
tenant encryption;
backup encryption;
event signing;
Runtime Bundle signing;
evidence signing;
token signing.

23.97.9. Tenant Key Isolation

Tenant-specific encryption keys MAY be required by Security Profile.

Shared keys SHALL not erase tenant access boundaries.

23.97.10. Envelope Encryption

Envelope encryption MAY separate:

data-encryption key;
key-encryption key;
tenant key;
service key;
master key.

Key hierarchy SHALL preserve ownership and rotation semantics.

23.97.11. Cryptographic Signing

Signatures MAY protect:

Runtime Bundles;
Compiler Manifests;
Constitutional Events;
Governance Decisions;
Validation Outcomes;
assurance conclusions;
publications;
evidence;
federation messages;
software artefacts.

23.97.12. Signature Validation

Validation SHALL determine:

signer identity;
signer authority;
certificate chain;
algorithm;
signed scope;
content digest;
signing time;
revocation;
trust anchor;
policy compatibility.

A valid signature SHALL not prove that the signed content is constitutionally correct.

23.97.13. Trusted Timestamp

Trusted timestamps MAY establish:

signing time;
publication time;
evidence acquisition time;
transaction order;
event time support;
legal timing.

Timestamp authority and scope SHALL be explicit.

23.97.14. Certificate Lifecycle

Certificate governance SHALL include:

issuance;
identity binding;
purpose;
activation;
renewal;
rotation;
revocation;
expiration;
trust-store update;
evidence;
provenance.

23.97.15. Trust Anchor

Every Trust Anchor SHALL possess:

Trust Anchor Identifier;
owner;
purpose;
scope;
tenant or shared status;
jurisdiction;
activation;
expiration;
rotation;
revocation;
provenance.

23.97.16. Cryptographic Agility

Security Profiles SHOULD support algorithm and provider migration without changing constitutional identity.

Migration SHALL preserve:

old and new algorithms;
transition period;
compatibility;
re-signing or re-encryption policy;
validation;
evidence;
provenance.

23.97.17. Key Destruction

Key destruction SHALL identify:

authority;
purpose;
affected data;
recoverability;
retention obligations;
legal hold;
backup copies;
time;
evidence;
provenance.

23.97.18. Runtime Attestation

Runtime Attestation verifies that a workload, Component, environment or execution context matches an approved state.

Attestation MAY evaluate:

software digest;
container or image digest;
Runtime Bundle;
boot state;
configuration;
policy version;
hardware state;
environment;
tenant;
deployment;
provenance.

23.97.19. Attestation Evidence

Attestation Evidence SHALL preserve:

attested subject;
attester;
measurements;
expected measurements;
result;
time;
nonce or replay protection;
trust chain;
expiration;
provenance.

23.97.20. Attestation Failure

Attestation failure MAY trigger:

request denial;
workload quarantine;
secret denial;
network isolation;
agent suspension;
incident creation;
replacement deployment;
forensic capture.

23.97.21. Runtime Bundle Trust

Runtime Bundle activation SHALL validate:

bundle digest;
compiler lineage;
signatures;
signer authority;
included artefacts;
dependencies;
overlay order;
revocation;
environment compatibility;
provenance.

23.97.22. Evidence Vault

High-value Security Evidence MAY be stored in a controlled evidence vault providing:

immutable storage;
encryption;
access control;
legal hold;
retention;
trusted timestamp;
integrity verification;
export control;
provenance.

23.97.23. Cryptographic Eventing

The Runtime SHOULD emit events including:

SecretCreated;
SecretAccessed;
SecretRotated;
SecretRevoked;
KeyCreated;
KeyActivated;
KeyRotated;
KeyRevoked;
CertificateIssued;
CertificateRevoked;
SignatureValidated;
SignatureFailed;
AttestationSucceeded;
AttestationFailed;
TrustAnchorChanged.

23.98. Component, Dependency and Software Supply-Chain Security

Every Runtime Component, dependency, build artefact, container image, package, model artefact and deployment configuration SHALL possess traceable origin, integrity, approval and lifecycle.

Software supply-chain trust SHALL be evaluated continuously.

23.98.1. Component Security Profile

Every Component SHALL declare:

Component Identifier;
owning Module;
source repository;
build process;
artefact identities;
dependencies;
Runtime Bundle compatibility;
privileges;
network needs;
data access;
secrets;
tenant support;
security owner;
lifecycle;
version;
provenance.

23.98.2. Source Identity

Source code and configuration SHALL be traceable to:

repository;
path;
commit;
branch or tag;
author or automation;
review;
signature where applicable;
provenance.

23.98.3. Build Identity

Every build SHALL possess:

Build Identifier;
source commit;
build definition;
builder identity;
build environment;
dependency lock state;
build time;
outputs;
digests;
test results;
provenance.

23.98.4. Reproducible Build

Where feasible, critical artefacts SHOULD support reproducible or independently verifiable builds.

A non-reproducible build SHALL disclose its trust limitations.

23.98.5. Software Bill of Materials

A software artefact SHOULD possess a machine-readable dependency inventory containing:

package identity;
version;
source;
licence;
integrity digest;
dependency relationship;
build inclusion;
runtime inclusion;
provenance.

23.98.6. Dependency Policy

Dependency policy SHALL govern:

approved sources;
version constraints;
licence;
vulnerability status;
maintenance state;
cryptographic verification;
transitive dependencies;
prohibited packages;
update cadence;
exceptions.

23.98.7. Dependency Confusion Prevention

The build system SHALL prevent untrusted packages from substituting for approved internal or external dependencies.

Controls MAY include:

namespace ownership;
private registry priority;
lock files;
integrity hashes;
source allowlists;
signature verification.

23.98.8. Artefact Signing

Build artefacts MAY be signed.

Signature verification SHALL occur before deployment and Runtime Bundle activation where required.

23.98.9. Provenance Attestation

A build provenance attestation MAY identify:

source;
builder;
build definition;
materials;
environment;
outputs;
digests;
test results;
signing authority;
provenance.

23.98.10. Container and Image Security

Image policy MAY govern:

approved base images;
digest pinning;
package inventory;
vulnerability state;
non-root execution;
filesystem policy;
secret absence;
signature;
provenance.

23.98.11. Infrastructure Definition Security

Infrastructure and deployment definitions SHALL preserve:

source;
version;
approval;
policy validation;
secret references;
environment;
tenant impact;
change plan;
rollback;
provenance.

23.98.12. Configuration Security

Configuration SHALL be:

typed;
versioned;
environment-scoped;
tenant-scoped where applicable;
validated;
free from embedded secrets;
change-controlled;
provenance-preserving.

23.98.13. Runtime Drift

Runtime Drift occurs where deployed state differs materially from approved state.

Drift MAY include:

artefact digest;
dependency;
configuration;
policy;
secret;
network rule;
Runtime Bundle;
environment variable;
model version;
agent instruction.

23.98.14. Drift Response

Material drift SHALL trigger:

detection event;
affected Component identification;
risk assessment;
secret restriction;
traffic restriction;
quarantine;
rollback;
redeployment;
incident;
provenance.

23.98.15. Vulnerability Object

A Vulnerability Object SHOULD preserve:

vulnerability identity;
affected artefact;
affected Component;
severity;
exploitability;
exposure;
tenant impact;
data impact;
fix availability;
compensating controls;
remediation state;
provenance.

23.98.16. Vulnerability Prioritisation

Priority SHOULD consider:

constitutional criticality;
runtime exposure;
reachable code;
data classification;
tenant count;
authority level;
exploit evidence;
compensating controls;
publication impact;
assurance impact.

23.98.17. Patch Governance

Patching SHALL preserve:

affected artefact;
patch version;
source;
test results;
compatibility;
change authority;
deployment plan;
rollback;
affected Runtime Bundles;
provenance.

23.98.18. Emergency Patch

Emergency patches SHALL follow Part VI Emergency Authority and SHALL not bypass non-bypassable integrity and provenance controls.

23.98.19. Deployment Gate

Deployment MAY require:

artefact signature;
build provenance;
vulnerability threshold;
conformance tests;
HECATE validation;
approval;
Runtime Bundle compatibility;
rollback readiness;
tenant-impact analysis;
attestation.

23.98.20. Promotion

Promotion across environments SHALL preserve artefact identity.

Rebuilding different binaries for each environment SHOULD be avoided where it breaks artefact equivalence.

23.98.21. Rollback

Rollback SHALL identify:

prior approved artefact;
compatibility;
data migration state;
Runtime Bundle;
policy versions;
authority;
validation;
provenance.

23.98.22. Model Artefact Security

Model artefacts SHALL preserve:

model identity;
version;
provider;
source;
digest where available;
deployment;
safety configuration;
evaluation;
data policy;
residency;
provenance.

23.98.23. Compiler Security

The Constitutional Compiler Framework SHALL protect against:

unauthorised source modification;
untrusted plugins;
dependency compromise;
non-deterministic compiler state;
artefact substitution;
manifest tampering;
signing-key misuse;
projection-loss concealment.

23.98.24. Security Conformance Tests

Component conformance SHOULD include:

tenant isolation;
secret handling;
policy enforcement;
network policy;
event integrity;
attestation;
vulnerability policy;
rollback;
logging;
provenance.

23.98.25. Supply-Chain Events

The Runtime SHOULD emit:

BuildCompleted;
ArtefactSigned;
ArtefactVerified;
DependencyChanged;
VulnerabilityDetected;
VulnerabilityRemediated;
DeploymentApproved;
DeploymentCompleted;
DriftDetected;
RuntimeQuarantined;
RollbackCompleted.

23.99. Agent, AI and Tool Security

Agent and AI security SHALL protect constitutional authority, tenant boundaries, confidential data, instruction integrity, tool use, model context, memory, outputs and side effects.

An AI system SHALL not be trusted merely because it is capable, fluent or approved for another purpose.

23.99.1. Agent Security Profile

Every Agent Definition SHALL possess or resolve an Agent Security Profile defining:

permitted tenants;
permitted purposes;
permitted data classifications;
permitted tools;
permitted models;
permitted environments;
permitted external endpoints;
permitted memory;
prohibited content;
side-effect limits;
oversight;
incident treatment;
provenance.

23.99.2. Instruction Hierarchy

Instruction authority SHALL be explicit.

A reference hierarchy MAY distinguish:

constitutional system instructions;
governed Agent Definition instructions;
Workflow Task instructions;
authorised human instructions;
tool contracts;
retrieved content;
external content;
untrusted user content.

Lower-authority content SHALL not override higher-authority instructions.

23.99.3. Prompt Injection

Prompt injection SHALL be treated as an attempt by data or lower-authority content to acquire instruction authority.

Controls MAY include:

content labelling;
source isolation;
instruction parsing;
tool restrictions;
retrieval filtering;
output validation;
secret isolation;
human approval;
sandboxing;
anomaly detection.

23.99.4. Indirect Injection

Documents, web pages, messages, images, tool outputs and retrieved data SHALL be treated as untrusted unless their instruction authority is explicitly established.

23.99.5. Agent Context Isolation

Model context SHALL be scoped by:

tenant;
purpose;
Task;
Workflow Instance;
Security Context;
data classification;
retention;
model policy.

23.99.6. Context Minimisation

Only constitutionally necessary content SHOULD enter model context.

The Runtime SHOULD exclude:

unrelated tenant data;
secrets;
unnecessary personal data;
hidden system configuration;
unrelated evidence;
privileged policy details;
historical memory without purpose.

23.99.7. Secret Protection

Agents SHALL not receive raw secrets where a brokered tool invocation can satisfy the purpose.

Secrets SHALL not be stored in:

prompts;
model context;
memory;
outputs;
logs;
explanations;
agent messages.

23.99.8. Tool Allowlist

An agent SHALL invoke only tools resolved through its Tool Set and current Security Context.

Tool names generated by a model SHALL not create tool permission.

23.99.9. Tool Parameter Security

Tool parameters SHALL be validated for:

schema;
tenant;
subject;
action;
path;
endpoint;
query;
command;
data classification;
side effects;
idempotency;
authority.

23.99.10. Confused-Deputy Prevention

A privileged tool or Component SHALL not perform an action merely because a less-privileged agent requests it.

The tool SHALL independently validate the caller, purpose, tenant, authority and resource.

23.99.11. Agent-to-Agent Security

Agent messages SHALL enforce:

sender identity;
receiver identity;
tenant;
purpose;
message type;
content classification;
authority;
correlation;
provenance.

23.99.12. Cross-Agent Instruction Injection

An agent message SHALL not acquire higher instruction authority solely because it was produced by another agent.

23.99.13. Agent Memory Security

Memory controls SHALL prevent:

cross-tenant leakage;
cross-purpose reuse;
stale authority retention;
malicious instruction persistence;
secret retention;
personal-data over-retention;
simulation contamination;
unvalidated assertion activation.

23.99.14. Retrieval Security

Retrieval SHALL enforce policy before content enters model context.

Retrieval results SHALL preserve:

source;
tenant;
classification;
trust;
time;
purpose;
provenance.

23.99.15. Model Provider Security

External model use SHALL govern:

provider identity;
model identity;
tenant policy;
data retention;
model-training use;
residency;
encryption;
logging;
subprocessors where relevant;
outage policy;
fallback;
provenance.

23.99.16. Model Output Security

Outputs SHALL be evaluated for:

sensitive data;
tenant leakage;
secret leakage;
unsupported authority claims;
hallucinated identifiers;
prohibited instructions;
unsafe tool requests;
malicious code;
external links;
policy conflict;
provenance.

23.99.17. Code Generation Security

Generated code SHALL be treated as untrusted until:

reviewed or validated;
scanned;
sandboxed;
dependency-checked;
authority-approved;
tested;
provenance-preserving.

23.99.18. Agent Data Exfiltration

The Runtime SHALL detect and prevent exfiltration through:

tool parameters;
URLs;
DNS-like channels;
file uploads;
model prompts;
event payloads;
agent messages;
logs;
encoded outputs;
public publication.

23.99.19. Agent Behaviour Monitoring

Monitoring MAY evaluate:

unusual tool sequence;
repeated denied actions;
scope expansion;
secret access;
cross-tenant attempts;
excessive retrieval;
unusual output volume;
repeated prompt-injection response;
budget anomalies;
model drift;
unexplained plan changes.

23.99.20. Agent Quarantine

An Agent Instance MAY be quarantined where:

identity is uncertain;
model version changes unexpectedly;
prompt injection is suspected;
tool misuse occurs;
tenant leakage is suspected;
memory contamination occurs;
attestation fails;
repeated invalid output occurs.

23.99.21. Agent Kill Control

High-risk agent execution SHALL support independent termination that:

stops new actions;
blocks tool calls;
revokes credentials;
isolates memory;
preserves evidence;
triggers workflow recovery;
prevents provenance deletion.

23.99.22. Human Oversight Security

Oversight interfaces SHALL protect against:

approval spoofing;
hidden agent changes;
misleading summaries;
concealed evidence;
automation bias;
session hijacking;
cross-tenant review;
replay attacks.

23.99.23. Agent Security Testing

Testing SHOULD include:

direct prompt injection;
indirect prompt injection;
tool misuse;
confused deputy;
data exfiltration;
tenant leakage;
memory poisoning;
agent impersonation;
authority escalation;
model substitution;
malicious file handling;
cross-agent attack;
kill-control verification;
recovery verification.

23.99.24. AI Security Finding

An AI Security Finding SHALL preserve:

Agent Definition;
Agent Instance;
model;
Task;
Security Context;
attack or defect type;
evidence;
affected data;
side effects;
severity;
remediation;
provenance.

23.99.25. AI Security Events

The Runtime SHOULD emit:

PromptInjectionDetected;
PromptInjectionBlocked;
ToolRequestDenied;
AgentAuthorityViolation;
AgentScopeExpansionAttempted;
AgentDataLeakageSuspected;
AgentQuarantined;
AgentCredentialRevoked;
ModelChanged;
ModelDriftDetected;
MemoryContaminationDetected;
KillControlActivated.

23.100. Threat Detection, Incident Response, Security Provenance and Conformance

The Security Runtime SHALL detect suspicious activity, represent security incidents explicitly, coordinate containment and recovery, preserve forensic evidence and support independent assurance.

A security alert SHALL not automatically be treated as a confirmed incident.

A confirmed incident SHALL not be closed merely because service availability has been restored.

23.100.1. Security Signal

A Security Signal is a potentially relevant observation from:

authentication;
policy enforcement;
network control;
Runtime Component;
agent;
tool;
workload attestation;
secret access;
key service;
event stream;
graph query;
database;
model gateway;
endpoint;
vulnerability scanner;
human report;
external notification.

23.100.2. Security Alert

A Security Alert is a governed object created when one or more signals meet an alerting condition.

It SHALL preserve:

Alert Identifier;
signal sources;
detection rule;
subject;
resource;
tenant;
time;
severity;
confidence;
status;
provenance.

23.100.3. Security Incident

A Security Incident is a governed event or condition that has compromised or materially threatened confidentiality, integrity, availability, authority, tenant isolation, cryptographic trust, provenance or safe execution.

23.100.4. Incident Identity

Every incident SHALL possess:

Incident Identifier;
incident type;
affected tenants;
affected organisations;
affected subjects;
affected resources;
affected Modules;
affected Components;
detection time;
suspected start;
confirmed period;
severity;
materiality;
regulatory significance;
assurance significance;
status;
owner;
response team;
authority;
provenance.

23.100.5. Incident Types

Incident Types MAY include:

identity compromise;
credential compromise;
tenant data exposure;
cross-tenant leakage;
unauthorised access;
privilege escalation;
policy bypass;
secret exposure;
key compromise;
signature compromise;
Runtime Bundle compromise;
software supply-chain compromise;
malware;
ransomware;
data integrity incident;
event tampering;
provenance tampering;
agent compromise;
prompt injection;
model substitution;
data exfiltration;
denial of service;
availability failure;
unauthorised deletion;
backup compromise;
federation compromise.

23.100.6. Incident Lifecycle

A reference lifecycle is:

Signal Detected
        │
        ▼
Alert Created
        │
        ▼
Triage
        │
        ├──► False Positive
        ├──► Monitoring
        ▼
Incident Confirmed
        │
        ▼
Contained
        │
        ▼
Eradicated
        │
        ▼
Recovered
        │
        ▼
Validated
        │
        ▼
Reviewed
        │
        ▼
Closed

23.100.7. Incident Severity

Severity MAY consider:

data classification;
tenant count;
legal-entity count;
confidentiality impact;
integrity impact;
availability impact;
authority impact;
publication impact;
assurance impact;
financial impact;
environmental impact;
exploitability;
persistence;
recoverability.

23.100.8. Incident Authority

Incident response SHALL operate under explicit authority.

Emergency actions SHALL follow Part VI Emergency Authority.

23.100.9. Containment

Containment MAY include:

session revocation;
credential revocation;
secret rotation;
key revocation;
workload quarantine;
agent quarantine;
network isolation;
tenant isolation;
feature suspension;
event-consumer suspension;
deployment rollback;
tool disablement;
model disablement;
publication suspension.

23.100.10. Evidence Preservation

Incident response SHALL preserve:

events;
logs;
traces;
identity state;
policy decisions;
Security Contexts;
agent state;
tool calls;
memory references;
Runtime Bundles;
workloads;
configurations;
network state;
cryptographic evidence;
timestamps;
chain of custody.

23.100.11. Forensic Snapshot

A Forensic Snapshot MAY capture:

affected state;
process state;
filesystem state;
memory state where lawful;
event position;
configuration;
workload identity;
attestation;
network connections;
secrets references;
model state;
agent state;
provenance.

23.100.12. Chain of Custody

Forensic evidence SHALL preserve:

collector;
collection authority;
collection time;
source;
method;
digest;
transfer;
storage;
access;
redaction;
analysis;
provenance.

23.100.13. Eradication

Eradication MAY include:

compromised credential removal;
malicious artefact removal;
vulnerable Component replacement;
configuration correction;
policy correction;
agent memory purge;
model replacement;
dependency remediation;
environment rebuild.

23.100.14. Recovery

Recovery SHALL verify:

trusted artefacts;
trusted Runtime Bundle;
valid policies;
valid secrets and keys;
restored tenant isolation;
restored data integrity;
restored event integrity;
restored workflow state;
restored agent controls;
monitoring readiness;
rollback readiness.

23.100.15. Security Validation

HECATE SHALL validate recovery before ordinary operation resumes where the incident is material.

Validation SHALL include:

root cause addressed;
compromised identities revoked;
secrets rotated;
keys treated appropriately;
Components attested;
tenant boundaries tested;
data integrity verified;
event and provenance integrity verified;
agent and tool security verified;
residual risk recorded.

23.100.16. Notification

Notification MAY be required to:

affected tenant;
white-label operator;
internal governance;
legal authority;
regulator;
assurance provider;
customer;
data subject;
supplier;
public authority.

Notification SHALL preserve authority, content, time, legal basis and provenance.

23.100.17. Incident Communication

Incident communication SHALL:

distinguish known facts from hypotheses;
preserve confidentiality;
avoid cross-tenant disclosure;
identify scope;
identify uncertainty;
identify next actions;
preserve approval;
preserve provenance.

23.100.18. Root-Cause Analysis

Root-cause analysis SHOULD identify:

direct cause;
contributing causes;
control failures;
detection failures;
governance failures;
Component failures;
agent failures;
process failures;
tenant impact;
systemic impact;
remediation;
preventive action.

23.100.19. Corrective and Preventive Action

Actions MAY include:

policy change;
Component change;
architecture change;
tenant-isolation improvement;
secret rotation;
key migration;
workflow change;
agent control change;
tool restriction;
training;
monitoring improvement;
conformance-test addition;
Runtime Bundle replacement.

23.100.20. Incident Closure

An incident SHALL close only when:

containment is complete;
eradication is complete;
recovery is validated;
affected tenants are reconciled;
required notifications are complete;
remediation is assigned;
evidence is sealed;
retrospective review is complete;
residual risk is accepted by authority;
provenance is complete.

23.100.21. Security Provenance

Security Provenance SHALL include:

Security Request;
Security Context;
Security Profile;
Security Policies;
identity assertions;
authentication;
authority;
Security Decision;
obligations;
enforcement;
protected resource;
tenant;
Runtime Environment;
Component;
agent;
tool;
network path where relevant;
secret and key events;
attestation;
alerts;
incident actions;
recovery;
timestamps;
signatures;
trust state.

23.100.22. Security Decision Receipt

Every high-risk Security Decision SHOULD produce a Security Decision Receipt containing:

request fingerprint;
Security Context Fingerprint;
subject;
resource;
action;
purpose;
policy identities and versions;
authority result;
decision;
obligations;
expiration;
enforcement result;
signatures or integrity metadata;
provenance.

23.100.23. Security Event Integrity

Security Events SHALL be protected against undetected alteration.

Permitted mechanisms MAY include:

append-only stores;
cryptographic hash chains;
digital signatures;
trusted timestamps;
transparency logs;
replicated evidence stores;
hardware-backed attestations.

23.100.24. Security Evidence Completeness

Completeness MAY be classified as:

complete;
complete with controlled redaction;
partially complete;
materially incomplete;
reconstructed;
disputed;
unavailable.

Materially incomplete evidence SHALL prevent an unqualified high-assurance security conclusion.

23.100.25. Security Replay

The Runtime SHALL support replay of:

authentication;
Security Context Assembly;
policy resolution;
authorization;
enforcement;
agent tool use;
event consumption;
incident timeline;
containment;
recovery.

Replay SHALL use historical policy, identity, authority, trust and Runtime Bundle state.

23.100.26. Security Diff

A Security Diff SHOULD identify changes in:

identity;
authority;
classification;
policy;
Security Context;
tenant boundary;
network policy;
secret state;
key state;
Component attestation;
Runtime Bundle;
agent policy;
tool policy;
incident state;
decision.

23.100.27. Security Impact Analysis

Changes or incidents SHALL support impact analysis over:

identities;
tenants;
organisations;
data;
graphs;
relationships;
workflows;
agents;
tools;
Runtime Outcomes;
reports;
disclosures;
publications;
assurance conclusions;
Modules;
Components.

23.100.28. Security Metrics

Operational metrics MAY include:

authentication failure;
step-up rate;
denied request rate;
cross-tenant attempt rate;
secret access rate;
secret-rotation age;
key-rotation age;
attestation failure;
drift;
vulnerability age;
prompt-injection detection;
agent quarantine;
incident detection time;
containment time;
recovery time;
evidence completeness.

Metrics SHALL not redefine constitutional security status.

23.100.29. Pergamum Pulse Integration

Pergamum Pulse MAY derive intelligence including:

identity risk;
authority concentration;
stale access;
tenant-isolation risk;
graph-inference risk;
suspicious relationship traversal;
secret-use anomalies;
key-rotation risk;
Component drift;
software supply-chain risk;
agent-security risk;
tool misuse;
incident recurrence;
control coverage gaps;
response bottlenecks;
security evidence weakness;
Module-level risk;
Component-level risk;
white-label divergence;
systemic security debt.

Pergamum Pulse SHALL preserve:

Module lineage;
Component lineage;
identity lineage;
tenant lineage;
Security Context lineage;
policy lineage;
decision lineage;
data and graph lineage;
agent lineage;
tool lineage;
Runtime Bundle lineage;
event lineage;
incident lineage;
temporal validity;
provenance.

Derived intelligence SHALL remain Intelligence Layer assertions until governed activation.

23.100.30. Security Conformance Suite

The Constitutional Compiler Framework SHOULD generate a Security and Isolation Conformance Suite containing:

identity mapping cases;
authentication-assurance cases;
workload-identity cases;
expired-session cases;
policy-composition cases;
deny-override cases;
purpose-limitation cases;
tenant-isolation cases;
cross-tenant denial cases;
cache-isolation cases;
graph-node security cases;
graph-edge security cases;
graph-path security cases;
aggregate-inference cases;
vector-retrieval isolation cases;
egress-control cases;
sandbox-escape cases;
secret-access cases;
key-rotation cases;
signature-authority cases;
attestation cases;
Runtime Bundle trust cases;
dependency-compromise cases;
runtime-drift cases;
prompt-injection cases;
confused-deputy cases;
agent-exfiltration cases;
kill-control cases;
incident-replay cases;
recovery-validation cases;
evidence-completeness cases.

Part IX Conformance

A Constitutional Runtime Framework implementation conforms to Part IX where it:

treats security and isolation as constitutional runtime behaviour rather than infrastructure configuration alone;
requires an explicit Security Context for material requests and executions;
resolves Security Profiles and Security Policies through Constitutional Resolution Policies;
distinguishes identity, authentication, technical access and constitutional authority;
preserves stable identities for humans, organisations, workloads, Components, agents, devices and federated systems;
requires workload identity for service-to-service trust;
produces explicit Security Decisions and enforceable obligations;
fails closed where identity, tenant, purpose, policy, trust or enforcement cannot be established;
applies policy enforcement at API, graph, data, event, workflow, agent, tool, publication and secret boundaries;
preserves tenant and white-label isolation across data, graphs, events, workflows, agents, memory, tools, caches, indexes, logs, backups and analytics;
prohibits cross-tenant access by default;
prevents platform and support administration from automatically granting tenant-content access;
governs cross-tenant access through explicit purpose, authority, scope, minimisation and evidence;
protects node, relationship, path, aggregate and inference semantics independently;
enforces policy before protected content enters search, vector retrieval or model context;
governs data classification, masking, residency, transfer, retention, deletion and legal hold;
distinguishes network reachability from service identity and constitutional permission;
enforces environment, network, service, process, sandbox and administrative-plane isolation;
governs secrets and cryptographic keys through explicit identity, purpose, lifecycle, rotation and revocation;
distinguishes signature validity from signer authority and content validity;
validates Runtime Bundles, workloads and Components through trust and attestation;
preserves source, build, dependency, artefact and deployment lineage;
detects runtime and software supply-chain drift;
governs AI instructions, retrieval, memory, model context, tools and side effects;
prevents external content from acquiring instruction authority;
prevents confused-deputy, prompt-injection, data-exfiltration and cross-agent authority attacks;
provides quarantine and independent kill controls for high-risk agents;
represents alerts and incidents as governed objects with explicit lifecycle;
preserves forensic evidence and chain of custody;
validates recovery through HECATE before ordinary operation resumes after material incidents;
preserves Security Decision Receipts and complete Security Provenance;
supports security replay, diff and impact analysis;
preserves both Module and Component lineage;
prevents emergency security access from becoming permanent or unrestricted;
prevents security redaction, deletion or recovery from erasing required constitutional provenance.

Part IX Foundational Principle

Security and Isolation Runtime is the governed constitutional mechanism through which ZAYAZ establishes trusted identity, resolves security policy, enforces purpose and authority, isolates tenants and execution environments, protects knowledge and cryptographic materials, constrains agents and tools, detects threats and preserves independently verifiable Security Evidence.

Authentication SHALL not imply authority. Network reachability SHALL not imply permission. Encryption SHALL not replace access control. Access to graph endpoints SHALL not imply access to their relationships or paths. White-label deployment SHALL not collapse tenant boundaries. Agent capability SHALL not imply permission, and external content SHALL not acquire instruction authority merely because an AI system can read it.

Every material security decision SHALL preserve its Security Request, Security Context, Security Profile, policies, identity assertions, authority, tenant, classification, purpose, trust state, obligations, enforcement result, Runtime Bundle, Module lineage, Component lineage, agent and tool lineage, temporal validity and complete provenance.

By making security contextual, deterministic, continuously evaluated, tenant-aware, graph-aware, cryptographically verifiable, agent-safe and replayable, ZAYAZ protects constitutional integrity across white-label deployments, ESG data, supply chains, evidence, reports, agents and distributed runtime operations without sacrificing explainability, auditability or accountable governance.

GitHub Repo Request for Change (RFC)

Part IX — Security and Isolation​

23.90. Security Runtime​

23.90.1. Purpose​

23.90.2. Security Boundary​

23.90.3. Security Subject​

23.90.4. Security Resource​

23.90.5. Security Action​

23.90.6. Security Request​

23.90.7. Security Runtime Components​

23.90.8. Security Decision​

23.90.9. Security Obligations​

23.90.10. Policy Enforcement Points​

23.90.11. Continuous Security​

23.90.12. Security Determinism​

23.90.13. Fail-Closed Behaviour​

23.90.14. Security Availability​

23.90.15. HECATE Validation​

23.91. Security Context, Classification and Profiles​

23.91.1. Security Context Dimensions​

23.91.2. Security Context Sources​

23.91.3. Security Context Assembly​

23.91.4. Context Precedence​

23.91.5. Restriction Intersection​

23.91.6. Security Context Sealing​

23.91.7. Security Context Fingerprint​

23.91.8. Classification Object​

23.91.9. Classification Dimensions​

23.91.10. Classification Inheritance​

23.91.11. Classification Aggregation​

23.91.12. Derived Classification​

23.91.13. Classification Change​

23.91.14. Security Profile​

23.91.15. Security Profile Types​

23.91.16. Profile Resolution​

23.91.17. Profile Composition​

23.91.18. White-Label Profile Order​

23.91.19. Security Context Validation​

23.92. Identity, Authentication and Workload Identity​

23.92.1. Identity Types​

23.92.2. Constitutional Identity​

23.92.3. Identity Record​

23.92.4. Identity Proofing​

23.92.5. Authentication Factors​

23.92.6. Authentication Assurance​

23.92.7. Step-Up Authentication​

23.92.8. Session Identity​

23.92.9. Session Binding​

23.92.10. Session Renewal​

23.92.11. Session Revocation​

23.92.12. Workload Identity​

23.92.13. Workload Identity Record​

23.92.14. Component Identity​

23.92.15. Agent Identity​

23.92.16. Device Identity​

23.92.17. Federation Identity​

23.92.18. Identity Collision​

23.92.19. Orphan Identity​

23.92.20. Impersonation​

23.92.21. Break-Glass Identity​

23.92.22. Identity Events​

23.93. Authorization, Policy Enforcement and Decisioning​

23.93.1. Authorization Model​

23.93.2. Role-Based Controls​

23.93.3. Attribute-Based Controls​

23.93.4. Relationship-Based Controls​

23.93.5. Purpose-Based Controls​

23.93.6. Policy Object​

23.93.7. Policy Resolution​

23.93.8. Policy Composition​

23.93.9. Deny Overrides​

23.93.10. Non-Overrideable Denials​

23.93.11. Policy Decision Point​

23.93.12. Policy Enforcement Point​

23.93.13. Decision Scope​

23.93.14. Decision Expiration​

23.93.15. Decision Caching​

23.93.16. Decision Explanation​

23.93.17. Dynamic Risk​

23.93.18. Rate and Volume Controls​

23.93.19. Bulk Operations​

Part IX — Security and Isolation

23.90. Security Runtime

23.90.1. Purpose

23.90.2. Security Boundary

23.90.3. Security Subject

23.90.4. Security Resource

23.90.5. Security Action

23.90.6. Security Request

23.90.7. Security Runtime Components

23.90.8. Security Decision

23.90.9. Security Obligations

23.90.10. Policy Enforcement Points

23.90.11. Continuous Security

23.90.12. Security Determinism

23.90.13. Fail-Closed Behaviour

23.90.14. Security Availability

23.90.15. HECATE Validation

23.91. Security Context, Classification and Profiles

23.91.1. Security Context Dimensions

23.91.2. Security Context Sources

23.91.3. Security Context Assembly

23.91.4. Context Precedence

23.91.5. Restriction Intersection

23.91.6. Security Context Sealing

23.91.7. Security Context Fingerprint

23.91.8. Classification Object

23.91.9. Classification Dimensions

23.91.10. Classification Inheritance

23.91.11. Classification Aggregation

23.91.12. Derived Classification

23.91.13. Classification Change

23.91.14. Security Profile

23.91.15. Security Profile Types

23.91.16. Profile Resolution

23.91.17. Profile Composition

23.91.18. White-Label Profile Order

23.91.19. Security Context Validation

23.92. Identity, Authentication and Workload Identity

23.92.1. Identity Types

23.92.2. Constitutional Identity

23.92.3. Identity Record

23.92.4. Identity Proofing

23.92.5. Authentication Factors

23.92.6. Authentication Assurance

23.92.7. Step-Up Authentication

23.92.8. Session Identity

23.92.9. Session Binding

23.92.10. Session Renewal

23.92.11. Session Revocation

23.92.12. Workload Identity

23.92.13. Workload Identity Record

23.92.14. Component Identity

23.92.15. Agent Identity

23.92.16. Device Identity

23.92.17. Federation Identity

23.92.18. Identity Collision

23.92.19. Orphan Identity

23.92.20. Impersonation

23.92.21. Break-Glass Identity

23.92.22. Identity Events

23.93. Authorization, Policy Enforcement and Decisioning

23.93.1. Authorization Model

23.93.2. Role-Based Controls

23.93.3. Attribute-Based Controls

23.93.4. Relationship-Based Controls

23.93.5. Purpose-Based Controls

23.93.6. Policy Object

23.93.7. Policy Resolution

23.93.8. Policy Composition

23.93.9. Deny Overrides

23.93.10. Non-Overrideable Denials

23.93.11. Policy Decision Point

23.93.12. Policy Enforcement Point

23.93.13. Decision Scope

23.93.14. Decision Expiration

23.93.15. Decision Caching

23.93.16. Decision Explanation

23.93.17. Dynamic Risk

23.93.18. Rate and Volume Controls

23.93.19. Bulk Operations