Design study · Personal environment
What should an agent be allowed to reach?
An MCP security review, starting with the tools already within reach.
My AI assistant could connect to tools with very different consequences: reading public information, reaching private data, or taking an action in an account. Treating all of that as a single category called “tools” hid the decisions I needed to make.
I reviewed the connected Model Context Protocol tooling, mapped its trust boundaries, and designed a more restrictive outbound-access model.
- My part
- Inventory, trust-zone analysis and control design
- Evidence boundary
- Design and audit findings; not a deployed enforcement layer
The problem
A connector's presence does not tell you whether it is authenticated, what data it can read, or where that data can go. An inventory that records only product names is too shallow to answer an access question.
I separated what was available from what was active, then classified the tools by capability and data destination. That made it possible to ask whether a connection was needed before spending effort hardening it.
The decisions
- Classify access by consequence
- Reading a public reference is different from accessing a private account or sending information out of it. I used those differences to draw trust zones instead of treating every connector as interchangeable.
- Remove unnecessary access before adding controls
- An unused capability does not need an elaborate security story. Leaving it disabled is the simpler boundary. Enabling it should be a deliberate change, not a side effect of having installed it.
- Put outbound restrictions outside the model
- The proposed design used an explicit outbound proxy and destination allowlist, with process isolation to prevent bypass. A model instruction alone cannot enforce where a process connects.
- Keep the plan separate from the test result
- Scanner selection and a vulnerability-monitoring path were part of the work. Selecting those tools did not establish that a scan had run or that monitoring was active.
What the review produced
The output was a capability inventory, a trust-zone classification, and a proposed deny-by-default egress model. It replaced a vague question about whether an assistant was “secure” with concrete questions about access and enforcement.
“Available” and “active” are not the same word.
The design also made the next verification work explicit: an allowed destination must be reachable, a prohibited destination must fail, and a process must not be able to bypass the boundary. Those are acceptance conditions for implementation, not results claimed by this review.
What it does not prove
This is a personal-environment design study, not a client engagement, penetration-test certificate, or claim that the proposed proxy and isolation controls are deployed. The private inventory and account connections are intentionally not reproduced.
It demonstrates how I scope an agent's access and distinguish a security plan from working protection. The broader practice is described in my approach to AI.