Skip to content

Context Egress Boundary

Why this page exists. A secure context layer is incomplete if it only controls retrieval. Enterprise buyers 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: scripts/generate_context_egress_boundary_pack.py
  • Evidence pack: data/evidence/context-egress-boundary-pack.json
  • Runtime evaluator: scripts/evaluate_context_egress_decision.py
  • MCP tools: recipes_context_egress_boundary_pack and recipes_evaluate_context_egress_decision

Regenerate and validate the pack:

python3 scripts/generate_context_egress_boundary_pack.py
python3 scripts/generate_context_egress_boundary_pack.py --check

Decision model

The pack is default-deny. Runtime decisions are:

DecisionMeaning
allow_public_egress_with_citationPublic or open SecurityRecipes context may leave when source ID, path, hash, and citation metadata are preserved.
allow_tenant_bound_egressTenant-sensitive context may move inside an approved tenant boundary with redaction, audit, retention, and residency controls satisfied.
hold_for_redaction_or_dpaThe request may be legitimate, but is missing redaction, tenant ID, approval, DPA, zero-data-retention, or residency evidence.
deny_unapproved_workflow_egressThe workflow or MCP namespace is not approved for this egress path.
deny_untrusted_destinationThe destination is unknown, untrusted, or disallowed for the data class.
deny_unclassified_egressThe data class or source is missing, unknown, or unmapped.
kill_session_on_secret_egressSecrets, 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:

python3 scripts/evaluate_context_egress_decision.py \
  --workflow-id vulnerable-dependency-remediation \
  --data-class curated_security_guidance \
  --destination-class approved_model_provider \
  --dpa-in-place \
  --zero-data-retention \
  --required-region us \
  --residency-region us \
  --expect-decision allow_public_egress_with_citation

Hold customer source code that lacks required human approval:

python3 scripts/evaluate_context_egress_decision.py \
  --workflow-id vulnerable-dependency-remediation \
  --mcp-namespace repo.contents \
  --destination-class approved_model_provider \
  --tenant-id tenant-123 \
  --dpa-in-place \
  --zero-data-retention \
  --required-region us \
  --residency-region us \
  --expect-decision hold_for_redaction_or_dpa

Kill a secret-egress attempt:

python3 scripts/evaluate_context_egress_decision.py \
  --workflow-id sensitive-data-remediation \
  --data-class secret_or_token \
  --destination-class external_url_or_webhook \
  --contains-secret \
  --expect-decision kill_session_on_secret_egress

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:

recipes_evaluate_context_egress_decision(
  workflow_id="vulnerable-dependency-remediation",
  mcp_namespace="repo.contents",
  destination_class="approved_model_provider",
  tenant_id="tenant-123",
  dpa_in_place=true,
  zero_data_retention=true,
  required_region="us",
  residency_region="us"
)

Why this is enterprise-grade

This moves SecurityRecipes closer to a product an AI platform team can approve and a buyer 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 paid-product 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