Secure Context Attestation Pack

Why this page exists. The Secure Context Trust Pack proves which context sources exist. This pack answers the next reviewer question: which context was attested, which hash should an MCP gateway verify, and what has to be signed before production use?

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

The product bet

SecurityRecipes should not look like another recipe catalog. The defensible product is a secure context layer: context sources are registered, hashed, scanned, recertified, exposed through typed MCP tools, and eventually signed for production gateways.

The Secure Context Attestation Pack turns the existing trust pack into an attestation-shaped artifact. It does not pretend the open repo has already produced a cryptographic signature. Instead, it creates a stable attestation seed that can be verified in CI today and signed later with a keyless signing system such as Sigstore or an enterprise attestation service.

Workflow at a glance

Secure Context Attestation Pack workflow

Create and verify a signed statement binding a context package to sources, hashes, owners, freshness, scans, workflow, and release profile.

secure-context

  1. Signal

    Select the context subject

    Identify package, workflow, environment, sources, files, retrieval mode, trust tier, owner, and intended consumers.

  2. Scope

    Collect attestation claims

    Bind source/file hashes, registry state, freshness, poisoning scan, prohibited-data checks, build method, and evidence dependencies.

  3. Decision

    Validate the subject

    Confirm files match approved roots/globs, hashes, owners, scans, package composition, and environment-specific requirements.

  4. Action

    Sign or hold

    Issue an attestation for the allowed profile or hold when identity, hash, freshness, scan, or production requirements fail.

  5. Proof

    Verify at retrieval

    Recheck signature, subject hash, expiry, revocation, workflow/environment match, and policy before context use.

Decision gate

Do subject, claims, evidence, signature, freshness, and intended-use requirements all match the requested profile?

Proceed

Issue or accept the attestation for the exact context package and use.

Hold or stop

Hold generation or retrieval on mismatch, expiry, revocation, missing scans, or insufficient production evidence.

Evidence to retain

  • subject/source hashes
  • owner/freshness/scan claims
  • signature and verification result

Expected outputs

  • secure-context attestation
  • verification decision
  • recertification request

What was added

  • data/assurance/secure-context-attestation-profile.json - the source profile for attestation policy, signed environments, recertification SLAs, and primary-source standards alignment.
  • data/evidence/secure-context-attestation-pack.json - the generated pack with in-toto-shaped subjects, verification policy, recertification queue, and signature readiness.
  • MCP tools: recipes_secure_context_attestation_pack, paired with recipes_playbook_plan using playbook id secure-context-attestation.

Run it locally from the repo root:

python3 scripts/generate_secure_context_attestation_pack.py
python3 scripts/generate_secure_context_attestation_pack.py --check

Evaluate an open-reference context source:

python3 scripts/evaluate_context_attestation_decision.py \
  --subject-type context_source \
  --source-id recipes \
  --environment open_reference \
  --expect-decision allow_attested_context

Evaluate the same subject for production MCP use:

python3 scripts/evaluate_context_attestation_decision.py \
  --subject-type context_source \
  --source-id recipes \
  --environment production_mcp \
  --expect-decision hold_for_signature

That second hold is intentional. Production and diligence environments must present a signature bundle and transparency-log verification before the subject is treated as production attested.

What is inside the pack

Section Purpose
attestation_summary Counts for active subjects, source subjects, workflow-package subjects, source-artifact subjects, decisions, statuses, and validation failures.
attestation_manifest Attestation subjects for registered context sources, workflow context packages, and trust-pack source artifacts.
in_toto_statement An in-toto-shaped statement seed with subject digests and a SecurityRecipes secure-context predicate.
verification_policy Allow, hold, deny, and kill-session decisions for open-reference, CI, production MCP, trust-center, and diligence environments.
signature_readiness The statement hash and explicit production requirement for a keyless signature bundle, identity-bound certificate, and transparency-log proof.
recertification_queue Any source or workflow package that is registered but not active enough for trusted retrieval.

Runtime decisions

The evaluator returns:

  • allow_attested_context for active context sources or source artifacts in open-reference and CI environments.
  • allow_attested_workflow_context for active workflow context packages whose source set is covered by context-source attestations.
  • hold_for_signature when a production, trust-center, or trust review diligence request lacks signature and transparency-log evidence.
  • hold_for_recertification when a subject is registered but stale, inactive, or missing source coverage.
  • deny_attestation_mismatch when a supplied hash does not match the attested digest.
  • deny_unregistered_attestation for unknown subjects or undeclared environments.
  • kill_session_on_forbidden_attestation for prohibited data classes such as raw tokens, private keys, live signing material, or unrestricted customer logs.

Industry alignment

This feature follows current primary guidance:

Trusted-source path

The open pack is valuable by itself because teams can inspect the context surface and fail CI on drift. The enterprise product path is stronger:

  • Hosted keyless signing for context packs and workflow context packages.
  • Customer-private context recertification for repositories, tickets, logs, approvals, and connector metadata.
  • Transparency-log monitoring for unexpected signing events.
  • MCP gateway verification APIs that hold or deny context before agents see it.
  • Procurement and trust-center exports that show context provenance, signature readiness, and recertification state.

That is the kind of control primitive a frontier AI lab, cloud platform, or security company can acquire: not only content, but a credible trust layer for the context agents depend on.

See also