How to Do MCP Security Right, Part 4: Adding Context

In case you missed the earlier parts:

Part 1 — Why MCP Needs Stronger Security

Part 2 — A Simple, Hands-On Example

Part 3 — Integrating Human & Non-Human Identity

Context:  Beyond identity

There are many cases where one would want to use contextual information to restrict access rights within an agentic system.  In this article, I will explain a simple example case.

The basic idea

Once an agent has accessed sensitive data, it shouldn’t be allowed to access the internet. We mark the biscuit token to reflect that fact, and any internet-capable tool refuses to run while the token is “tainted.”

Why track whether the agent has accessed sensitive data?

Because once an agent touches sensitive data, that data tends to stick around in working memory—prompt context, tool arguments, scratch variables, even logs. LLMs also remix recent context when composing new outputs and requests. Together, that turns any subsequent internet-capable call into a potential exfiltration path, even when the call looks harmless.

Concretely, sensitive bits can leak via:

• Query strings & URLs: auto-appended identifiers (e.g., ?patient=Erin+Ortega&A=118).
• Headers & metadata: “helpful” custom headers or auth fields reflecting prior results.
• Bodies & payloads: JSON/POST requests that serialize prior context for “better results.”
• Side channels: DNS names, SNI, timing, referrers, proxies, and caches.

So the rule is simple and defensible: if the agent has accessed sensitive data, it can’t talk to the internet until that risk is cleared (expiry, re-auth, manual approval, or a de-taint workflow). That’s exactly what the taint mark (sensitive_data = 1) enforces here—context-aware, order-sensitive containment that closes off exfiltration routes after sensitive access.

How we enforce it: a tiny mark with big impact

When the database returns sensitive results, the MCP server adds an attenuation block to the biscuit—think of it as stamping the token with sensitive_data = 1. From then on, any internet-capable tool checks the token and follows one rule:

If sensitive_data == 1, reject the request.

No central session store, no guesswork—just a cryptographically signed, portable fact that travels with the token and is easy for downstream services to enforce.

Attenuation lets you evolve context without a central authority, preserving a verifiable chain of custody.

A second MCP server to make it obvious

To make this policy visible, the repo adds a tiny HIPAA info MCP server that fetches public HIPAA documentation from the web. It’s intentionally simple, but it proves the point: because a fetch can also send data out, it refuses tainted tokens.

Two short workflows (order matters)

Safe order: public → sensitive

1. Agent fetches the HIPAA document (internet) → Allowed (token is clean).
2. Agent then queries patient data (DB/RLS) → Allowed; token becomes tainted after this.

Unsafe order: sensitive → public

1. Agent reads patient data → Allowed; token becomes tainted.
2. Agent then tries to fetch the HIPAA document → Blocked (token says sensitive_data = 1).

That’s it—you’ve just seen context- and sequence-aware safety in action.

Try it quickly

• GitHub repo with code & instructions: https://github.com/esweiss/MCP-biscuit-PoC
• Run demo_magic_security.py for the complete runthrough.

What’s coming next (your input wanted!)

What would be most useful to you next? A few suggestions—tell me which you’d like to see:

• Cool-down timers / approvals (temporary quarantine or explicit de-taint workflows).
• Propagation across agents/tools (ensure taint is honored end-to-end).
• Signed audit events (ledger entries for each attenuation and denial).
• Start looking into how to handle complex policies.