Skip to content

Product Boundaries

This page defines the current agent-bom product lanes so public docs, demos, PRs, and buyer conversations use the same vocabulary.

The short version:

  • OSS is the open scanner, CLI, reports, MCP tools, API, and local control plane components in this repository.
  • Self-hosted enterprise is the same product operated in the customer's infrastructure with Postgres/Supabase, Helm, auth, tenant isolation, audit, fleet, graph, and selected runtime controls.
  • Snowflake is a warehouse-native governance and deployment lane for customers who already govern data in Snowflake. It is not the default transactional control-plane backend for every feature.
  • Managed agent-bom Cloud is not shipped in this repository today.

Lane Matrix

Lane First command Artifact Current boundary
OSS local scanner agent-bom agents --demo --offline terminal findings, JSON/HTML/SARIF/SBOM, graph exports runs locally or in CI; no hosted service required
OSS MCP tools agent-bom mcp server strict-args read-only tools for agents agent-callable security surface; no remote control plane required
OSS API/UI pilot agent-bom serve --host 127.0.0.1 --port 8000 local API and browser cockpit single-node pilot or demo; use auth for non-loopback binds
Self-hosted enterprise helm template agent-bom deploy/helm/agent-bom -f deploy/helm/agent-bom/examples/eks-production-values.yaml production-shaped Kubernetes manifests customer VPC/Kubernetes/database/IdP/audit boundary
Snowflake POV agent-bom agents --snowflake Snowflake inventory and posture evidence visible to the configured role read-only Snowflake discovery, governance, and selected backend paths
Snowflake Native App follow docs/snowflake-native-app/INSTALL.md customer-account Snowflake deployment package Snowflake-account deployment lane; not a replacement for every API/UI store

OSS

OSS is the default adoption path and should remain useful without a hosted service.

What is shipped:

  • CLI scans, local reports, SARIF, SBOM, HTML, JSON, and graph exports
  • GitHub Action and Docker entry points
  • read-only MCP tool server with strict argument validation
  • local API/UI pilot mode
  • skills scanning and policy-aware CI gates
  • graph-backed ExposurePath output for humans and agents

What is not implied:

  • no managed agent-bom Cloud account is created by installing the package
  • no vendor telemetry is required for local scans
  • no dashboard is required for CI or MCP use

Self-Hosted Enterprise

Self-hosted enterprise is the production control-plane lane for customers that need central inventory, graph state, audit, auth, governance, and runtime controls inside their own boundary.

What is shipped:

  • API and dashboard deployment paths
  • Helm profiles and Docker Compose pilot profiles
  • Postgres/Supabase transactional stores for broad control-plane coverage
  • auth, RBAC, tenant scope, audit, evidence, fleet, graph, and policy surfaces
  • runtime proxy/gateway patterns for selected MCP enforcement paths
  • local entitlement metadata hooks for support/SLA and future commercial feature visibility

Recommended first proof:

helm template agent-bom deploy/helm/agent-bom \
  -f deploy/helm/agent-bom/examples/eks-production-values.yaml

Artifact:

  • rendered Kubernetes manifests that show the API/UI, database, auth, runtime, and operational settings that would be applied in the customer's cluster

Next step:

  • bind the deployment to the customer's IdP, Postgres/Supabase, ingress, audit log retention, and selected scan or runtime sources

What is not implied:

  • the repo does not ship a managed multi-tenant vendor cloud service today
  • SQLite is not the recommended clustered enterprise store
  • API-local filesystem scans should stay disabled in shared EKS-style control planes unless an explicit tenant workspace is mounted
  • local entitlement metadata does not make outbound licensing calls and does not gate current OSS scanner or control-plane functionality

Local Entitlement Metadata

Self-hosted packages can set AGENT_BOM_ENTITLEMENT_FILE to a local JSON file so admins and health checks can see support/SLA and enabled commercial metadata without contacting a vendor service.

Example:

{
  "lane": "self-hosted-enterprise",
  "features": ["support.sla", "retention.extended"],
  "support": {
    "tier": "enterprise",
    "sla": "business-hours"
  },
  "expires_at": "2027-01-01T00:00:00Z"
}

Operator surfaces:

  • GET /health includes an entitlement summary.
  • GET /v1/entitlements returns the full local metadata state for admins.
  • GET /v1/entitlements/check/{feature} evaluates one feature and appends an audit entry.

Boundary:

  • Missing metadata returns status: missing and keeps OSS paths usable.
  • Invalid or expired metadata returns status: invalid or status: expired and disables only commercial metadata features.
  • The current implementation is metadata-only. It is not hosted billing, telemetry, or a mandatory license check.

Snowflake

Snowflake is a lane for organizations that already use Snowflake as a governance, evidence, or security-lake boundary.

What is shipped:

  • Snowflake discovery from the CLI when credentials are configured
  • Snowflake CIS and posture evidence surfaces
  • Snowflake Native App packaging and deployment guidance
  • selected Snowflake-backed store paths where the code and backend parity docs say parity exists

Recommended first proof:

agent-bom agents --snowflake --format json --output snowflake-inventory.json

Artifact:

  • a local JSON evidence file for the account, role, warehouse, and schemas visible to the configured read-only Snowflake role

Next step:

  • for a customer-account deployment, follow docs/snowflake-native-app/INSTALL.md and validate the exact enabled features against site-docs/deployment/backend-parity.md

What is not implied:

  • Snowflake is not the default transactional backend for every API/UI workflow
  • Snowflake Native App does not remove the need to document role grants, warehouse boundaries, and customer-owned retention
  • Snowflake support does not mean agent-bom claims full CNAPP parity with a proprietary cloud platform

Managed Cloud Boundary

Managed agent-bom Cloud is a roadmap lane, not a shipped repository feature.

It is acceptable to describe a future managed lane as:

  • managed operations for the same scanner and graph primitives
  • optional hosted scale for teams that do not want to run the control plane
  • customer-controlled data and explicit telemetry boundaries

It is not acceptable to describe it as shipped until there is code, deployment evidence, billing or tenant isolation evidence, and release documentation for that lane.

Copy Rules

Use these phrases:

  • "open security scanner and self-hosted control plane"
  • "open security data plane for AI-era infrastructure"
  • "deploys in the customer's infrastructure"
  • "Snowflake Native App lane" or "Snowflake-backed selected paths"
  • "managed cloud is not shipped today"

Avoid these phrases unless a future release proves them:

  • "agent-bom Cloud is available"
  • "Snowflake is the full control-plane backend"
  • "drop-in commercial CNAPP replacement"
  • "complete CNAPP"
  • "all UI workflows are fully persisted"
  • "all cloud identity providers have live ingestion parity"

Release Checklist

Before a release or demo repeats product-lane claims, verify:

  • README and Docker Hub README mention the same lane boundaries
  • site-docs/deployment/backend-parity.md still matches the backend claim
  • Helm, Docker, CLI, and Snowflake first commands still work or have a stated reason they were not rerun
  • screenshots use the shipped UI and current real or fixture-backed data
  • roadmap items remain labeled as roadmap items