Secure Context Customer Proof Pack

Why this page exists. SecurityRecipes now has strong reference evidence. The next credibility gap is customer proof: runtime events, receipts, MCP decisions, redacted telemetry, operational-impact metrics, and renewal signals that prove the secure context layer works in a real pilot.

Rechecked source anchors against the public MCP specification 2026-07-28 on August 21, 2026.

SecurityRecipes is positioned as The Secure Context Layer for Agentic AI. The open project already shows the control model: secure context, MCP authorization, protocol conformance, source freshness, telemetry, run receipts, evals, reviewer diligence, and value modeling. That is enough to start serious conversations, but it is not enough to claim recurring adoption proof or a trusted-source outcome.

The Secure Context Customer Proof Pack closes that gap honestly. It defines what a design partner must measure before customer evidence can replace assumptions.

What was added

  • data/assurance/secure-context-customer-proof-profile.json - source profile for proof claims, runtime event classes, metrics, renewal gates, reviewer readout, and proof risks.
  • data/evidence/secure-context-customer-proof-pack.json - generated pack with source-pack hashes, 7 proof claims, 9 metrics, 9 runtime event classes, 5 renewal gates, and 6 proof risks.
  • recipes_secure_context_customer_proof_pack - MCP tool for the full pack, one proof claim, event class, metric, renewal gate, risk, or status-filtered view.

Workflow at a glance

Secure Context Customer Proof Pack workflow

Convert design-partner runtime evidence into qualified proof claims, operational metrics, renewal gates, and honest gaps.

trust-and-adoption

  1. Signal

    Select the proof period

    Define customer, deployment, workflows, cohort, dates, baseline, claims, metrics, release audience, and consent.

  2. Scope

    Collect customer events

    Ingest context, authorization, approval, telemetry, receipts, review outcomes, incidents, operational impact, and renewal signals.

  3. Decision

    Validate proof quality

    Check correlation, coverage, source hashes, tenant isolation, redaction, denominators, bias, attribution, and missing intervals.

  4. Action

    Evaluate claims and gates

    Calculate defined metrics and mark each claim proven, partial, failed, or not measured; apply renewal/expansion blockers.

  5. Proof

    Publish the proof pack

    Release approved aggregated evidence, limitations, gaps, owner actions, renewal decision, and next measurement period.

Decision gate

Do customer events support the claimed control and value outcomes with sufficient coverage and no blocking renewal gate?

Proceed

Publish qualified proof and approve the bounded renewal/expansion path.

Hold or stop

Hold claims or renewal when telemetry, control outcomes, attribution, privacy, or thresholds fail.

Evidence to retain

  • correlated customer event set
  • metric/claim calculations
  • renewal-gate decisions

Expected outputs

  • customer proof pack
  • renewal/expansion recommendation
  • proof-gap plan

What the pack contains

Section Purpose
customer_proof_summary Contract status, source-pack readiness, proof-claim count, metric count, renewal-gate count, and failure count.
proof_claims reviewer claims that require customer runtime proof, including context retrieval, MCP authorization, safe holds, redacted telemetry, ROI replacement, source freshness, and hosted-ready-proof evidence.
runtime_event_classes Metadata-first events a design partner should emit, such as context.package.returned, mcp.authorization.decided, approval.receipt.validated, and reviewer.outcome.recorded.
metric_definitions Renewal metrics such as receipt completeness, context hash coverage, MCP pre-execution decisions, safe hold behavior, sensitive telemetry escape count, reviewer minutes, and hosted-ready-proof confirmation.
renewal_gates Hold conditions that block renewal, expansion, reviewer export, or trust review claims until customer evidence passes.
acquirer_readout What is ready, what is not ready, and the next 90 days of proof collection.
risk_register How the project avoids overclaiming from synthetic demos, leaky telemetry, unproven MCP auth, weak operational-impact proof, source drift, or vague hosted-ready proof paths.

The generated artifact currently reports customer_proof_contract_ready with 10/10 source packs ready. It still marks the actual proof state as customer_runtime_evidence_required, which is intentional.

Why it is review-ready

This pack gives the project a more serious posture in security reviewer conversations:

  • It turns a design-partner pilot into a measurable evidence contract.
  • It treats holds, denials, and kill decisions as product value when they prevent unsafe agent action.
  • It requires metadata-first telemetry and zero counted secret capture.
  • It blocks operational-impact claims until customer runtime evidence replaces default assumptions.
  • It names the next vendor proof: hosted-ready proof path, budget owner, expansion trigger, support burden, and renewal signal.

That makes the path to a valuable project clearer: open evidence creates trust, customer proof validates the wedge, and hosted MCP controls become the review-ready hosted layer.

MCP examples

Inspect the full customer proof pack:

recipes_secure_context_customer_proof_pack()

Inspect one proof claim:

recipes_secure_context_customer_proof_pack(claim_id="mcp-calls-are-authorized-before-execution")

Inspect one runtime event class:

recipes_secure_context_customer_proof_pack(event_id="mcp.authorization.decided")

Inspect one renewal gate:

recipes_secure_context_customer_proof_pack(gate_id="roi-impact-replaces-assumptions")

Find contract areas that still require customer evidence:

recipes_secure_context_customer_proof_pack(status="customer_metric_required")

Industry alignment

The profile is grounded in current primary sources:

See also