2 min lesson
Model context is itself sensitive data
Use "What untrusted content can this server push into context and what sensitive context can it pull out" to describe the practical rule.
Step 1 of 2
Model context is itself sensitive datawhat goes in is what can leak out
Whatever lands in the model's context - code, secrets that slipped into a file, internal API responses - can leave through any tool call or any provider request. Minimizing context isn't just a cost lever, it's a data-protection control. The less you put in, the less there is to exfiltrate.
Cursor respects model blocklists and won't send requests to blocked models, so an org can keep its code out of a provider or model it hasn't approved. Cite this as a real, enforced control - it's a clean example of a technical guarantee about where context is allowed to go, not just a policy promise.
If asked to assess an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. integration, split your answer into ingress and egress at that boundary: what untrusted content can this server push into context and what sensitive context can it pull out. Then map each to a control - provenance labeling and clamping for ingress, egress bounds and least-privilege for outbound. Treating the server as an untrusted dependency is the framing that signals seniority.
"Take the ticket-tracker server we just connected. Ingress: it hands back issue text the model will read as instruction, so I label that content as external provenance and clamp what the agent may do for the rest of the turn. Egress: its tools take arguments the model fills from context, so I bound those arguments and give the integration only the scopes it needs - it never gets handed a whole file or a secret to pass along. And I'd treat the server as an untrusted, pinned dependency, because a version bump can change what its tools do."