Context Egress Boundary

Why this page exists. A secure context layer is incomplete if it only controls retrieval. Enterprise reviewers also need to know where context is allowed to go after retrieval.

The product bet

SecurityRecipes is positioned as the secure context layer for agentic AI. That creates two control planes:

  • Ingress: which context can an agent retrieve?
  • Egress: where can that context go next?

The existing Secure Context Trust Pack and Secure Context Firewall cover ingress. The Context Egress Boundary covers outbound movement to model providers, remote MCP servers, tenant gateways, telemetry sinks, public docs, and external URLs.

That matters because agentic systems routinely mix public guidance, generated evidence, customer findings, source code, logs, tickets, pipeline output, and connector responses in one workflow. A high-trust product needs to make the safe path obvious and the unsafe path boringly blocked.

What was added

  • Source model: data/assurance/context-egress-boundary-model.json
  • Generator:
  • Evidence pack: data/evidence/context-egress-boundary-pack.json
  • Runtime evaluator:
  • MCP tools: recipes_context_egress_boundary_pack and

Regenerate and validate the pack:

Decision model

The pack is default-deny. Runtime decisions are:

Decision Meaning
allow_public_egress_with_citation Public or open SecurityRecipes context may leave when source ID, path, hash, and citation metadata are preserved.
allow_tenant_bound_egress Tenant-sensitive context may move inside an approved tenant boundary with redaction, audit, retention, and residency controls satisfied.
hold_for_redaction_or_dpa The request may be legitimate, but is missing redaction, tenant ID, approval, DPA, zero-data-retention, or residency evidence.
deny_unapproved_workflow_egress The workflow or MCP namespace is not approved for this egress path.
deny_untrusted_destination The destination is unknown, untrusted, or disallowed for the data class.
deny_unclassified_egress The data class or source is missing, unknown, or unmapped.
kill_session_on_secret_egress Secrets, tokens, private keys, signing material, seed phrases, or production credentials attempted to leave the boundary.

Data classes

The model separates context into classes such as:

  • public references,
  • curated SecurityRecipes guidance,
  • generated policy evidence,
  • public vulnerability intelligence,
  • customer asset metadata,
  • customer source code,
  • customer finding metadata,
  • customer pipeline metadata,
  • customer case context,
  • customer runtime logs,
  • regulated personal data,
  • secrets and signing material.

That makes the agent-side behavior simple: classify the context, name the destination, attach the workflow and namespace, then ask for a decision before the data moves.

Destination classes

The generated pack declares destination classes for:

  • securityrecipes_public_corpus,
  • tenant_mcp_gateway,
  • approved_model_provider,
  • approved_remote_mcp_server,
  • observability_sink,
  • untrusted_remote_mcp_server,
  • external_url_or_webhook.

Each destination records whether it is trusted, whether it is an external processor, and whether it requires DPA, zero-data-retention, residency match, connector trust, schema pinning, token-audience validation, or tool-result inspection.

CLI examples

Allow public guidance to an approved model provider:

Hold customer source code that lacks required human approval:

Kill a secret-egress attempt:

MCP examples

Inspect the boundary:

recipes_context_egress_boundary_pack()

Review one data class:

recipes_context_egress_boundary_pack(data_class="customer_source_code")

Evaluate one outbound context movement:

Why this is enterprise-grade

This moves SecurityRecipes closer to a product an AI platform team can approve and a reviewer can diligence:

  • It separates public context from tenant runtime context.
  • It makes model providers and remote MCP servers explicit external processors.
  • It records DPA, zero-data-retention, residency, approval, redaction, and trust-tier requirements as policy inputs.
  • It gives privacy, security, and platform teams a shared vocabulary for data movement.
  • It creates a hosted-ready path for tenant-side egress enforcement, DLP integrations, provider adapters, residency alerts, and customer trust-center exports.

Industry alignment

This feature follows current guidance:

See also