Honest Status

• ✓Public landing page with hero, problem, capability passport overview, prompt-vs-native explainer
• ✓Public registry preview with 10 seed packages
• ✓Capability Passport detail pages for all 10 seed packages
• ✓Manifest Spec v0.1
• ✓Capability Passport Spec v0.1
• ✓Install Receipt Spec v0.1
• ✓Policy Pack Spec v0.1
• ✓Prompt-URL-Install Spec v0.1
• ✓LLM-readable site install card at /llms.txt (text/plain)
• ✓LLM-readable per-package install cards at /packages/[slug]/llms.txt (text/plain)
• ✓Machine-readable registry endpoint declaration at /.well-known/apai.json
• ✓Honest status page (this page)
• ✓Security baseline page
• ✓Pricing preview page
• ✓Private registry beta and waitlist pages
• ✓Publisher application page
• ✓JSON Schemas for manifest, passport, receipt, policy
• ✓CLI scaffold under packages/cli/ (commands print stub output and write local receipts)
• ✓Install Card Verification: per-package install cards include a SHA-256 Checksum line. Agents echo it back; POST /api/install/verify validates. Catches LLM fabrications about which card was loaded. Does NOT enforce runtime behavior - that is the Policy Pack story.
• ✓Provenance Chain structural verification: three-step (publish / retrieval / install) chain with prev_hash linking + payload_sha256 hash-of-payload. POST /api/provenance/verify returns chainIntegrity (verified | broken | missing), stepsPresent, stepsVerified, and warnings. The chain LINKING is cryptographically verified; the chain IDENTITIES are not (see stubbed).
• ✓Cross-agent attestation in provenance chain: schema accepts up to 16 install steps per chain (publish + retrieval + up to 14 install steps). One artifact installed by multiple agents in an operator fleet (e.g. Claude Code + Codex on two different machines) produces one chain with multiple install steps, each referencing its own install receipt. /api/provenance/verify handles arbitrary step counts and returns one chain-link plus one payload-hash entry per step. STRUCTURALLY supported; distinct verified signers are stubbed pending v0.2 trust root (see stubbed).
• ✓Sigstore Bundle verification (v0.2 spike): POST /api/provenance/verify-sigstore verifies real Sigstore Bundles (V0.3 format) against pinned Fulcio trust root. Five-layer verification: (1) bundle parsing with media-type discrimination, (2) X.509 cert chain to Fulcio root with CA constraint checks (signing-time validation when tlog integratedTime is available; RFC 3161 timestamp parsing deferred), (3) ECDSA P-256 signature verification with artifact digest match (requires caller to supply artifact bytes), (4) Rekor Merkle inclusion proof recomputation (RFC 6962 tree hashing) with bundle-to-body binding cross-check (checkpoint signature verification is attempted but may not pass all checkpoint formats; verdict is partially-verified when checkpoint fails), (5) signer identity extraction from cert SAN. Trust root is pinned (TUF refresh is v0.3). OIDC issuer extraction is deferred (requires raw ASN.1 parsing). EKU check on signing cert is not implemented. V0.1 bundles parse but inclusionPromise verification is not implemented.
• ✓Behavioral scanner v0.1: lib/scanner.ts now produces deterministic scan reports for prompt-injection phrases, secret-exfiltration wording, destructive command patterns, hidden Unicode format controls, plain HTTP URLs, and oversized prompt payloads. /api/audit/package/[slug] returns scanner_version, scanner_status, summary counts, highest severity, findings, and the later-phase checks it does not perform.
• ✓CLI source-prefix preview: `apai install npm:left-pad --dry-run`, `pip:requests`, `gh:owner/repo`, and `gemini:<url>` are parsed as wrapped external source references. v0.1 previews the underlying installer as an argv object and blocks external execution, file writes, and receipts outside dry-run.
• ✓CLI receipt-aware rollback: `apai rollback <package> --install-id <id>` reads and verifies the local install receipt, completes as a no-op when no payload files were recorded, removes only verified package-store files recorded under ~/.apai/packages/<slug>/<version>/, blocks untrusted receipt evidence, and writes rollback-attempt evidence under ~/.apai/rollbacks unless --dry-run is used.
• ✓Seven checksum-pinned package-store payloads: prompt-preflight-starter protocol, costguard cost policy, mcp-audit audit profile, agent-passport template, coding-safe-mode policy, doc-brief workflow, and private-workspace-policy policy.

Exists in code; not yet functional in the way the spec describes.

• ~CLI external install execution: source-prefixed external references are recognized for preview, but APAI does not yet run npm, pip, gh skill, gemini extensions, or any other external package manager.
• ~Scanner limitations: v0.1 is deterministic heuristic scanning only. Model-assisted prompt-injection classification, OAuth-scope review, dependency vulnerability scanning, publisher signature verification, and transitive MCP risk review land later.
• ~Waitlist form: submits to /api/waitlist but persistence is in-memory only; Phase 4 adds Neon Postgres + Resend confirmation email
• ~Audit API limitation: /api/audit/package scans published package metadata and install URLs, not downloaded package payload bytes. Deep payload scanning lands in a later phase.
• ~Install preview API: /api/install/preview accepts APAI slugs and source-prefixed references, returns the wrapped installer argv object, and explicitly blocks external execution in v0.1. Receipt API remains an example payload until Phase 1.
• ~Provenance Chain cryptographic signature verification: at v0.1 the ed25519 signatures embedded in each chain step are placeholder strings prefixed 'stub-ed25519:'. There is no key authority, no sigstore, no fulcio, no rekor, no publisher enrollment, no key rotation. The trustRoot literal everywhere is 'stub-v0.1-no-trust-root'. Chain LINKING is structurally verified; chain IDENTITIES are not. Real signing lands in v0.2.
• ~Cross-agent attestation distinct-signer verification: at v0.1 multiple install steps in one chain may carry different actor.id and actor.key_id strings (e.g. agent-claude-code vs agent-codex-jwgh02), but these are opaque strings with no key authority. A registry that mints a chain can choose any three key_id values it wants and the chain will verify. Distinct verified signers land with the v0.2 trust root.

Roadmap items. Not present in any form yet.

• ○User accounts, sessions, authentication, billing (Phase 4)
• ○Real multi-source CLI install execution with external package fetch, dependency scanning, trust gates, and receipts (Phase 1)
• ○Remote MCP gateway at mcp.apai.run (Phase 6)
• ○Private workspaces and approval queue (Phase 5)
• ○Publisher verification and package signing (Phase 6)
• ○Audit log export (Phase 5)
• ○Model-assisted prompt-injection classification, OAuth-scope review, dependency vulnerability scanning, and transitive MCP risk review (later phase)
• ○Multi-tenant database (Phase 4)
• ○Stripe billing integration (Phase 4)
• ○Workspace policies and runtime enforcement (Phase 5)
• ○Trademark clearance for APAI name (legal track, not engineering)