AI Agents Need Boundaries, Not Master Keys
Giving an AI agent access to your app via MCP is risky. You are handing over a keyring and hoping they only open certain doors. That trust is a security risk.
When building MCP tools for a multi-tenant Laravel app, you must solve one problem: how to let an agent drive the app without accessing someone else's data.
Each MCP tool acts as an endpoint. An agent calls a tool, and your server runs code. In a multi-tenant setup, every tool must answer two questions:
- Are you allowed to do this?
- Are you allowed to do it here?
If you skip these, you create a security hole.
Web requests use sessions to handle multi-tenancy. MCP tools use tokens. There is no session and no middleware to set a current tenant context. If you rely on global scopes that look for a "current org" in a session, they will find nothing. A query that should be restricted might return every row in your database.
I use these four rules to stay safe:
- Explicit filtering: Never rely on ambient scope under token auth. Use a single trait to filter by organization every time.
- Use UUIDs: Never use auto-increment IDs. Use unguessable identifiers so agents cannot guess other records.
- Reuse permissions: Do not create new permission sets for agents. Use the same ability strings your web app uses.
- Mark side effects: Use annotations to label tools as read-only or write-enabled.
By using a single trait for organization lookups, you create one place to audit. If the lookup returns null, the tool tells the agent the record is not found. The agent gets no information about other tenants.
This is not an AI problem. It is a multi-tenancy and authorization problem. MCP makes it easy to expose your app, so you must be disciplined about your boundaries.
An agent should do exactly what the human can do, within their own tenant, and nothing more.
Optional learning community: https://t.me/GyaanSetuAi