AI APIs and MCP Services
AI APIs and MCP services should be treated as external capabilities with explicit data boundaries, server-side credentials, minimum tool permissions, budgets, audit logs, and human approval for consequential actions.
What You Will Be Able to Decide
- Explain the role of ai apis and mcp services in a self-hosted system.
- Apply the procedure to a real open-source deployment.
- Recognise unsafe defaults and verify the resulting control.
- Record enough evidence for another operator to repeat or recover the work.
A self-hosted application can keep its primary data and workflow under your control while still calling an external model API. That is a hybrid architecture, not a contradiction.
The Model Context Protocol gives AI clients a standard way to discover and invoke tools or retrieve resources. Standardisation improves interoperability, but it also makes authorisation and tool boundaries more important.
An AI credential should never be shipped to the browser merely because the interface needs AI. Requests should pass through a controlled server component that can validate the user, restrict the operation, redact data, and enforce cost limits.
Technical term
MCP server
A service that exposes named tools, resources, or prompts to an MCP-compatible client through a standard protocol.
It is a universal tool cabinet: compatible assistants can see labelled tools, but the lock and permission policy still decide who may use each one.
The Working Model
Separate model inference from application authority. The model can propose an action, but the server should validate parameters, check the authenticated user's permission, and require approval for irreversible or high-impact work.
For remote MCP, follow the current protocol authorisation specification and the server's implementation guidance. Use OAuth-style delegated access where supported, validate tokens for the intended resource, and do not pass unrelated upstream tokens through the model.
Record the provider, model, region, retention terms, data categories, token budget, rate limits, and failure behaviour. A private application can still leak information if prompts contain secrets or if an overly broad tool can read an entire production system.
Implementation Procedure
- Draw the data path from user input through the application, model provider, MCP client, MCP server, and target system.
- Keep provider and MCP credentials on the server and create separate values for each environment.
- Expose the smallest tool surface and validate every tool argument independently of the model.
- Add per-user authorisation, timeouts, rate limits, spending limits, redaction, and structured audit events.
- Test prompt injection, unauthorised tool calls, provider failure, excessive usage, and human rejection of a proposed action.
AI_PROVIDER_API_KEY=
MCP_SERVER_URL=https://mcp.example.com
MCP_AUDIENCE=https://mcp.example.com
AI_MONTHLY_BUDGET_USD=50
AI_REQUIRE_APPROVAL_FOR_WRITES=trueControlled Practice and Fragile Practice
Verification and Recovery Evidence
- A user cannot invoke a tool against records they cannot access in the normal application.
- Provider keys are absent from client bundles and model-visible context.
- Budgets, timeouts, and failure responses prevent an AI dependency from exhausting the application.
Warning Signs
- The model receives a system-wide administrator token.
- MCP tools accept free-form commands without schema validation.
- No one can say which customer data leaves the self-hosted boundary.
Questions to Ask a Consultant
- Which data crosses the boundary and under which provider terms?
- Can the model propose an action without gaining authority to perform it?
- What limits contain cost, latency, and provider failure?
Key takeaway
Key Takeaway
AI integration is safe when intelligence and authority are separated. Keep credentials server-side, minimise tools and data, enforce real permissions, and preserve human control.