Architecture decision
Apply least privilege to MCP at four layers: identity, resource, tool, and action. Authenticate each user, issue audience-bound and short-lived tokens, authorize the specific workspace and records, expose only necessary tools, validate every argument server-side, and require approval for consequential writes.
MCP makes an AI client useful because it can see context and invoke tools. Those same capabilities turn an overbroad connection into a high-value attack path.
Security must live in the server and authorization layer. A system prompt asking the model to behave is not an access-control mechanism.
Design requirements
01A four-layer scope model.
02OAuth and token boundaries.
03Prompt-injection containment.
04A pre-production test matrix.
Scope four independent layers
| Layer | Question | Example restriction |
|---|---|---|
| Identity | Who is acting? | Named user, not shared service identity |
| Resource | Where may they act? | One team workspace and selected campaigns |
| Tool | What capability is exposed? | Read conversations but not delete them |
| Action | Under what conditions? | Draft automatically, send only after approval |
Treat tokens as capabilities
- Use the documented authorization flow and validated redirect URIs.
- Bind access tokens to the intended resource server and audience.
- Keep lifetimes short and support revocation.
- Do not pass tokens through prompts, model context, URLs, or logs.
- Reject tokens issued for another service even if the signature is valid.
Assume retrieved content can be hostile
A Telegram message, profile field, website, or attached document can contain instructions aimed at the model. Label external content as data, separate it from policy, and never let it expand permissions or select hidden tools.
The confused-deputy problem
An authorized agent can still be tricked into using its legitimate permissions for the wrong party. Reconfirm the user, target, and intent at the action boundary.
Validate every tool call
- Strict schemas with bounded strings, arrays, and enumerations.
- Workspace and record authorization rechecked on every call.
- Server-calculated ownership fields.
- Rate and volume ceilings independent of model output.
- Idempotency keys for writes.
- Structured, redacted audit events.
Test abuse cases
| Test | Expected result |
|---|---|
| Cross-workspace record ID | Denied without information leakage |
| Token for another audience | Rejected |
| Prompt asks for hidden tool | Tool remains unavailable |
| External content requests secret | No disclosure or privileged call |
| Repeated write | Idempotent result |
| Revoked user | Active session loses access promptly |
Research note
This guide draws on the MCP authorization and client-security specifications, OAuth security best current practice, and OWASP secrets guidance. Follow the exact version implemented by your client and server.
Build the safe path first
MCP security becomes manageable when permissions are explicit and independently enforced. Give the model enough context to help, never enough ambient authority to improvise outside the user's intent.
Connect AI clients with narrower, auditable access
TeleBoost's hosted MCP server is part of a broader Telegram CRM with team isolation, scoped access, API, webhooks, and human-owned workflows.
Continue the operating system