Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Security

GitHub’s security tab reads the repository-root SECURITY.md. This chapter is that file, included verbatim rather than summarised, so book readers get the whole policy — reporting channel, supported versions, in-scope crates, and the Verification posture (cargo-deny, deny.toml, and why Miri is not a v1 gate) — not just the disclosure SLA.

Read the threat model first. Scope of protection and scope of disclosure are one story.

Security Policy

Aegis is a research instrument for secure agent tool execution. This document covers how to report vulnerabilities, what we support, and what is in scope.

Threat model: docs/threat-model.md — read this first to understand what Aegis protects and its named non-goals. Scope of protection and scope of disclosure are one story.

Reporting a vulnerability

Please do not open public GitHub issues for security vulnerabilities.

Report privately to:

Email: support@botzr.com

Include:

  • Description of the issue and impact
  • Steps to reproduce (proof-of-concept welcome)
  • Affected version or commit SHA
  • Your contact for follow-up (optional)

You may also use GitHub private vulnerability reporting on the repository if you prefer that channel.

What to expect (solo maintainer SLA)

StageCommitment
AcknowledgmentWithin 72 hours of report receipt
Triage / updatesBest effort; severity-dependent
Fix & advisoryBest effort; critical issues prioritized
CreditWith reporter permission, in the GitHub Security Advisory

This is a solo-maintainer project. Timelines are honest estimates, not enterprise SLAs. We appreciate responsible disclosure and will work in good faith.

Coordinated disclosure

We follow a 90-day coordinated disclosure window by default:

  1. Reporter submits privately.
  2. Maintainer acknowledges and triages.
  3. Fix developed and validated.
  4. Advisory published via GitHub Security Advisories.
  5. RustSec / cargo audit ecosystem notified for in-scope runtime crates when applicable.

If a fix cannot ship within 90 days, we will agree on an extension with the reporter. Public disclosure before a fix is available should be coordinated with the maintainer.

Supported versions

Pre-1.0 releases receive security fixes on the latest minor release only.

VersionSupported
latest 0.x.y on main✅
older 0.x.* tags❌

Check releases for the current tag. Integrators should pin to a released version and plan upgrades.

In scope

Security issues in the Aegis runtime crates that affect confidentiality, integrity, or availability of the enforcement pipeline:

CrateScope
botzr-aegis-coreTypes/traits used in enforcement decisions
botzr-aegis-policyPolicy evaluation bypass, silent widening
botzr-aegis-capabilityGrant minting, default-deny bypass
botzr-aegis-sandboxWASM isolation, cap-std preopens, host-function grant enforcement
botzr-aegis-auditRecord emission gaps, secret leakage in audit fields, chain or signature forgery (schema v2 JSONL: request_digest plus optional response_digest, hash-chained and ed25519-signed; no raw payloads, no OTel export — see the record format spec)
botzr-aegis-runtimePipeline ordering, audit-on-all-exits

Also in scope:

  • Deny-suite or adversarial-demo tests that demonstrate a containment failure
  • Resource limit bypass (memory, wall-clock, output size)
  • Dependency CVEs in pinned wasmtime/cap-std when exploitable through Aegis’s use

Out of scope

CategoryExamples
Layer 2 governancePre-release; not part of v1 runtime
Example / fixture codeexamples/, tests/fixtures/damage-bot — deliberately adversarial test guests
Third-party WASM guestsTool code you compile and run; Aegis does not audit your guest’s business logic
Upstream wasmtime/cap-stdReport to Bytecode Alliance / upstream; we track and bump pins
Deployment misconfigurationOver-broad grants, shared host credentials, missing network segmentation
Prompt injection / return-value exfilNamed non-goals — see threat model §6
Model B marketed as full isolationDocumentation issue if our docs are wrong; design limitation if expectations exceed Model B

Hardening recommendations for integrators

These are not Aegis bugs, but common failure modes:

  1. Keep host functions small and audited. Every Model B import is a hole in the sandbox wall.
  2. Never configure the sandbox from the raw request — only from the resolved grant.
  3. Use cap-std preopens for filesystem scoping; do not hand-roll path prefix checks.
  4. Deploy process-per-tenant for multi-tenant isolation (v1 honesty boundary).
  5. Read the threat model before claiming isolation guarantees to downstream users.

Verification posture

The workspace forbids unsafe (unsafe_code = forbid workspace-wide), so Miri on Aegis crates is not a v1 verification gate — there is no first-party unsafe code for it to check. Upstream dependencies such as wasmtime and cap-std do contain their own unsafe and own their UB surface; we consume them as pinned dependencies and track RUSTSEC advisories via cargo-deny (deny.toml + CI supply-chain and weekly advisory jobs) rather than re-auditing their unsafe code here. See docs/threat-model.md for what isolation is and is not claimed.

Contact