Much of my recent work connects AI agents to products that already hold real data. In my experience the first question a client asks is rarely which model. It is what the agent will be able to touch.
These are the habits I build in. The examples come from PREKIT, the industrial data platform where I built the AI assistant and the MCP server from the start, inside Alpamayo's engineering team. The short version is on my home page, and the screens are in the Alpamayo case study.
1. Sign in before any tool runs
An agent that calls your tools is a client like any other, so it should sign in like one. PREKIT's MCP server sits behind OAuth 2.1 with dynamic client registration and OpenID on Keycloak. The agent registers as a client, the person signs in, and the server knows who is asking.
The shortcut I see most often is a long-lived API key pasted into a config file or a prompt. It cannot tell people apart, it rarely expires, and nobody remembers where it was copied.
2. Read-only by default
The PREKIT assistant works through read-only MCP tools. It reads live alarms and the data behind them, and when a request needs a change it says plainly that the change is outside what it may do.
Writes are where an agent can do damage, so I add them one at a time and on purpose. A write tool gets a narrow job, a check on who may use it, and a step where a person confirms what is about to happen.
3. Keep the model behind a proxy
The assistant reaches its language model through an AI proxy and answers from what the read-only MCP tools return. A proxy gives you one place for provider keys, one place to log requests, and one place to switch providers without touching the product.
4. Plan, then act, on the record
PREKIT's first assistant plans its tool calls, refines the plan, then runs it, and the chat history is stored. A stored plan and conversation let you see afterwards why the agent did what it did, which is most of what you need when something looks wrong.
5. Choose the model to fit the data
The agent harness I build runs on OpenAI, Anthropic or open models such as Qwen. That choice belongs to the client. Some data can go to a hosted provider under the right agreement; some should stay with an open model on infrastructure the client controls.
What I check before an agent ships
- Every tool call carries the person's identity, and the tool filters data by it on the server. The model never decides whose data it sees.
- Text that comes back from tools is data. Alarm descriptions, tag names and customer messages can all contain instructions, and none of them gets to change what the agent may do.
- Every call leaves a line in an audit log: who, which tool, allowed or refused, and why.
- Each person has a limit on how often they can call each tool, so a runaway loop stays cheap.
- A refusal comes with a message the agent can pass on, so people know what to do next.
You can read these checks in code in mcp-guarded-server, a small open-source sample server with tests. It is a teaching sample with demo data.
These are checks I bring to each project. If your product holds data you care about and you want an agent on top of it, let's talk.
Top comments (0)