Secure Context Evidence Contract

Why this page exists. SecurityRecipes already has many generated evidence packs. The next product step is a stable contract for exposing that evidence safely through a hosted MCP/API surface without leaking raw prompts, customer code, secrets, tokens, or private runtime data.

The product bet

SecurityRecipes is positioned as the Secure Context Layer for Agentic AI. That only becomes enterprise-grade when reviewers can answer:

  • What evidence objects are safe to expose?
  • Which source packs back each claim?
  • Which channels can publish public, design-partner, trust-center, hosted API, or reviewer evidence?
  • Which controls block an export that contains raw prompts, source code, customer data, secrets, tokens, or unsigned evidence?
  • What would the hosted API look like before the product is built?

The Secure Context Evidence Contract turns those questions into a generated artifact and deterministic release evaluator. It is a product foundation, not a marketing page.

What was added

  • Source profile: data/assurance/secure-context-evidence-contract-profile.json
  • Generator:
  • Evidence contract: data/evidence/secure-context-evidence-contract.json
  • Runtime evaluator:
  • MCP tools: recipes_secure_context_evidence_contract and

Regenerate and validate the contract:

Evaluate a safe trust-center release:

Evaluate a blocked secret release:

Decision model

Decision Meaning
allow_publish_evidence_release The release satisfies channel, redaction, source-hash, artifact, tenant, approval, retention, DPA, ZDR, and signature requirements.
hold_for_redaction_or_signature The release is missing redaction, source hashes, tenant binding, approval, retention, DPA/ZDR state, signature evidence, or registered artifact references.
hold_for_customer_runtime_evidence The selected channel requires customer runtime proof, receipts, telemetry, or customer proof metrics.
deny_sensitive_payload_release The release contains raw prompts, source code, or customer data without an allowed and verified redaction boundary.
kill_session_on_secret_or_token_release The release contains or declares secrets, tokens, keys, cookies, seed phrases, signing material, or other prohibited payload classes.

Evidence object catalog

The generated contract defines stable object types for the evidence a hosted product will need:

  • evidence releases and source-pack references;
  • secure context source references, lineage, and attestations;
  • MCP policy decisions and tool-surface baselines;
  • run receipt and approval receipt references;
  • metadata-only telemetry references;
  • trust-center claims and customer proof metrics;
  • incident signals, redaction manifests, and release signatures.

Each object type has required fields, a redaction rule, linked source packs, and a contract hash. That makes the output reviewable by agents, humans, procurement systems, and future hosted APIs.

Release channels

The contract separates evidence by audience and risk:

Channel Purpose
open_reference Public evidence for forks, search, and open adopters.
design_partner_private Tenant-bound customer pilot proof with runtime evidence.
trust_center_external Signed or signable procurement and governance packet.
acquirer_diligence Redacted runtime proof for strategic reviewer review.
hosted_mcp_api Hosted-ready API path for evidence release checks, MCP decisions, receipt lookup, and trust-center export.

The important design choice is fail-closed publication. A channel that needs customer runtime proof, tenant binding, DPA state, ZDR state, or a signature cannot silently downgrade itself to a public export.

Hosted API surface

The generated artifact sketches the hosted v1 API before the product exists:

  • GET /v1/evidence/contract
  • POST /v1/evidence/releases/evaluate
  • POST /v1/evidence/releases
  • GET /v1/evidence/releases/{release_id}
  • GET /v1/trust-center/export
  • GET /v1/mcp/decisions/{correlation_id}
  • GET /v1/run-receipts/{receipt_id}
  • GET /v1/customer-proof/metrics

This is intentionally narrow. It gives a design partner or reviewer a concrete integration shape while preserving the open repo’s read-only boundary.

Industry alignment

This feature follows current primary guidance:

Trusted-source path

The open repo now proves the object model and evaluator. The hosted-ready proof path is a hosted evidence API:

  • tenant-private evidence release checks;
  • signed trust-center exports;
  • MCP decision lookup by correlation ID;
  • run-receipt and approval-receipt lookup;
  • customer-proof metric aggregation;
  • DPA, ZDR, retention, and signature state enforcement;
  • reviewer-ready redacted evidence packets.

That is a credible bridge from open knowledge to a production secure context layer that an AI platform, frontier lab, security vendor, or regulated enterprise could buy.

MCP examples

Inspect the contract:

recipes_secure_context_evidence_contract()

Inspect one release channel:

recipes_secure_context_evidence_contract(channel_id="trust_center_external")

Evaluate a hosted API release:

See also