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?

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.

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 and

Run it locally from the repo root:

Evaluate an open-reference context source:

Evaluate the same subject for production MCP use:

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