There is a moment, when you decide to open your SaaS to AI agents over MCP, where the ground shifts under two of your oldest assumptions at once.
The first assumption is that your data stays inside your walls. With MCP, the result of any tool call passes once through the user's chat screen — which means it passes through an external AI vendor's processing infrastructure on the way to the user. That is data sovereignty, and for finance, healthcare, audit, and HR it has historically been the reason to keep everything inside a built-in dashboard.
The second assumption is that the only actor writing to your system is a person you authenticated, or your own code. Open over MCP and an external agent becomes a write-capable actor on someone's behalf. The agent reads instructions from its context window, and that context can be poisoned. OWASP lists prompt injection as the number-one AI-related security risk for a reason: a quiet malicious instruction can steer a model into operations it should never perform.
Both of those sound like reasons not to open up. They are not. They are reasons to design the server side so that opening up is safe by construction. The whole game is to hold the reins on the server side, so that no matter what the external AI decides, it can only move inside the range you permitted.
This article is about the three reins, plus the tool design that makes them work.
The shift in one sentence
When you wrap your product as an MCP server, you stop deciding what happens. The user's AI client decides what to attempt. You decide what is allowed to succeed.
That single reframe is the difference between a safe MCP surface and a dangerous one. If your security model assumes the caller is well-behaved, you have lost. If your security model assumes the caller will try anything and your server is the thing that says no, you are in good shape.
The good news, and the reason the industry's walls are coming down, is that you mostly already have the machinery. The permission systems SaaS teams spent a decade building to keep one human user out of another human user's data are exactly the systems that govern an AI agent acting on that user's behalf. You are not inventing authorization. You are pointing existing authorization at a new kind of caller.
Rein 1: scope every call to the logged-in user's permissions
The first and most important rein is narrow access. An agent acting for a user must be able to do exactly what that user can do, and nothing more.
This is precisely the posture the Japanese accounting leaders took. When Money Forward and freee published MCP servers in March 2026 — in accounting, the dead center of finance — both bound the agent's operating range to within the logged-in user's permissions. freee states it plainly: no operation beyond the logged-in user's permissions is performed. The agent is not handed unlimited platform authority. It is handed exactly the slice of authority the human already had.
The practical mistake to avoid is the "service account" trap. It is tempting to back your MCP server with a single high-privilege credential and let the server "figure out" who the request is for. That credential becomes a master key that a prompt injection can aim anywhere.
Instead, resolve identity on every call and filter every query by the authenticated user:
// Every tool handler receives a verified user identity from the
// authentication layer (e.g. OAuth 2.1 token -> user id). It is never
// trusted from the model's arguments.
async function getResponses(userId: string, formId: string) {
// Ownership/role check first. "Not found" and "not allowed" return
// the same shape so a probing agent cannot enumerate valid ids.
const access = await checkFormAccess(formId, userId, { requiredRole: "viewer" });
if (!access.ok) return notFound();
// Even with a service-role DB client, scope the query explicitly.
return db.responses
.where("form_id", formId)
.where("user_id", userId); // the rein: no row outside the user's reach
}
Two details matter here. First, the user identity comes from the authentication layer, not from a tool argument the model supplies — a model can be talked into passing user_id: "someone_else", so that field must never be load-bearing. Second, do not distinguish "this resource does not exist" from "you may not see this resource." Returning different errors lets a poisoned agent map your id space.
If your MCP tools run with an admin/service-role database client that bypasses row-level security, this scoping is your only defense line. That is the situation in FORMLOVA: every MCP tool runs with a service-role client, so the application layer must perform the ownership check on each call. The rein is not "trust RLS"; the rein is "filter by the user on every query, every time."
Auth0's launch of a dedicated authentication feature for MCP on May 6, 2026 is the same idea moving into shared infrastructure. Rather than each SaaS hand-rolling identity and permission checks for agent callers, the identity and scope of an agent reaching your tools can be guaranteed with an industry-standard mechanism. That is the first rein becoming a commodity.
Rein 2: multi-step approval for sensitive operations
The second rein is that not every operation should execute the instant a model asks for it.
Reads are cheap to be wrong about. A misguided read returns data the user could already see. But some operations are externally irreversible — sending a bulk email, deleting a record, removing a team member, publishing something to the public. If an MCP client tells a model "you may call any tool," and a prompt injection convinces it to call the bulk-send tool, the cost of being wrong is real money and real trust.
The fix is to make irreversible operations require a fresh, server-issued approval token that the model cannot forge. The server only issues the token after the right summary has been shown to the user and the user has explicitly approved.
A useful way to organize this is to classify every tool by blast radius and attach the gate to the dangerous tiers:
L0 read-only execute immediately
L1 reversible write execute immediately (version history covers rollback)
L2 user/public-facing server-side review state machine
L3 externally final HMAC-signed confirmation token required
In FORMLOVA the externally-final tools and the publish flow all require a confirmation token signed with HMAC-SHA256 and valid for only a few minutes. The shape of the gate is what matters:
function issueConfirmationToken(userId: string, action: string, args: unknown) {
const payload = `${userId}:${action}:${hash(args)}:${Date.now()}`;
return hmacSign(payload, SERVER_SECRET); // bound to user, action, args, time
}
async function sendBulkEmail(ctx, args) {
if (!args.confirmation_token) {
// First call: do NOT send. Return a summary the user must approve:
// recipient count, subject, first lines, sender. Then issue a token.
return needsApproval({
summary: summarize(args),
confirmation_token: issueConfirmationToken(ctx.userId, "send_bulk_email", args),
});
}
// Second call: verify the token is valid, unexpired, and matches THIS user/action/args.
if (!verifyToken(args.confirmation_token, ctx.userId, "send_bulk_email", args)) {
return rejected("stale or invalid approval");
}
return actuallySend(args);
}
The token binds to the user, the action, the arguments, and a timestamp. A model cannot bluff past the gate by claiming it already confirmed, because there is no valid token in its possession until the server mints one after a real approval. If the arguments change between the summary and the send, the token no longer matches and the call is rejected. Even a model that misreads its own instructions cannot escalate, because the gate lives on the server, not in the prompt.
This is the same principle behind ServiceNow's Action Fabric, which routes every external-agent action through identity verification, permission narrowing, operation logging, and approval chains. ServiceNow opened its entire system to external agents over MCP and, in the same motion, placed every action from outside under watch. Openness and control are not a trade-off when the control sits on the server.
Rein 3: a verifiable log of every call
The third rein is that you must be able to answer, after the fact, exactly what the agent did.
When the caller is an external AI, "I trust the integration" is not an audit position. You need a durable, tamper-evident record of who called which tool, with what arguments, on whose behalf, and what the result was. This is what makes prompt injection survivable rather than catastrophic: even if an attacker slips one bad instruction through, you can see it, scope the damage, and prove what happened.
A workable audit record for an agent-driven write looks like this:
type AuditEntry = {
at: string; // ISO timestamp
userId: string; // the human on whose behalf the agent acted
actorType: "agent" | "human" | "automation";
tool: string; // e.g. "delete_response"
argsHash: string; // hash of arguments, not raw PII
approvalTokenId?: string; // ties the action to a specific approval
result: "ok" | "rejected" | "error";
reason?: string; // why a rejection happened
};
Log the approval token id alongside L3 actions so that every irreversible operation is provably tied to a specific user approval. Hash arguments rather than storing raw personal data, so the audit trail itself does not become a privacy liability. Make the log queryable by the operator from inside the same product — for FORMLOVA that means audit entries are readable both from the dashboard and over the MCP surface, so the same agent that did the work can also be asked to account for it.
The three reins compose. Scope decides what is reachable. Approval decides what can fire. Logging decides what you can prove. Each is a familiar SaaS discipline; the only new thing is pointing all three at an external AI caller.
The fourth piece: design tools around intent, not endpoints
Reins keep the agent inside the fence. Tool design decides whether the agent does the right thing inside it — and, surprisingly, it is also a security property.
The early instinct is to wrap each existing API endpoint as one MCP tool. It does not work well. A model staring at a flat list of low-level verbs has to assemble multi-step plans itself, and every extra hop it improvises is another place a wrong turn — or an injected instruction — can do damage. Stripe, and Block with its 60-plus MCP servers, have published the same lesson: reorganize functions around the user's goal so the agent can accomplish a real task in as few, as well-bounded, calls as possible.
A goal-shaped tool is safer because it is opinionated. "Reply to this respondent" can bake in the quota check, the suppression-list check, the approval gate, and the status transition as one server-controlled unit. The model does not get to skip a step, because the steps are not its to skip. Compare that to handing the model raw "fetch contact," "compose," "send," "update status" verbs and hoping it sequences them correctly under adversarial input.
FORMLOVA organizes its 129 tools into 25 categories precisely so the agent reasons about goals — forms, responses, analytics, response-management, scheduling — rather than guessing at a flat surface of verbs. Fewer degrees of freedom for the model means fewer degrees of freedom for an attacker.
This is why the pillar argument holds: when the reins design and the tool design click together, MCP works both safely and usably. They are not separate projects. The tool that expresses the user's intent is the same tool that is easy to bound, approve, and log.
What the reins do not solve
Honesty matters more than a clean ending.
The reins do not solve the contractual case where data may not pass through a specific AI vendor's infrastructure at all. No amount of server-side scoping changes the fact that the narrowed result still travels through the external AI on the way to the user. Some medical data, some state-secret-adjacent data, and data under specific geographic sovereignty rules sit here. That is an institutional problem — approving particular AIs, or controlling where processing happens — and it will take years and standards, not a clever handler, to settle.
The reins also do not make prompt injection disappear. They make it containable. An injected instruction still arrives in the model's context; what the server guarantees is that the instruction cannot reach beyond the user's permissions, cannot fire an irreversible action without a fresh approval, and cannot escape the log. Containment, not immunity, is the realistic target.
And the reins do not replace the rest of your security program. Rate limits, input validation, secret management, and dependency hygiene all still apply. The agent is a new caller, not a new universe.
A short checklist
If you take five things from this article, take these:
1. Resolve user identity from the auth layer, never from a tool argument.
2. Filter every query by the authenticated user, even with an admin DB client.
3. Gate externally-irreversible tools behind a fresh, server-signed approval token.
4. Bind that token to user + action + arguments + time, with a short TTL.
5. Log every agent call verifiably: who, on whose behalf, which tool, what result.
If you can do four more:
6. Classify every tool by blast radius (L0..L3) and attach controls per tier.
7. Make "not found" and "not allowed" return the same shape to stop id probing.
8. Design tools around user goals, not raw endpoints, to shrink the model's freedom.
9. Treat containment, not immunity, as the prompt-injection target — and prove it with logs.
None of these is exotic. Together they are the difference between opening your SaaS to AI agents and losing control of it, versus opening it and keeping the reins firmly in your own hands.
The largest SaaS companies, the most regulated banks, and the two accounting leaders all reached the same conclusion in roughly a year: you can open over MCP and still hold control, as long as the control sits on the server side. That is the design that brought the walls down.
If you want the wider story of why SaaS is being called rather than chosen, and why this reins design is what made the shift possible, I wrote it here: SaaS Is Moving from Chosen to Called.
FORMLOVA is a chat-first form service whose entry point is an MCP server, available from MCP-capable AI clients such as Claude, ChatGPT, Gemini, Cursor, and Windsurf.
