What giving an AI real access to my computer taught me
# What giving an AI real access to my computer taught me
A few months back I connected an AI model to the tools I actually use. My files, my messaging apps, my calendar, and the servers I run. I described what it was allowed to do, then let it act on its own. Most days the arrangement is more useful than any chat window has ever been. One moment along the way forced a full rethink of the setup, and that moment shaped every rule described below.
MCP, in plain words
The piece that makes any of this possible carries a dull name: the model context protocol, or MCP. It is quietly becoming the standard way to hand a model real tools, so the dull name is worth learning.
A plain chatbot produces text and stops there. MCP gives the same model a published list of tools it may call, where each tool is one small described action. Send a message. Read a file. Search my notes. Check the calendar. The model reads each description, decides which action fits the request, and calls it. Before this protocol existed, every such connection was a custom one off hack. After it, tools speak one shared language and simply plug in.
The analogy I keep returning to is a brilliant new hire on their first morning. Sharp as anything, and useless until someone shows them where things live and hands over keys. MCP is the labeled key ring. This one opens the filing cabinet, this one sends the mail, this one checks the schedule. Capability was always there. The keys turn it into work. And exactly as with a real hire, deciding which keys to hand over, and which stay on your own ring, is the decision that outweighs all others.
Deliberately boring demos
The examples I lean on are boring on purpose, because boring is where a setup like this earns its keep.
In plain English I can ask for the message someone sent last week about a delivery, and get back what it actually said, pulled from the right app. I can ask for the three files I edited yesterday and a summary of where I left off. I can ask whether an overnight job on one of my servers finished, and the agent goes and looks rather than telling me how to check.
None of that is flashy. The gap between a model that explains how to do something and one that goes and does it is enormous the first time you feel it. The thing stops being consulted and starts working alongside you.
The chaining is the real shift
Single tools are handy. The genuine shift arrives when several chain together from one request, with no scripting from me.
A real example: check whether last night's job finished on the server, and if it failed, find the error in the logs and send me a short summary in my messaging app. Three tools, two systems, one plain sentence. The agent checked the server, read the log, decided what mattered, and delivered the answer where I would actually see it. No glue code connected those steps. The model worked out the order on its own from the tool descriptions available to it, and it usually gets that order right.
That composition, small abilities assembled into something never explicitly spelled out, is the part that genuinely surprised me.
What is actually happening underneath
Two pieces make up the machinery. The client is the AI side, the model plus the app it runs in. A server is a small program that exposes tools, one that knows how to talk to my messages, another for my files. Each server publishes its tool list with a description and the inputs each tool expects. When the model decides a tool fits, it sends a structured request, the server performs the real action, and the result flows back.
The detail worth sitting with: the model can only ever do what some tool explicitly offers. Nothing reaches into the machine by magic. Which means the whole question of what an agent can do to your computer reduces to a single decision, namely which tools you connected. Safety talk about agents is really tool talk wearing a costume.
The moment that changed my setup
Early on, while testing, the agent held fairly broad access, including the ability to send messages rather than only read them. I asked for something innocent, a drafted reply to someone, and my wording was sloppy. Draft and wait is what I meant. Draft and wait is what I failed to say.
For a second or two I watched it move to send a message, on my behalf, to a real person, before I had read a word of it. I caught it in time and nothing went out. It still landed hard. The agent had followed its setup precisely, at machine speed, off the back of one imprecise sentence from me. No malice, no malfunction. The risk in the room was a sharp tool, a vague instruction, and my own assumption that it would read my intent instead of my words.
Since then I think of it as a power tool. Genuinely useful, holding no grudge, and completely willing to cut whatever gets put in front of the blade. Every guardrail below exists because of that one near miss.
The read line and the write line
The rules that came out of it are simple. Reading is nearly always allowed. The agent can search files, read messages, check the calendar, and scan logs all day long, because the worst case is that it sees something and tells me about it.
Writing is a different country. Anything that changes the world beyond my machine, a message to a real person, a public post, a deleted file, money moving anywhere, stops and waits for my explicit approval, every single time.
Some things stay disconnected entirely. Passwords. Anything financial. The ability to spend. Convenience does not enter into it. The rule fits in one sentence: reading is free, and acting on the outside world requires a human yes first.
Guardrails, concretely
Approval gates come first. Any tool that writes has to stop and show me the exact action before performing it, and I read what it is about to do, verbatim.
Scoping comes second. A tool gets the least access that still does the job. Something meant to read one folder has no business seeing the whole drive.
Logging covers the rest. Every action the agent takes gets written down, so anything odd can be traced back to exactly what happened and when. And every new tool starts read only. It looks first, and it earns the ability to act later, once trust is warranted.
None of this is clever. These are the boring principles careful systems have always used. An agent moving at machine speed is precisely where boring belongs.
Three mistakes worth avoiding
The first mistake is asking the backwards question. What can this agent do for me feels natural. What am I allowing it to do to my stuff is the version that protects you, and the two produce very different setups.
The second is connecting tools you cannot describe. If you cannot state plainly what a tool can touch and what it cannot, handing it to an autonomous agent is premature.
The third I learned personally: vagueness. An agent with real tools takes words literally and acts fast, so a sloppy sentence has stopped being a small thing. It is an action waiting to happen. The fix for all three is the same. Slow down, know the reach of each tool, say precisely what you mean. A very fast new hire will do exactly what you said, including the parts you did not quite mean.
Whether you should wire this up
For most people, my honest answer right now is: wait. The capability is real, the ecosystem is early, and the safety defaults are still catching up to the power. Today the main barrier between a vague instruction and a real action is you.
For the technical reader willing to set up access carefully, this is among the most useful things I run, and it feels like a preview of how a lot of work will soon happen. Start read only, on data that does not matter. The people who get burned are the ones granting broad write access on day one because a video made it look easy. Power gets added one careful step at a time, or the near miss finds you before the habit does.
An agent like this is a fast, literal assistant bounded entirely by the tools behind it. Keep reading open, gate every real action behind your own yes, and the rest is just adding keys to the ring. More honest looks at building with AI, caveats included, live at [xavierfok.com](/).
Get new guides and videos first — join the Telegram channel.