> 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/standardization/nexus-sovereignty/ix.-security-privacy-and-resilience/access-controls.md).

# Access Controls

## Fine-Grained Access Control in the Nexus Sovereignty Framework: Role-Scoped Authority, Jurisdictional Firewalls, Credential Intersection, Node Isolation, Emergency Lockdown, and Defense-in-Depth Governance

### Why Fine-Grained Access Control Is Foundational

The Nexus Sovereignty Framework operates across many control surfaces: Smart Clauses, simulation engines, credential registries, event buses, digital twin adapters, AI agent runtimes, edge nodes, offline kits, private-chain anchors, public registries, Project Evidence rooms, finance-readiness evidence workflows, insurance-readiness evidence workflows, governance dashboards, and DAO-compatible coordination systems. Each of these surfaces can affect how evidence is interpreted, how clauses are validated, how credentials are issued, how public-safe outputs are generated, how simulations are trusted, and how institutional decisions are routed.

Access control in this environment cannot be coarse. A user cannot simply be “admin.” A node cannot simply be “trusted.” A credential cannot simply be “valid.” A governance body cannot simply be “authorized.” Each permission must be scoped by role, jurisdiction, clause family, risk domain, credential status, time window, simulation context, governance authority class, public-safe classification, and audit obligations.

This is essential because compromise of any control surface can create systemic consequences. A malicious actor may attempt to override a clause, manipulate a simulation, issue unauthorized credentials, hijack a governance proposal, spoof a node interface, alter Project Evidence records, misrepresent finance-readiness evidence, overstate insurance-readiness evidence, bypass public-safe review, or create policy misalignment across jurisdictions. A compromised credential issuer may grant roles to unauthorized actors. A compromised simulation runner may generate false forecasts. A captured governance interface may present a malicious proposal as legitimate. A rogue AI agent may attempt to use tools outside its scope. A field node may reconnect with stale or manipulated state.

Fine-grained access control is therefore a zero-trust requirement. NSF must verify not only who is requesting access, but what role they hold, what they are trying to do, where they are doing it, which clause or simulation they are touching, which registry state applies, whether their credential is active, whether the action is public-safe, whether the jurisdiction permits the action, whether the request is fresh, and whether the result will be auditable.

The core doctrine is:

**In NSF, access is not granted to identities in general. Access is granted to verified roles for specific actions, under specific scopes, against specific protocol objects, within specific jurisdictions, during specific time windows, subject to credential status, simulation context, public-safe constraints, and audit logging.**

### Access Control Is Governance, Not Merely Security

Access control in Nexus is not only an information-security mechanism. It is a governance mechanism. It determines who can propose clause changes, who can validate simulations, who can issue credentials, who can view protected evidence, who can publish public-safe summaries, who can run AI agents, who can operate edge nodes, who can update Project Evidence, who can access finance-readiness evidence, who can access insurance-readiness evidence, and who can participate in governance decisions.

This means access control must be institutionally legible. Permissions should not be hidden in opaque administrator settings. They should be declared in credential schemas, role policies, node policies, clause metadata, registry entries, governance records, and CAC outputs. A reviewer should be able to determine why access was granted or denied. A governance body should be able to revoke or restrict a role. An auditor should be able to reconstruct the credential state at the time of execution. A public-safe reviewer should be able to determine whether an output was produced by an authorized actor. A Project Evidence room should be able to verify that a user accessed only evidence within their scope.

Fine-grained access control creates security because it creates institutional accountability.

### NSF Access Control Model Overview

NSF implements a layered access control model.

The **Identity Layer** verifies that an actor, node, device, institution, AI agent, or runtime has a valid decentralized identifier or equivalent identity anchor.

The **Credential Layer** verifies that the actor holds a valid role credential, that the credential is active, unrevoked, issuer-recognized, scope-bound, and valid for the requested action.

The **Policy Layer** evaluates whether the requested action is permitted under role policy, clause metadata, jurisdictional rules, simulation classification, public-safe policy, node policy, and governance state.

The **Context Layer** evaluates situational constraints: time, location, jurisdiction, SDZ, event state, simulation state, model status, clause lifecycle, emergency condition, public-safe status, and offline reconciliation status.

The **Runtime Layer** enforces the decision through CAC runtimes, Event Bus gateways, node APIs, Credential Oracles, simulation runners, registry resolvers, AI agent tool gates, edge runtimes, and evidence-room access controls.

The **Audit Layer** records access decisions, proof inputs, credential checks, policy evaluations, runtime actions, denial reasons, overrides, and correction paths.

This model ensures that every access decision is attributable, bounded, reproducible where feasible, and reviewable.

An access decision record may look like:

```json
{
  "type": "NSFAccessDecision",
  "request_id": "access-0x71ac",
  "actor": "did:nsf:person:0x91",
  "presented_role": "FloodSimulationReviewerVC",
  "requested_action": "review-simulation-output",
  "target_object": "FloodRiskEvidence@3.1",
  "jurisdiction_scope": ["KEN"],
  "credential_status": "active",
  "policy_result": "allow",
  "conditions": [
    "public-safe-output-not-authorized",
    "review-note-required",
    "audit-log-required"
  ],
  "non_meaning": [
    "not-public-authority",
    "not-finance-approval",
    "not-insurance-underwriting"
  ],
  "audit_record": "audit-0x88bc"
}
```

Access control decisions should be cryptographically enforced where material, but they must also be human-readable enough for governance review.

### DID-Based Node Access Control

NSF nodes use decentralized identifiers or equivalent verifiable identity anchors to authenticate node operators, administrators, monitors, simulation runners, credential issuers, registry writers, AI agents, and evidence-room systems. Node access is never granted merely because a request comes from a known network address or familiar interface. Every node-level action must be tied to a credentialed actor, device, runtime, or governance function.

DID-based node access control governs who can deploy a node, update node software, monitor node status, install clause bundles, run simulations, publish registry updates, write credential status roots, operate event gateways, access Project Evidence rooms, manage public-safe outputs, or rotate node keys. Node operators should hold role-limited credentials. Deployment authority should be separate from monitoring authority. Credential issuer authority should be separate from simulation runner authority. Public-safe publication authority should be separate from internal evidence access.

Every node access request should evaluate issuer trust graph, credential scope, node policy, jurisdictional context, signed nonce, freshness, device or runtime attestation where required, credential intersection, and audit obligations. High-risk node actions should require multisignature approval, hardware-backed signing, TEE attestation, governance approval, or delayed activation.

A node update request may be denied even if the requester is known, if their credential does not authorize that node, that jurisdiction, that software package, that clause bundle, or that time window.

### Domain-Scoped Role Enforcement

Roles in NSF must be domain-scoped. A credential valid for one domain should not silently authorize action in another. A flood-risk simulation reviewer is not automatically a public health reviewer. A Project Evidence reviewer is not automatically a finance-readiness reviewer. A finance-readiness evidence reviewer is not an investment adviser. An insurance-readiness evidence reviewer is not an underwriter. A public-safe reviewer is not a public authority. A community steward is not automatically authorized outside the community-governed scope.

Role scopes should include clause domains, such as `climate.risk.flood`, `health.capacity`, `food.security`, `infrastructure.grid`, `ai.agent.tooluse`, or `project.evidence.monitoring`. They should include jurisdictional boundaries, such as national, regional, municipal, SDZ, community, corridor, asset, or project scope. They should include simulation template classes, credential schema tags, lifecycle state, time window, public-safe classification, and permitted action type.

Domain-scoped enforcement prevents three major risks. First, it prevents actors from executing or reviewing clauses beyond their expertise or mandate. Second, it prevents cross-jurisdictional misuse, where a credential valid in one country is used in another without recognition. Third, it prevents replay of a previously valid credential in a new governance context where it does not apply.

A credential valid for `WaterEvidenceReview@KEN` should not authorize `FinanceReadinessEvidenceReview@RegionalPortfolio` unless a separate credential, explicit recognition, or governance approval exists.

### DAO-Compatible Access Isolation

DAO-compatible governance systems require strict access isolation. NSF should support DAO tooling where useful, but authority must remain role-bound, credential-scoped, jurisdiction-aware, and audit-linked. A DAO interface should not become an unrestricted control panel for protocol governance.

DAO-compatible systems should use VC-based membership proofs, role-verified quorum, tiered permissions, time-limited delegation, multisig policies, conflict-of-interest controls, proposal validation, simulation gates, public-safe gates, and credential status checks. A member may have voting rights for one domain but not another. A Health Evidence Governance function may vote on outbreak simulation templates, while a Climate Evidence Governance function may vote on flood or drought templates. A Project Evidence governance group may review evidence schema changes, but not approve finance or insurance. A public-safe body may block publication, but not rewrite underlying evidence without proper process.

DAO interfaces themselves must be authenticated and attested. Interface spoofing is a real threat: a malicious dashboard could present false proposal content, hide dissent, change vote wording, suppress non-meaning boundaries, or trick users into signing unsafe actions. NSF should require signed proposal payloads, interface integrity checks, content-hash previews, hardware-wallet or secure signer confirmation, and audit linkage.

Private DAO participation may use ZK eligibility proofs and encrypted ballots. But privacy does not remove scope. A private vote must still satisfy role, quorum, jurisdiction, and conflict rules.

### Simulation Access Gatekeeping

Simulations in NSF are not generic compute jobs. They may use sensitive inputs, influence clause validation, generate governance proposals, update Project Evidence, affect public-safe outputs, or support finance-readiness and insurance-readiness evidence. Access to simulation systems must therefore be tightly controlled.

Simulation access should be classified by sensitivity and policy class. Low-risk public simulations may be open or broadly accessible. Restricted simulations may require credentialed researchers or reviewers. Sovereign simulations may require national node authorization. Health, humanitarian, migration, community, infrastructure, or Project Evidence simulations may require controlled access and privacy-preserving proofs. High-consequence simulations may require TEE-verified runners, approved model hashes, recognized templates, input provenance checks, runtime attestation, and governance review before outputs are relied upon.

Authorized users may include TEE-verified runners, credentialed researchers, recognized simulation validators, national or regional simulation officers, public-safe reviewers, community stewards, controlled evidence-room reviewers, and clause-bound AI agents with prior approval. Each access class should define whether the actor may view raw inputs, run models, alter parameters, approve outputs, publish summaries, attach review notes, or route results to governance.

A simulation access profile may include:

```json
{
  "simulation_class": "RestrictedHumanitarianEvidenceSimulation",
  "allowed_roles": [
    "HumanitarianEvidenceReviewerVC",
    "SimulationValidatorVC",
    "PublicSafeReviewerVC"
  ],
  "prohibited_actions": [
    "public-output-without-review",
    "identity-data-export",
    "finance-approval",
    "insurance-underwriting"
  ],
  "runtime_requirements": [
    "TEE-attestation",
    "input-commitment",
    "audit-log"
  ],
  "public_safe_required": true
}
```

Simulation access gatekeeping prevents sensitive models from becoming ungoverned sources of authority.

### Credential Issuer Controls

Credential issuance is one of the highest-risk control surfaces in NSF. If an attacker can issue credentials, they can potentially influence clause execution, governance votes, simulation validation, registry updates, AI agent permissions, public-safe outputs, Project Evidence review, finance-readiness evidence review, or insurance-readiness evidence review. Credential issuer controls must therefore be strict.

Credential issuance should be allowed only when the issuer DID is valid, the issuer is recognized for the credential type, the credential schema is active in the registry, the issuance workflow matches approved policy, required evidence or governance approval exists, revocation infrastructure is initialized, signing keys are valid, and the issuance event is audit-linked.

Credential signing keys should use HSMs, hardware-backed keys, secure enclaves, air-gapped signing, multisig issuance, or equivalent safeguards depending on risk. Post-quantum-ready signature profiles should be supported where required. Key rotation, emergency suspension, issuer revocation, credential regeneration, and status root anchoring should be part of the lifecycle.

An issuer should not be able to issue all credential types. A simulation governance registry may issue SimulationReviewerVCs. It should not issue finance-readiness review credentials unless separately authorized. A Project Evidence registry may issue ProjectEvidenceReviewerVCs. It should not issue public authority credentials. A community steward body may issue community review credentials for its scope. It should not issue credentials for other communities.

Issuer authority must be as scoped as user authority.

### Cross-Domain Role Intersection Controls

Many actors may hold multiple credentials. This is normal in complex governance systems, but it creates risk. A person or institution may hold climate, finance-readiness, project evidence, public-safe, and governance credentials. Without intersection controls, credential aggregation could allow the actor to combine roles in ways that were never intended.

NSF should evaluate compound actions through role intersection, not role accumulation. If a requested action touches climate simulation and Project Evidence, the actor must have authority in the intersection of those scopes. If it touches finance-readiness evidence, the actor must have a finance-readiness evidence role, and the output must still preserve non-approval boundaries. If it touches public-safe publication, public-safe review must be satisfied. If it touches multiple jurisdictions, cross-jurisdictional recognition must be present.

A cross-domain request may trigger additional simulation validation, governance review, conflict-of-interest checks, or alerts. For example, a FinanceReadinessEvidenceReviewerVC should not allow an actor to trigger a HealthCapacityClause unless the actor also holds the required health evidence role and the action is permitted by the clause. A ProjectEvidenceReviewerVC and InvestorObserverVC combination may require conflict screening before evidence review.

Cross-domain intersection prevents credential stacking from becoming hidden privilege escalation.

### AI Agent Access Control

AI agents require explicit access control because they can read evidence, summarize records, call tools, draft proposals, invoke simulations, interact with Event Bus topics, generate public-safe text, and influence institutional attention. An AI agent must never receive broad ambient authority.

An agent should operate under an AgentCredential that defines model identity, operator, tool scope, data access scope, memory policy, public-safe policy, jurisdictional scope, output class, logging requirements, and human review requirements. Tool access should be granted per tool, not per system. A simulation-assist agent should not access credential issuance tools. A public-safe drafting agent should not access raw protected evidence unless specifically authorized. A Project Evidence assistant should not generate finance approval language. A finance-readiness evidence assistant should not provide investment advice. An insurance-readiness evidence assistant should not underwrite, price, or determine claims.

Agent access decisions should be logged. High-risk tool calls should require CAC-like proof, human approval, or governance-defined thresholds. If an agent attempts to exceed scope, the tool call should be blocked and audit-recorded.

AI agents are executable actors. They require the same zero-trust access discipline as human and institutional actors.

### Emergency Lockdown and Role-Freezing Protocols

NSF must support emergency lockdowns when compromise, misalignment, data poisoning, governance capture, bridge failure, credential issuer compromise, model quarantine, node intrusion, public-safe violation, or systemic shock is detected. Lockdown should be precise. It should freeze only the affected roles, nodes, event classes, clauses, simulations, credentials, interfaces, or registries where possible, rather than shutting down the entire ecosystem.

A national node may freeze a role type within its jurisdiction. A regional governance function may restrict a cross-border event class. A Credential Governance function may suspend an issuer. A Simulation Governance function may quarantine a model. A Public-Safe Governance function may block publication of a class of outputs. A Project Evidence room may restrict evidence access after a data leak. An AI agent governance function may revoke tool access.

Emergency lockdown should be versioned, time-bound, justified, audit-linked, reviewable, and appealable where appropriate. It should include scope, trigger, authority, duration, affected objects, fallback state, public-safe implications, and reconciliation path.

A lockdown record may look like:

```json
{
  "type": "AccessLockdownRecord",
  "lockdown_id": "lockdown-0x72bc",
  "trigger": "credential-issuer-compromise",
  "affected_roles": [
    "FloodSensorInputProviderVC"
  ],
  "jurisdiction_scope": ["MOZ"],
  "effect": "freeze-new-events-and-route-existing-events-to-review",
  "authorized_by": "CredentialGovernanceFunction",
  "valid_until": "2025-08-15T00:00:00Z",
  "review_required": true,
  "audit_record": "audit-0x551",
  "non_meaning": [
    "not-misconduct-finding",
    "not-public-authority-order"
  ]
}
```

Lockdown is a safety mechanism, not a punishment by default.

### Jurisdictional Firewalls and Sovereign Autonomy

Fine-grained access control must support jurisdictional firewalls. A role valid in one national node should not automatically operate in another. A simulation template approved by one jurisdiction may be advisory in another. A credential issuer recognized in one regional consortium may not be recognized globally. A Project Evidence record may be visible in a controlled evidence room but not in a public registry. A community-controlled dataset may remain inaccessible outside local rules.

Jurisdictional firewalls enforce sovereignty, privacy, community control, and legal boundaries. They also support disaster containment. If one node is compromised, access controls should prevent the compromise from spreading across all domains. If one credential issuer fails, dependent credentials can be restricted without invalidating unrelated systems. If one event topic is poisoned, only affected clause families should freeze.

Sovereign autonomy in Nexus is not achieved by isolation alone. It is achieved through scoped interoperability.

### Access Control for Edge and Offline Deployments

Edge and offline environments require special access control. They may operate with cached credential status roots, local policy bundles, pre-approved clause packages, offline signatures, temporary field credentials, and delayed reconciliation. The risk is that stale credentials, old clause versions, compromised devices, or replayed signatures could be used while disconnected.

Offline access control should include expiry windows, nonce policies, local revocation lists, device attestation where available, signed policy bundles, restricted offline authority, proof bundles, and reconciliation requirements. Offline-issued credentials should be temporary, local-scope, and marked pending synchronization unless otherwise authorized. Edge nodes should not execute high-consequence workflows beyond pre-approved local scope.

When connectivity returns, access decisions should be reconciled against current registry state. If a credential was revoked during disconnection, affected records should be marked under review, not erased. If a clause version changed, local executions should be interpreted under cached-state rules and flagged where necessary.

Offline access control preserves continuity without allowing disconnected authority drift.

### Access Control for Project SPVs, Finance-Readiness, and Insurance-Readiness

Project SPV evidence workflows require access controls across sponsors, operators, contractors, monitors, community stewards, technical reviewers, public-safe reviewers, investors, insurers, lenders, government observers, and auditors. Each actor may need different access to raw data, summaries, proof bundles, public-safe outputs, finance-readiness evidence, or insurance-readiness evidence.

A contractor may upload monitoring evidence but not alter public-safe summaries. A community steward may review local disclosure but not approve finance-readiness evidence. A finance-readiness evidence reviewer may review evidence completeness but not approve financing or provide investment advice. An insurance-readiness evidence reviewer may review exposure evidence but not underwrite, price, bind coverage, or determine claims. A public dashboard may show only public-safe summaries, not raw asset telemetry.

Access controls should enforce these boundaries technically, not merely through policy statements. Evidence rooms should use credential-gated access, selective disclosure, ZK proofs, audit logging, role separation, and public-safe filters.

Project evidence becomes trustworthy when access is controlled as carefully as claims are written.

### Auditability of Access Decisions

Every material access decision should be auditable. This includes allowed requests, denied requests, failed credential checks, scope violations, emergency overrides, role freezes, public-safe blocks, node administration actions, simulation access, credential issuance, AI tool calls, Project Evidence access, finance-readiness evidence access, and insurance-readiness evidence access.

Audit records should include actor commitment or identity where appropriate, role proof, credential status, requested action, target object, policy evaluated, decision result, reason codes, timestamp, registry snapshot, jurisdiction, runtime, and reviewer or override references. Sensitive identity may remain protected through role proofs, encrypted audit envelopes, or selective disclosure, but the decision itself should remain traceable.

Access audit is what makes zero trust operational. Without it, enforcement cannot be reviewed, corrected, or trusted.

### Boundary Statement for Fine-Grained Access Control

Fine-Grained Access Control supports role-scoped authority, DID-based node access, credential verification, domain-scoped permissions, DAO-compatible access isolation, simulation gatekeeping, credential issuer controls, cross-domain role intersection, AI agent tool control, emergency lockdown, jurisdictional firewalls, edge and offline access continuity, Project SPV evidence workflows, finance-readiness evidence workflows, insurance-readiness evidence workflows, public-safe review, and audit-ready governance.

It does not by itself create legal authority, public authority status, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, professional licensing, sovereign consent, community consent, legal compliance determination, ESG rating, SDG certification, institutional endorsement, data truth, model correctness, prediction certainty, treasury authority, custody authority, operational command, or guaranteed security. An access control decision proves only that a declared request was evaluated under declared identity, credential, policy, context, and registry conditions. Its institutional meaning depends on source authority, governance review, credential status, jurisdiction, applicable law, contracts, community rules, licensed actors, and competent adoption.

Access granted is not institutional approval.

Credential scope is not unlimited authority.

A node role is not public authority.

A DAO permission is not valid outside its mandate.

A simulation access grant is not model endorsement.

A finance-readiness access grant is not finance approval.

An insurance-readiness access grant is not underwriting.

A Project Evidence access grant is not procurement approval.

An emergency lockdown is not a legal finding by itself.

This boundary should appear in access policies, credential schemas, node configuration records, DAO-compatible interfaces, simulation access profiles, Credential Oracle outputs, AI agent policies, Project Evidence records, finance-readiness evidence records, insurance-readiness evidence records, public-safe outputs, dashboards, and audit reports.

### A Defense-in-Depth Model for Global-Scale Governance

Fine-grained access control is one of the main ways NSF turns zero trust into daily operational discipline. It prevents identities from becoming unchecked power. It prevents credentials from leaking across domains. It prevents nodes from trusting interfaces blindly. It prevents DAOs from becoming unrestricted control planes. It prevents simulations from becoming open manipulation surfaces. It prevents AI agents from acting beyond tool scope. It prevents Project Evidence rooms from exposing sensitive data. It prevents finance-readiness and insurance-readiness evidence from being misused as approval. It prevents emergency measures from becoming invisible authority.

Access is never assumed.

Execution is never silent.

Permissions are scoped.

Credentials are checked.

Jurisdictions are respected.

Simulations are gated.

Roles expire.

Keys rotate.

Interfaces attest.

Overrides are logged.

Failures freeze safely.

The purpose of Fine-Grained Access Control in the Nexus Sovereignty Framework is to ensure that every pathway from proposal to clause, from clause to simulation, from simulation to credential, from credential to node, from node to audit, and from audit to correction remains bounded by verifiable authority. Control is composable, cryptographic, jurisdiction-aware, simulation-aware, public-safe, and reviewable. This is how Nexus maintains institutional resilience under stress while enabling global-scale governance without blind trust.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/ix.-security-privacy-and-resilience/access-controls.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.