> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/cooperation/nexus-guilds/platforms/x.-security.md). # X. Security Security, Identity, and Audit Architecture **Where this fits:** all six sectors ([The Model](/organization/model.md)) · [Labs](/organization/programme/labs.md), [Risk Academy](/organization/programme/academy.md) · communities of practice by sector, supplying the questions of the Labs pillar; National Working Groups ([NWG](/organization/governance-in-operation/nwg.md)) · community of practice. **In brief.** b. Read against the international frameworks it serves ([UN General Assembly 2015](https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030); [FAO 2014](https://www.fao.org/4/bl496e/bl496e.pdf); [One Health High-Level Expert Panel (OHHLEP) et al. 2022](https://doi.org/10.1371/journal.ppat.1010537)) and the [Nexus Standards](/organization/institutions/nexus-standards.md) that govern its records ([NS-0](https://nexustandards.com/standards/ns-0/), [NS-13](https://nexustandards.com/standards/ns-13/)). "An experiment is exploratory: its results are labelled as such and become evidence only after the Foundry rebuilds and the Universe tests them." (Labs pillar boundary). Ordinary participation has no fee. Paid work, internships and fellowships are separate arrangements, and unqualified contributors never take safety-critical tasks. {% hint style="info" %} **Read with the current model (2026-10-21).** * Everything this page describes is a design in formation. No national, regional or global consortium is recorded as constituted or active; the current service level is R0, information and enquiries ([Status and service levels](/organization/governance-in-operation/status-and-service-levels.md)). Where the text below reads as operation, read it as design. * Tokens, credits and on-chain instruments in this text are earlier design ideas; no token, credit or digital asset is issued, offered or traded under the programme. * Completion is recorded, not credentialed, until [Risk Academy](/organization/institutions/risk-academy.md) has an issuer, an assessment method and a revocation path on record; GCRI Canada is issuer of record ([Risk Academy](/organization/programme/academy.md)). {% endhint %} ### 10.1 Security Objective 10.1.1 **Security objective.** Nexus Platforms must provide security posture that is:\ a. **sovereignty-preserving** (tenant and jurisdiction boundaries are enforceable),\ b. **handling-aware** (Public-Safe / Controlled / Restricted are materially different security regimes),\ c. **records-first** (security-relevant acts are captured as record-valid events), and\ d. **cloneable** (a node can be replicated without weakening controls or losing audit continuity). 10.1.2 **Threat model (practical).** Nexus must assume:\ a. credential theft (password reuse, phishing, session hijack),\ b. privilege misuse (insider, compromised admin, role-marker drift),\ c. data leakage via exports, screenshots, share links, and “helpful” AI summaries,\ d. scraping and bot abuse (public content harvesting, enumeration of controlled resources),\ e. supply chain vulnerabilities (dependencies, plugins/components, CI/CD),\ f. model/provider risk (prompt injection, data retention, vendor incidents),\ g. cross-tenant bleed (misconfigured indices, shared caches, shared object storage),\ h. sovereignty break (data leaving jurisdiction via logs, backups, analytics, or provider routing). 10.1.3 **Non-executing perimeter enforcement is a security requirement.** Security controls must prevent the platform from being used as:\ a. a deal room (solicitation, placement, underwriting enablement),\ b. an operations command center (targeting instructions, exploit guidance, critical infrastructure abuse),\ c. an implied-authority channel (false badges, unrecorded “approvals,” or misleading claims).\ This is enforced through handling + workflow gates + assistant behavior rules + misrepresentation takedown mechanisms. *** ### 10.2 Identity and Access Management (IAM): Federation, MFA, and Purpose-Bound Access 10.2.1 **Identity architecture (**[**NXS-NSF**](/organization/systems/nxs-nsf.md) **(trust, authorization and assurance) Credential + Institutional Federation).** Every user has a NXS-NSF Credential identity that supports:\ a. **native account** (platform-managed), and/or\ b. **federated account** (institution-managed via SSO) for national/regional/institutional deployments.\ Federation is optional but recommended for Controlled/Restricted environments. 10.2.2 **Authentication requirements by handling class (step-up).**\ a. **Public-Safe:** standard login optional (public browsing allowed as policy permits), rate limited.\ b. **Controlled:** authenticated access required; **MFA required**; session protections increased.\ c. **Restricted:** authenticated access required; **strong MFA required**; short session lifetimes; re-auth for sensitive actions (downloads, exports, restricted assistant queries, release approvals). 10.2.3 **Institutional SSO patterns (sovereign-ready).** Nexus instances support:\ a. **single institution SSO** (one ministry, one bank group, one university network),\ b. **multi-institution federation** (regional bodies, consortia, cross-sector coalitions),\ c. **mixed mode** (some users SSO, others native) while preserving consistent role and handling policies. 10.2.4 **Purpose binding (ABAC policy posture).** Beyond “who you are,” access must also consider **why**:\ a. purpose declared at access time for Controlled/Restricted (e.g., review, replication, drafting, incident learning),\ b. purpose logged in audit trails and distribution logs,\ c. purpose gates can block high-risk combinations (e.g., competitive intelligence intent in industry-sensitive restricted WGs). 10.2.5 **Credential hygiene and lifecycle.**\ a. password policy (where native accounts exist),\ b. enforced account lockouts and suspicious login alerts,\ c. automated deprovisioning for expired role markers or closed memberships,\ d. re-validation for elevated privileges (reviewer/maintainer) on a periodic clock. *** ### 10.3 Authorization Model: RBAC + ABAC + Handling Gates + Role Markers 10.3.1 **Layered authorization is mandatory.** Nexus must implement:\ a. **RBAC** (role-based access: observer, contributor, reviewer, maintainer, steward, admin),\ b. **ABAC** (attribute-based: handling class, jurisdiction, guild/WG membership, COI status, purpose, timebox),\ c. **role markers** as time-bounded authority tokens (scope + term + revocation path), and\ d. **workflow state** as an access attribute (draft vs under review vs released vs disputed). 10.3.2 **Role separation (separation of duties).** At minimum:\ a. platform administrators cannot unilaterally approve releases,\ b. maintainers cannot bypass handling gates,\ c. stewards can “stop-the-line” but cannot silently edit released content,\ d. reviewers cannot review where COI flagged and not cleared. 10.3.3 **COI-aware authorization (automatic recusal prompts).**\ a. COI declarations are structured data, not PDFs,\ b. access to review lanes triggers a recusal check,\ c. if COI is flagged, the system either blocks review or requires documented mitigation (e.g., second reviewer, steward oversight) logged as a record. 10.3.4 **Handling inheritance rules.**\ a. attachments inherit parent object handling unless explicitly downgraded through a redaction workflow,\ b. derived summaries can be Public-Safe even when source is Controlled/Restricted, but only if passed through staged release requirements,\ c. “mixed bundle” releases enforce the highest handling rules on the bundle index and distribution logs. 10.3.5 **Temporal controls.**\ a. role markers expire automatically,\ b. access to Controlled/Restricted resources can be time-boxed per event,\ c. expiring share links and revocation capabilities apply to controlled distribution. *** ### 10.4 Privileged Access Management (PAM): Admin Control, Break-Glass, and Immutable Trails 10.4.1 **Privileged roles.** Distinguish and separately govern:\ a. **Platform Admin** (infrastructure and configuration),\ b. **Security/Handling Officer** (handling enforcement, breach response),\ c. **Records & Register Steward** (workflow integrity, register truth surfaces),\ d. **Release Steward** (gating, publishing windows),\ e. **Audit/Risk Steward** (review of logs, exception handling).\ These are time-boxed role markers with explicit duties, limits, and recusal rules. 10.4.2 **Break-glass access.** For emergency cases (incident response, outage recovery):\ a. break-glass actions require multi-step confirmation,\ b. generate a signed incident record,\ c. trigger heightened logging and post-incident review,\ d. expire break-glass privileges quickly (hours/days). 10.4.3 **Configuration governance (secure change control).**\ a. configuration changes are versioned,\ b. approval workflow for changes impacting handling gates, indexes, or role policies,\ c. rollbacks are defined and tested,\ d. changes publish internal “platform release notes” to stewards. 10.4.4 **Admin “cannot invisibly change truth.”** Administrators must not be able to:\ a. remove audit logs,\ b. silently edit released objects,\ c. bypass staged release prerequisites,\ d. grant themselves unrestricted access without generating records. *** ### 10.5 Immutable Audit Logging: Evidence-Grade, Handling-Aware, Tenant-Isolated 10.5.1 **Audit logs as evidence artifacts.** Audit logs are not “debugging.” They are:\ a. admissible operational evidence for disputes, security reviews, and incident response,\ b. handling-aware (log content must not leak restricted data into lower handling stores),\ c. tenant-isolated (each sovereign instance has its own logging domain). 10.5.2 **Minimum audit events (must capture).**\ a. authentication (success/fail, device hints, IP/region indicators as permitted),\ b. authorization decisions (why access granted/denied),\ c. content access (object ID, version, handling class, purpose, timestamp),\ d. downloads/exports (what, who, which version),\ e. workflow transitions (submit/triage/review/approve/reject/publish/supersede/withdraw),\ f. assistant interactions (index used, objects referenced, refusal triggers fired),\ g. admin actions (settings, role assignments, key rotation, index rebuilds),\ h. distribution log events (share link created, opened, expired, revoked). 10.5.3 **Audit retention and legal hold.**\ a. retention policies by handling class and jurisdiction,\ b. ability to place legal hold on relevant records and logs,\ c. secure export bundles for sovereign archiving and court/oversight needs,\ d. deletion/destruction attestation workflows when allowed by law. 10.5.4 **Audit log minimization and redaction.**\ a. do not log sensitive payload contents unless required,\ b. log metadata and cryptographic hashes for integrity,\ c. separate restricted logs from public/controlled operational telemetry,\ d. ensure observability does not become a backdoor for data leakage. *** ### 10.6 Handling-Class Data Protection: DLP, Watermarking, Distribution Logs, and Recall 10.6.1 **Distribution logs are mandatory for Controlled/Restricted.** Every controlled/restricted object access must log:\ a. who accessed,\ b. what version,\ c. when,\ d. why (purpose),\ e. from where (coarse location as permitted),\ f. what downstream sharing controls applied (no-forward, expiry, watermark). 10.6.2 **Export and sharing controls (practical within platform).**\ a. controlled download approvals (optional for higher sensitivity),\ b. expiring links for controlled sharing,\ c. watermarking for controlled/restricted PDFs/exports where feasible,\ d. rate limits and anomaly detection for bulk access attempts. 10.6.3 **Recall and revocation.**\ a. revoke share links instantly,\ b. mark an object as withdrawn/superseded and force banners on access,\ c. notify prior access holders for critical corrections,\ d. prevent indexing of withdrawn or disputed restricted materials into lower handling indices. 10.6.4 **Staged release enforcement as a DLP control.**\ a. restricted appendices require public-safe abstract first,\ b. controlled publication requires limitations and reliance bounds,\ c. “unsafe detail detectors” (rule-based triggers) prompt steward review before publication. *** ### 10.7 AI/Assistant Security: Prompt Injection Resistance, Provider Controls, and Logging 10.7.1 **No cross-handling retrieval.** Assistants must retrieve only from the user-authorized handling index:\ a. public index for public users,\ b. controlled index only when user has controlled eligibility,\ c. restricted index only for restricted lane users with role markers. 10.7.2 **Prompt injection safeguards (platform posture).**\ a. treat page content and uploaded documents as untrusted instructions,\ b. enforce system-level guardrails: “never reveal restricted content,” “never produce operational targeting guidance,”\ c. reject attempts to override policies (“ignore previous instructions”),\ d. log injection attempts as security signals. 10.7.3 **Provider routing controls (AI-agnostic without leakage).**\ a. policy routes requests by handling class (e.g., restrict external processing for restricted content),\ b. enforce “no training / no retention” configurations where available,\ c. optional local/sovereign model routing for restricted instances,\ d. model/provider incident response: rapid switch to alternate provider or degrade to non-AI workflows. 10.7.4 **Assistant logs as governance artifacts.**\ a. log retrieval footprints and outputs for auditability,\ b. avoid storing sensitive user uploads beyond retention rules,\ c. allow stewards to review assistant behavior regressions and update refusal patterns. *** ### 10.8 Platform Hardening: WAF, Rate Limits, Bot Mitigation, and Secure Baselines 10.8.1 **Edge protection for public surfaces.**\ a. web application firewall rules tuned to community and publishing workloads,\ b. rate limiting on login, search, and assistant endpoints,\ c. bot mitigation and scraping controls (especially for directories and registers),\ d. protection against enumeration of controlled content (predictable URLs, leaked IDs). 10.8.2 **Secure baseline configuration.**\ a. hardened headers and session cookies,\ b. strict separation between public and controlled content delivery paths,\ c. reduced attack surface by disabling unused features,\ d. controlled admin access via allowlists and MFA. 10.8.3 **Anti-spam and abuse controls.**\ a. throttles on form submissions, comments, group join requests, and message sending,\ b. reputation/credits gating for higher-impact actions,\ c. quarantine lanes for first-time contributors until accepted by a steward or reviewer. *** ### 10.9 Supply Chain Security: Dependency Governance, Patch Clocks, and SBOM Discipline 10.9.1 **Dependency governance.**\ a. maintain an inventory of platform components and versions,\ b. review new components via an intake workflow,\ c. ensure components do not weaken handling segregation or audit logging,\ d. prefer minimal, composable additions that remain replaceable. 10.9.2 **Patch clocks by handling class.**\ a. public-facing vulnerabilities: fastest patch window,\ b. controlled/restricted environment vulnerabilities: immediate triage + accelerated patching,\ c. documented exceptions require steward sign-off and compensating controls. 10.9.3 **Release discipline for platform updates.**\ a. versioned platform releases (not ad-hoc changes),\ b. staging environment validation,\ c. rollback plan,\ d. publish internal change logs to stewards and node operators. *** ### 10.10 Incident Response and Security Operations: Clocks, Roles, and Evidence 10.10.1 **Incident classes (minimum).**\ a. credential compromise,\ b. controlled/restricted leakage,\ c. defacement or integrity compromise,\ d. malicious automation (spam, scraping),\ e. provider incident (AI or infrastructure),\ f. insider misuse of privileges. 10.10.2 **Incident runbooks (must exist).** Each runbook includes:\ a. containment steps (disable roles, revoke links, rotate keys),\ b. evidence capture steps (snapshot logs, preserve records, legal hold),\ c. communication posture (public-safe statements, controlled notices),\ d. correction pathway (withdrawal/supersession where needed),\ e. post-incident review record and lessons learned. 10.10.3 **Stop-the-line authority.** A defined steward role must be able to:\ a. freeze publication,\ b. remove or quarantine unsafe public-safe materials,\ c. mark items disputed/withdrawn,\ d. initiate forced staged-release review for sensitive domains. 10.10.4 **Security metrics.**\ a. mean time to detect (MTTD),\ b. mean time to contain (MTTC),\ c. privileged access review cadence,\ d. rate of blocked injection/leakage attempts,\ e. compliance with patch clocks and restore drills. *** ### 10.11 What This Part Adds 10.11.1 **Security becomes provable, not implied.** Handling-aware RBAC/ABAC, immutable audit trails, distribution logs, and staged release gates create evidence that controls exist and are enforced.\ 10.11.2 **Sovereign deployments stay sovereign.** Tenant-isolated logs, retention controls, local key posture, and provider routing constraints prevent “hidden cross-border leakage” through analytics or AI workflows.\ 10.11.3 **Community scale stays safe.** Self-organization works only if identity, recusal, privilege controls, and anti-abuse defenses are built in—not bolted on. *** ### 10.12 Knowledge Base Outputs 10.12.1 **Nexus Security Architecture Guide** (IAM/SSO/MFA, RBAC+ABAC, role markers, purpose binding).\ 10.12.2 **Handling Enforcement Handbook** (distribution logs, staged release gates, recall/revocation, watermarking posture).\ 10.12.3 **Audit & Evidence Specification** (minimum events, retention, legal hold, tenant isolation, redaction).\ 10.12.4 **Assistant Security Standard** (no cross-handling retrieval, injection defenses, provider routing rules, logging).\ 10.12.5 **Incident Response Playbooks** (classes, runbooks, stop-the-line, post-incident records).\ 10.12.6 **Platform Update and Dependency Discipline** (versioning, patch clocks, rollback, change logs). ## Sources 1. UN General Assembly (2015). Sendai Framework for Disaster Risk Reduction 2015–2030. A/RES/69/283, 3 June 2015. 2. FAO (2014). The Water-Energy-Food Nexus: A new approach in support of food security and sustainable agriculture. Rome: Food and Agriculture Organization of the United Nations. 3. One Health High-Level Expert Panel (OHHLEP), Adisasmito, W. B. et al. (2022). One Health: A new definition for a sustainable and healthy future. PLoS Pathogens 18(6): e1010537. doi:10.1371/journal.ppat.1010537. 4. Nexus Standards. NS-0: Constitution and principles. Status: PROPOSED; UNI `NXS-STD-ST-000004`. 5. Nexus Standards. NS-13: Open standards development process. Status: PROPOSED; UNI `NXS-STD-ST-000008`. 6. GCRI. The Labs pillar home. 7. GCRI. Working groups (NWG). 8. This documentation: [Governance in operation](/organization/governance-in-operation.md); [The Model](/organization/model.md); [historical labels](/organization/reference.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.therisk.global/organization/cooperation/nexus-guilds/platforms/x.-security.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.