Guide: Security and Access Control

Relevant source files

The following files were used as context for generating this wiki page:

• README.md
• IMPLEMENTATION_PLAN.md
• Cargo.toml
• CODE_OF_CONDUCT.md
• crates/sentinel/Cargo.toml
• rustfmt.toml
• crates/sentinel/src/lib.rs

Cyberpath Sentinel is designed with a "Security First" principle, prioritizing trust, transparency, and compliance. Unlike traditional databases that manage security internally, Sentinel leverages the underlying operating system's filesystem and its inherent security features. This approach treats the filesystem as the database, making every piece of data inspectable, auditable, and compliant by design. The security model is built on a foundation of OS-level permissions, cryptographic verification, and immutable audit trails.

This guide provides a comprehensive overview of the security and access control mechanisms within Sentinel. It covers the core architectural principles, data integrity measures, encryption strategies, and the compliance-ready features that are central to the project's vision. For more details on the overall architecture, see the Implementation Plan.

Sources: README.md:5-10, 102-104, IMPLEMENTATION_PLAN.md:15-21

Core Security Principles

Sentinel's security architecture is guided by several key principles that differentiate it from conventional database systems.

Principle	Description	Source
Filesystem is the Database	Leverages the reliability, maturity, and tooling of modern filesystems (ext4, NTFS, APFS). Security is managed via standard OS tools and permissions.	README.md:102-103
Immutability by Default	Operations are designed to be non-destructive. Deletions are soft (moving files), and updates can be versioned, creating a natural audit trail.	README.md:104
Security First	The architecture integrates file permissions, encryption, and cryptographic verification as fundamental components, not afterthoughts.	README.md:105
UNIX Philosophy	Sentinel aims to do one thing well (auditable storage) and composes with standard tools like grep, rsync, and git for operations.	README.md:106

Sources: README.md:102-107

Access Control

Access control in Sentinel is intentionally simplified by delegating it to the operating system. There is no internal database user management system.

Filesystem ACLs

Access to collections (folders) and documents (files) is controlled directly by OS-level Access Control Lists (ACLs) and standard file permissions (e.g., chmod, chown). This approach eliminates a common layer of complexity and potential misconfiguration found in traditional DBMSs.

• Granularity: Permissions can be set per-store, per-collection, or even per-document.
• Management: Administrators use standard OS tools to manage user and group access.
• Use Cases: Ideal for managing access to sensitive data like encryption keys, audit logs, and compliance policies.

This diagram shows how a user request is mediated by the OS before reaching Sentinel's file I/O layer.

Planned Role-Based Access Control (RBAC)

Phase 4 of the implementation plan includes the introduction of a Role-Based Access Control (RBAC) system. This will likely supplement, not replace, the OS-level controls, providing finer-grained permissions within the application logic, especially for managing access to encryption keys.

Sources: IMPLEMENTATION_PLAN.md:316

Data Integrity and Auditability

A primary goal of Sentinel is to ensure data is inspectable, auditable, and verifiably intact. This is achieved through a combination of hashing, digital signatures, and immutable logging.

Checksums and Digital Signatures

Every document is planned to contain metadata for integrity verification.

• _hash: A SHA-256 hash of the document's content to detect accidental corruption.
• _sig: An RSA-2048 digital signature to verify the author and detect tampering.

The following diagram illustrates the process of writing and then verifying a document.

Immutable Audit Logs & Soft Deletes

Sentinel is designed for perfect auditability.

• Soft Deletes: When a document is deleted, it is not removed from the disk. Instead, it is moved to a .deleted/ sub-folder within its collection. This preserves the data for forensic analysis and makes deletion a recoverable, audited event.
• Audit Trails: All operations (Create, Update, Delete, etc.) are intended to be logged as AuditEvents in a dedicated, append-only collection. This creates an immutable history of all activities, which is critical for compliance.
• Git Integration: The entire data store can be a Git repository, providing a transparent, versioned history of every change, including who made it and when.

The soft delete process is visualized below:

Data Encryption

Encryption is a core, though optional, feature designed to protect sensitive data at rest. The implementation plan outlines a sophisticated EncryptionManager.

Encryption Manager

The EncryptionManager is the central component responsible for all cryptographic operations. It is planned for Phase 4 of development.

This diagram shows the planned structure of the EncryptionManager.

Sources: IMPLEMENTATION_PLAN.md:200-216

Key components of the encryption strategy include:

Component	Description	Planned Implementation
Algorithms	Strong, authenticated encryption algorithms.	AES-256-GCM or ChaCha20-Poly1305.
Master Key	A primary key used for deriving other keys.	Managed by the EncryptionManager.
Key Derivation	A Key Derivation Function (KDF) to create keys.	Argon2 is planned.
Per-Document Keys	Each document may be encrypted with a unique key, enhancing security.	Planned for Phase 4.
Key Rotation	The ability to rotate keys to mitigate risk from key compromise.	Planned for Phase 4.

The dependencies for these features are listed in the workspace Cargo.toml.

Sources: README.md:115, IMPLEMENTATION_PLAN.md:200-224, 300-306, Cargo.toml:104-107

Secure Development and Project Security

The project enforces a strict set of linter rules via clippy to promote secure coding practices. The release profile is also configured for security and performance.

• Panic Behavior: Panics are configured to abort, which prevents stack unwinding and can mitigate certain classes of exploits.
• Overflow Checks: Integer overflow checks are disabled in release builds for performance, requiring developers to handle arithmetic carefully. Numerous clippy lints are enabled to catch potential arithmetic side effects.
• Denied Operations: The linter configuration explicitly denies potentially unsafe operations like mem_forget, panic, todo, and unimplemented.

For reporting security issues related to the Sentinel project itself, the CODE_OF_CONDUCT.md directs individuals to contact support@cyberpath-hq.com.

Sources: Cargo.toml:13-20, 24-400, CODE_OF_CONDUCT.md:49-50

Compliance Readiness

The security features of Sentinel are designed to directly support various regulatory and compliance standards.

Standard	Relevant Sentinel Feature(s)
GDPR	The "right-to-delete" is a simple rm command, with the action recorded in the audit trail.
SOC 2	Intrinsic, immutable audit trails for change management and access logging.
HIPAA	Encryption at rest (AES-256/ChaCha20) and strict access controls via filesystem ACLs.
PCI-DSS	File-level access controls and auditable logs for handling sensitive data.
ISO 27001	A comprehensive set of security controls built directly into the architecture.

Sources: README.md:34-36, 119-123, IMPLEMENTATION_PLAN.md:249-257

Conclusion

Cyberpath Sentinel's approach to security and access control is fundamentally different from traditional databases. By building on the robust and well-understood security model of the filesystem, it offers unparalleled transparency and auditability. Features like OS-level ACLs, cryptographic integrity checks, optional strong encryption, and immutable logs are not add-ons but are woven into the core design. This makes Sentinel a powerful choice for applications where trust, compliance, and verifiable data history are more critical than raw transaction speed.