In this piece
Vendo for SaaS: Tenant Isolation and Approval Boundaries
Evidence: Documentation reviewed on 8 October 2026. This is a researched implementation guide. The pilot below is proposed; we have not run these vendor evaluations or measured their performance.
What must a SaaS team still own after adding Vendo?
Your backend remains responsible for deciding which records the signed-in user can read or change. Generated screens, a sandbox and an approval card do not replace authorization in your API. Start with a customer-specific dashboard whose tools already enforce tenant scope. Expand to actions only after that boundary passes independent checks.
The relevant product is Vendo at vendo.run, the customization layer maintained in the official runvendo repository. It adds agent-driven features and micro-apps to an existing product. Other companies named Vendo are unrelated to this guide.
How should identity and tenant access work?
The Vendo authentication documentation resolves the host's existing identity and recommends an immutable subject. Its no-auth example assigns every visitor the same demo user. That example is unsuitable for a multi-tenant production integration.
Use one trusted server-side session resolver for Vendo and host routes. Resolve organization membership from the backend, then check it in every tool that reads or writes business data. Never treat an organization identifier supplied by the model as proof of access. Users who belong to two organizations still need an explicit active-organization boundary.
What should a two-tenant pilot prove?
Create synthetic organizations A and B. Give each an administrator and a read-only member. Both have an invoice with the same local number but different internal identifiers. Propose a generated “overdue invoices” view and a reminder action. The following cases are acceptance targets, not observed Vendo results.
| Attempt | Required outcome | Independent check |
|---|---|---|
| A requests B's invoice ID | Denied without leaking invoice fields | Host API response and access log |
| A changes active organization | Only the newly authorized context is visible | Re-query records and reopen the saved app |
| Read-only member sends a reminder | Blocked unless the role explicitly permits it | Delivery ledger stays unchanged |
| Administrator loses the role after approval | Permission is checked again before execution | No external send after revocation |
| Two workers resume the same approved action | One logical side effect | Durable operation key and delivery ledger |
| Process restarts | Authorized state survives; expired grants do not revive | Store contents and replayed action |
Run the read tests directly against host tools as well as through generated UI. A UI that hides a button is not an access-control test.
Does Vendo ask before every write?
No. The approval guide documents a default posture where reads and writes run, while destructive and ungraded calls ask. Define explicit policies for sensitive writes such as sending messages or changing billing data. A business-critical write can require approval even when its technical risk label is not destructive.
The same guide distinguishes in-app resumption from the MCP path: outside agents must call again on the same MCP session after approval. Test both entry points if your customers use both. Bind approval to the intended action and recheck permissions at execution; approval is not an authorization bypass.
What must survive a restart?
The persistence documentation describes Vendo Cloud storage for threads, apps, grants, approvals, audit and runs. Persistence is a capability, not proof that a host-side write is exactly once. Keep a durable business-operation ledger with tenant, actor, approved arguments, operation key and reconciled outcome.
On uncertain external outcomes, inspect the destination before retrying. If a reminder was delivered but the process died before saving the response, starting a new operation can send it twice. Test a crash between the external side effect and the local acknowledgement.
Is passing vendo doctor enough for production?
No. The production checklist explicitly says doctor reads source and environment without calling the deployed app. Use it to detect wiring problems, then test the live staging deployment for identity, streaming, verified webhooks, approvals and restart behavior. Cloud fills some infrastructure slots; the host still wires several security and request boundaries.
When is Vendo a good fit?
Pilot it when customers need different views or bounded workflows over an API you can authorize reliably. A bespoke copilot may be simpler when there is one fixed task and no need for user-built apps. Assign maintenance ownership for tool schemas, saved features and incident recovery before expanding. Bring one feature and its permission matrix to scope a SaaS agent integration.
Related implementation guidance
Enterprise MCP Authorization Architecture: A Multi-Tenant Reference Design. AgentMail for SaaS: Tenant Isolation and Duplicate-Send Recovery.
Sources checked
Independence and trademarks: Wavect publishes this page and is itself a provider, so we have a commercial interest in it. We are not affiliated with, endorsed by or partnered with the other companies named here, and all third-party company names, brands and trademarks are the property of their respective owners. Statements about other providers are taken from publicly available sources, primarily their own published pages, as of the review date shown on this page, and may have changed since. Please verify them directly before you decide. This page was written to the best of our knowledge and with the intent to remain objective. If you believe anything here is inaccurate or unfair, write to us and we will correct it: [email protected]