Security & Safety Boundaries
Relevant source files
The following files were used as context for generating this wiki page:
Security and safety boundaries in Delano define the operational limits and protective measures for agents and operators interacting with the delivery runtime. These boundaries ensure that project state remains traceable, privacy is maintained, and destructive actions are prevented unless explicitly authorized.
The system relies on a combination of file-backed contracts, restricted runtime environments, and validation gates to maintain the integrity of the .project/ and .agents/ directories. This posture prioritizes local, read-only inspection through the Delano viewer while enforcing strict rules on data logging and remote synchronization.
Sources: README.md:12-16, AGENTS.md:36-41
Operational Safety Principles
Delano enforces specific completion rules and safety constraints to prevent accidental data loss or unauthorized mutations. Agents are prohibited from taking destructive actions such as force-pushing or rewriting shared history without explicit task instructions.
Core Security Constraints
- Destructive Action Prohibition: No force-pushes or history rewrites unless explicitly tasked.
- Local Path Secrecy: Absolute local paths must not be leaked in documentation, contracts, or hook outputs.
- Privacy-Safe Logging: Prompt and tool logs are restricted to ensure they do not leak sensitive information.
- Explicit Approval: The
onboardingskill requires explicit approval before analyzing the environment.
Sources: AGENTS.md:36-41, README.md:179-181, README.md:358-360
The diagram shows the decision logic for agent actions, emphasizing the requirement for explicit authorization and path/privacy validation.
Sources: AGENTS.md:36-41, test/package.test.js:159-170
Data Privacy and Logging
Privacy is maintained through strict logging defaults and text safety checks. Committed logs must pass the .agents/scripts/check-log-safety.sh validation. Raw prompts are treated as opt-in only features.
Security Validation Components
| Component | Responsibility | Source File |
|---|---|---|
check-log-safety.sh | Ensures committed logs do not contain raw sensitive prompts. | AGENTS.md:38 |
check-text-safety.mjs | Rejects bidirectional (Bidi) control characters to prevent spoofing. | test/package.test.js:159 |
check-delivery-metrics.mjs | Verifies that metrics events remain metadata-only and privacy-safe. | test/package.test.js:296 |
log-safety.js | Common logic for scrubbing sensitive output from runtime logs. | assets/install-manifest.json:13 |
Bidirectional control character rejection is a critical security gate. For example, U+202E (RIGHT-TO-LEFT OVERRIDE) is explicitly flagged and rejected during safety checks to prevent text manipulation in contracts.
Sources: test/package.test.js:159-170, assets/install-manifest.json:13
Runtime & Installation Gating
The installation process is "conflict-first," meaning it computes a full plan and aborts if approved target paths already exist. This prevents accidental overwrites of repository-owned state.
Install Behavior
- Abort on Conflict: The installer stops if it detects pre-existing files in the allowlist paths.
- Allowlist Only: It does not touch files outside the predefined
assets/install-manifest.json. - State Protection: By default, it avoids overwriting
.project/context,.project/projects, and.project/registryunless forced. - Git Config Isolation: Top-level Git configuration files (
.gitignore,.gitattributes) are never installed or overwritten by the CLI.
Sources: README.md:204-213, test/package.test.js:20-25
The sequence illustrates the conflict-first installation logic that protects existing repository state.
Sources: README.md:204-210, assets/install-manifest.json:1-10
Coordination and Lease Boundaries
In multi-agent environments, Delano uses lease-based coordination to prevent race conditions and conflicting writes to project artifacts.
Lease Lifecycle
Lease contracts define lifecycle fields that govern how agents claim specific "zones" (files or logic areas). A lease release requires a handoff summary, ensuring that no agent leaves a task in an indeterminate state.
Sources: test/package.test.js:255-275, README.md:126-130
| Security Feature | Description | File Path |
|---|---|---|
| Exclusive Mode | Blocks overlapping exclusive zones from being claimed by multiple agents. | test/package.test.js:275 |
| Handoff Requirement | Forces agents to provide evidence/summary before releasing a file lease. | test/package.test.js:266 |
| Zone Isolation | Restricts lease claims to specific relative paths or scripts. | test/package.test.js:259 |
Summary of Boundaries
The Delano security model is founded on local transparency and restrictive automation. The primary boundary is the distinction between the Shared Runtime (.agents/), which is provided by the package, and the Delivery State (.project/), which is owned by the repository. By enforcing validation gates like check-log-safety.sh and text safety audits, the system ensures that the file-backed contracts remain a reliable, tamper-evident source of truth for both humans and machines.
Sources: README.md:16-20, AGENTS.md:36-41, PRODUCT.md:26-31