Independent evidence without becoming a new secret or control plane.
BeProof is built around metadata-only credential handling, source attribution, explicit consent, visible CoverageGap records, and independently verifiable exports. Planned adapters will record external control outcomes without claiming that BeProof performed the enforcement.
Security model
BeProof is designed as an independent, local-first evidence layer. It inspects AI-agent surfaces, credential references, access metadata, and usage signals on the endpoint, then links review and policy outcomes back to their evidence.
Evidence versus enforcement
BeProof does not block AI-agent actions or remediate endpoint software. External allow, warning, denial, and remediation outcomes are accepted only as source-attributed evidence from the product that performed them. A BeProof finding or review item is not proof that enforcement occurred.
Provenance and link strength
Action and link evidence carries source references, timestamps, confidence, collector identity, transformation metadata, journal linkage, and export integrity metadata where the source supports them. Provider or path matches remain correlations. Causal action links and external enforcement events are labelled partial or planned until a source supplies stable action identifiers and verifiable provenance.
Privacy model
Evidence processing starts on the user endpoint by default. Reports are intended to carry metadata, fingerprints, source references, consent state, and integrity information rather than raw sensitive values.
Website product analytics
When enabled, the public website uses PostHog in cookieless mode for anonymous page traffic and an explicit pilot-request funnel. Autocapture, session replay, person profiles, surveys, heatmaps, and exception capture are disabled. Pilot form values such as name, email, company, role, AI tools, and evidence-gap text are not sent to PostHog; only field names, counts, duration buckets, fleet-size categories, and delivery outcomes are measured.
What BeProof scans
BeProof can inspect configured scan scopes, known AI-agent locations, MCP configs, instruction files, credential references, usage signals, install records, and optional cloud grants when provider tokens or admin APIs are configured.
Coverage for this audit
The macOS app shows a per-audit matrix (Surface / Expected / Scanned / Result) with separate Declared, Granted, Observed, and Trust completeness. The public coverage page additionally distinguishes inventory, access, activity, control outcomes, and provenance. BeProof intentionally avoids a single global score so partial layers stay visible.
What BeProof never stores
BeProof reports are designed not to store raw API keys, raw OAuth tokens, passwords, or full secret values.
Credential handling
Credential evidence is represented through provider, storage type, locator, source, and fingerprint metadata.
Consent model
Sensitive sources such as keychain metadata require explicit user or admin approval. Missing or denied access is represented as a CoverageGap, not as a clean result.
Local storage
Personal Mode is designed around local processing and a local SQLite database. Evidence events are appended to a hash-chain journal; journal payloads are encrypted at rest with AES-256-GCM and a Keychain-bound key per database path. Tampering remains visible through `verify-journal`. Inventory tables are metadata-only but not encrypted in the current release.
Retention boundaries
Personal and managed-local evidence stays under endpoint or customer administration. Managed-fleet uploads are limited to allowlisted, tenant-scoped summaries; the pilot default upstream retention is 90 days and is reviewed during procurement. Future external-control metadata must follow the same explicit retention and deletion boundary.
Verify CLI contract
BeProof exposes five distinct verify commands. They are not interchangeable: `verify-export-manifest` checks artifact integrity only; `verify-export` additionally requires journal linkage fields and a local database; `verify-journal` validates the full local chain; `verify-install` validates release distribution trust; `verify-incident-bundle` validates a signed incident evidence package without the endpoint database.
When to use which verify command
Offline recipient / GRC handoff: `beproof verify-export-manifest --artifact <path>` (optional `--public-key` for trust-anchor cross-check). Incident handoff: `beproof verify-incident-bundle --artifact <path>`. Local auditor trust on the scanning endpoint: `beproof verify-export --artifact <path>` plus `beproof verify-journal`. Release / install trust: `beproof verify-install --app /Applications/BeProofApp.app` with optional `--artifact` and `--provenance` for DMG and SBOM checks.
Telemetry policy
BeProof does not depend on sending raw endpoint evidence to a hosted service. Future managed action or enforcement telemetry must preserve source attribution, consent, scope, retention, privacy class, freshness, and evidence-quality boundaries.
Export integrity
Audit and incident exports include artifact SHA256 and an Ed25519-signed manifest hash (`ed25519-v1`). Audit exports can additionally carry journal linkage fields when produced on an endpoint with an active evidence journal. Recipients without the local database should use `verify-export-manifest` for an audit export or `verify-incident-bundle` for an incident package. The scanning endpoint should add `verify-export` and `verify-journal` for complete local trust. Key strategies are documented in the BeProof repository (`EXPORT_SIGNING.md`, `JOURNAL_ENCRYPTION.md`).
Release trust
Release trust is implemented in the public release pipeline: signed/notarized macOS app DMG and CLI with published checksum, SBOM, provenance, Sparkle appcast metadata (disabled in managed mode), and CLI verification via `beproof verify-install`. Enterprise release controls (partial): Fleet-wide verify-install attestation in control plane, tenant-private or air-gapped artifact mirror, org-enforced minimum release version policy, and automated MDM promotion workflow — manual MDM runbooks today. Export manifests use Ed25519 signing (`ed25519-v1`); legacy `sha256-only` manifests remain verifiable for artifact hash only.
macOS admin requirements
BeProof supports macOS 14+ on Apple Silicon. Baseline deployment does not require Full Disk Access or an Endpoint Security extension. Optional Keychain metadata scans require explicit user consent in addition to any macOS TCC approval. MDM deployment — PKG, PPPC template, org-policy overlay, and Jamf/Intune/Kandji/Fleet runbooks — is documented on the Managed deployment page. See also the macOS Admin Guide for support and permissions matrices.
Vulnerability disclosure
Report security issues privately to 0xy9en@gmail.com — do not use public GitHub issues. We aim to acknowledge reports within 3 business days and provide initial triage within 10 business days. Supported components are the latest macOS app and CLI releases from the public downloads repository. Full policy: SECURITY.md in the BeProof repository.
Known limitations
BeProof cannot guarantee complete cloud or control visibility unless the relevant provider tokens, admin APIs, or source adapters are configured and healthy. Cloud grants, cloud usage, causal action lineage, and external enforcement outcomes should be treated as partial or unknown unless the report explicitly marks them as covered. Historical usage does not by itself prove that an agent is currently running.
Verify command reference
Normative semantics align with the Policy Pack verify CLI contract and the macOS guide verify section.
| Command | Validates | Local DB | Status |
|---|---|---|---|
beproof verify-journal | Append-only hash chain: sequence continuity, payload hashes, prev-hash links, local chain head, and journal payload encryption status (AES-256-GCM at rest). | Yes (`--db`, default `.beproof/beproof.db`) | Shipped |
beproof verify-export | Manifest hash plus journal linkage (`journalStartSeq`, `journalEndSeq`, `journalHeadHash`) against the local evidence journal. | Yes (optional `--db`; required for journal linkage check) | Shipped |
beproof verify-export-manifest | Artifact SHA256, manifest hash, and Ed25519 signature (`ed25519-v1`). No journal linkage. | No | Shipped |
beproof verify-install | App signature, notarization, optional DMG checksum, and release provenance/SBOM when artifacts are supplied. | No | Shipped (CI gate + public release) |
beproof verify-incident-bundle | Incident bundle artifact SHA256, manifest hash, and Ed25519 signature over the causal evidence package. | No | Shipped |