Security & Integrity
Relevant source files
The following files were used as context for generating this wiki page:
OCX implements a multi-layered security model designed to ensure the integrity of installed components and the safety of the development environment. The system focuses on preventing supply chain attacks through cryptographic verification and enforcing strict logic boundaries through established engineering philosophies.
The core of OCX security lies in its "Auditable by Default" approach, where every component is version-pinned and verified by SHA-256 hashes before installation or update. This ensures that your AI agents never run code that has not been reviewed and locked by your team. Sources: README.md:46-57, SECURITY.md:3-5
Integrity Verification System
OCX uses a locking mechanism to protect against tampering. When a component is first installed, its content is hashed and stored in a local lockfile (ocx.lock). On subsequent operations, such as updates or reinstalls, OCX re-hashes the incoming content and compares it against the stored value.
Cryptographic Hashing Process
The system utilizes SHA-256 cryptographic hashes to ensure that components have not been silently swapped or modified, even if a registry is compromised. If a hash mismatch is detected, the process terminates with an INTEGRITY_ERROR. Sources: SECURITY.md:5-12, README.md:121-125
The diagram above illustrates the logic flow used by the OCX CLI to verify component integrity during the installation and update lifecycle. Sources: SECURITY.md:7-13, packages/cli/src/commands/update.ts:200-220
Deterministic Bundle Hashing
For components consisting of multiple files, OCX computes a deterministic hash for the entire bundle. Files are sorted by their paths before hashing to ensure that the resulting hash remains consistent regardless of file system ordering. Sources: packages/cli/src/commands/update.ts:365-375
// Sources: packages/cli/src/commands/update.ts:365-375
async function hashBundle(files: { path: string; content: Buffer }[]): Promise<string> {
const sorted = [...files].sort((a, b) => a.path.localeCompare(b.path))
const manifestParts: string[] = []
for (const file of sorted) {
const hash = await hashContent(file.content)
manifestParts.push(`${file.path}:${hash}`)
}
return hashContent(manifestParts.join("\n"))
}
Security Philosophy: The 5 Laws of Elegant Defense
OCX enforces a specific "Elegant Defense" philosophy across its codebase and components to prevent common logic vulnerabilities and maintain a clean security posture. Sources: examples/registry-starter/AGENTS.md:21-25
| Law | Principle | Security Impact |
|---|---|---|
| Early Exit | Use guard clauses at the top of functions. | Prevents deep nesting where logic errors and bypasses are often hidden. |
| Parse, Don't Validate | Use Zod schemas at boundaries to transform data into typed states. | Ensures data is trusted and structured before reaching internal logic; prevents malformed input attacks. |
| Atomic Predictability | Functions should be "Pure" (Same Input = Same Output). | Eliminates hidden state mutations that can lead to race conditions or unauthorized state changes. |
| Fail Fast, Fail Loud | Halt immediately with descriptive errors on invalid states. | Prevents the system from operating in "half-broken" states that could be exploited. |
| Intentional Naming | Names must reveal intent so code reads like a sentence. | Improves auditability and reduces the likelihood of developer error during security reviews. |
Sources: examples/registry-starter/AGENTS.md:27-65, workers/kdco-registry/files/plugin/workspace-plugin.ts:167-175
Code Review & Audit Protocol
OCX provides a systematic methodology for reviewing code and implementation plans through specialized agents and skills. This process is structured into four distinct layers. Sources: workers/kdco-registry/files/skill/code-review/SKILL.md:15-18
The 4 Review Layers
- Correctness: Logic errors, edge cases, and type safety.
- Security: Detection of hardcoded secrets, input validation, injection prevention (SQL, XSS), and authorization checks.
- Performance: Prevention of memory leaks and inefficient query patterns.
- Style & Maintainability: Adherence to project conventions and DRY principles.
Sources: workers/kdco-registry/files/skill/code-review/SKILL.md:20-40
Automated Review Triggers
The WorkspacePlugin includes automated reminders and triggers to ensure security audits are not skipped. For example, a system reminder is injected whenever an implementation plan is saved or a coder task is completed, mandating a review by the reviewer agent. Sources: workers/kdco-registry/files/plugin/workspace-plugin.ts:470-505
This sequence ensures that the transition from implementation to completion always involves an explicit security and correctness audit. Sources: workers/kdco-registry/files/plugin/workspace-plugin.ts:485-508, workers/kdco-registry/files/agent/reviewer.md:15-30
Permission Boundaries
The project implements strict agent sandboxing and permission boundaries to limit the blast radius of any potential compromise within an agent session. Sources: facades/opencode-workspace/README.md:65-68
| Agent | Permissions | Restrictions |
|---|---|---|
| Researcher | Read-only external access (Docs, Web, API) | FORBIDDEN: Write files, modify filesystem, or search codebase. |
| Coder | Full file and bash access for implementation | FORBIDDEN: Commit code or perform git push/force operations. |
| Scribe | File write access for documentation | FORBIDDEN: Execute bash commands or run code. |
| Reviewer | Read-only access to files and git history | FORBIDDEN: Modify files or execute arbitrary bash commands. |
Sources: workers/kdco-registry/files/agent/researcher.md:85-95, workers/kdco-registry/files/agent/coder.md:80-90, workers/kdco-registry/files/agent/scribe.md:65-70, facades/opencode-workspace/README.md:69-80
Vulnerability Disclosure
OCX maintains a formal security policy for reporting vulnerabilities. The project scope for security includes the CLI tool, the integrity verification mechanism, and registry resolution logic. Vulnerabilities in third-party extensions are explicitly considered out of scope and should be reported to their respective maintainers. Sources: SECURITY.md:16-36
Reporting Contact
Security concerns should be reported to: ocx-security@alias.kdco.llc. The team commits to an initial acknowledgement within 48 hours and a resolution within 90 days. Sources: SECURITY.md:18-24
Summary
Security in OCX is a combination of cryptographic enforcement and procedural rigor. By utilizing SHA-256 lockfiles, deterministic bundle hashing, and specialized reviewer agents with strict permission boundaries, OCX provides a transparent and auditable environment for managing OpenCode components. These systems ensure that every change is verified against both its original source and a structured set of security principles.