Security
ByteOr's security posture is built on OS-level isolation, cryptographic approval verification, and scoped credential management.
SHM Threat Model
ByteOr's shared-memory path is designed for high-throughput local IPC, not as a trust boundary by itself.
Trust Model
- Shared-memory files and headers are untrusted input until validated
- ByteOr relies on normal OS file permissions and process isolation
- The intended baseline is cooperating processes on the same host with least-privilege filesystem access
- ByteOr does not create a security boundary stronger than the host/user model already provides
Defenses
- Header magic and version validation on region open
- Bounds checking on all lane operations
- No assumption that SHM contents are well-formed
- Capacity and entry size validated before use
What ByteOr Does Not Defend Against
- A malicious process with write access to the SHM file can corrupt data
- ByteOr guards against accidental corruption and stale data, not adversarial writers with host-level access
- If your threat model requires isolation between SHM participants, you need OS-level or VM-level isolation
Cloud Auth Model
- OIDC-based authentication for the Cloud UI and API
- Organization, project, and environment scoping
- Per-agent runtime API keys with explicit scope sets
- Enrollment tokens are single-use and environment-scoped
Approval Verification
- Cryptographic signing and verification for approval credentials
- Spec hash binding prevents approval reuse across versions
- Environment scoping prevents approval reuse across environments
- Time-limited credentials with explicit expiry
- Capability matching ensures approvals cover the required action
Abuse Controls
- Route-level rate limiting for auth, agent, and artifact traffic
429responses with backoff guidance- Content-hash deduplication for artifact uploads
- Size validation on uploads
Disclosure
If you find a security issue, report it through the responsible disclosure process described in the repository SECURITY.md files.