How Cortex collects context candidates
How Cortex discovers permitted MCP tools and collects bounded GitHub candidate records without automatically inserting them into prompts.
- Permitted sourcesMCP discovery follows active policy
- Opted-in retrievalAutomatic tool calls need enablement
- Context candidatesCollection leaves prompts unchanged
Cortex can discover tools on permitted MCP mappings and, when separately enabled, collect supported GitHub candidate records during an AI session. It does not automatically insert collected candidates into a user's prompt or change a provider response. This is separate from Smart Router, which selects where a request goes, and from ordinary activity capture. Collection and upload depend on active configuration, policy, and deployment enablement.
How context is collected
After Cortex captures an exchange with a conversation identifier, it can ask each permitted, configured MCP mapping for its tool catalog. Catalog discovery runs on a per-conversation cadence while capture and MCP invocation are active.
Automatic retrieval of candidate documents is a separate, managed opt-in. It requires an explicit enablement setting, a permitted GitHub repository context, the official GitHub MCP mapping, and an available tool catalog. The current candidate adapters handle GitHub issues, pull requests, and commits.
Collection is best effort. Cortex skips the work when capture is inactive, the exchange has no conversation identifier, MCP invocation is unavailable, source policy denies a mapping, required repository context is unavailable, or a configured limit is reached. Configuration changes also stop work that was planned under an earlier policy or mapping.
Source access and limits
MCP discovery and retrieval only use mappings that are configured and permitted by the active MCP policy. Candidate retrieval does not infer arbitrary sources or synthesize an open-ended search.
The implementation bounds automatic GitHub retrieval to a small number of queries per cadence firing and a small number of admitted candidates per query. It ranks supported records by recency before retaining them. These limits bound each firing and reduce repeated collection.
Source permissions remain important. Configure supported tools and capture paths through AI tools supported by Defender, and review Cortex data handling in Data flow and access and Roles and visibility.
What is retained and delivered
Supported GitHub candidate records are first stored locally with their retrieval metadata. The full MCP result body and the literal query text are not sent through the candidate-upload path.
When candidate upload is configured for a device, Cortex sends a device-authenticated batch of candidate references and metadata. The upload can include a secret-scrubbed content preview bounded to 2,048 UTF-8 bytes. URLs that contain credentials, a query string, or a fragment are removed from this upload.
The upload path is independently gated. It requires an enrolled device, local candidate storage, and a configured capture service. The receiving service also uses an organization allowlist that is empty by default, so an accepted upload can remain unstored until the organization is explicitly enabled. Failed uploads remain pending locally for a later attempt.
Capture, enrichment, and prompt context
These concepts describe different parts of the system:
| Concept | Current behavior |
|---|---|
| Capture | Records supported activity and its permitted telemetry. |
| Context enrichment | Discovers permitted MCP tools and can collect bounded GitHub candidate records. |
| Prompt augmentation | Adds selected context to a model request. The current collection path does not do this. |
For the broader request and telemetry path, see Defender request flow.
For retrieval from connected sources and the evidence behind generated answers, see Search company knowledge and inspect evidence.