--- title: Keep customer access isolated in your eve agent description: Review an eve app’s session and service boundaries, then test that one customer cannot read another customer’s conversations or data. url: "https://vercel.com/kb/prompts/isolate-eve-customer-access" last_updated: 2026-11-07 related_resources: "[eve authentication](https://eve.dev/docs/guides/auth-and-route-protection)": "Protect inbound agent routes and distinguish route access from service credentials." "[Multi-tenant outbound authentication](https://eve.dev/docs/patterns/multi-tenant-auth)": "Resolve service credentials from verified customer membership." "[eve connections](https://eve.dev/docs/connections)": "Choose connection credentials, tool filters, and account identity." --- # Keep customer access isolated in your eve agent Review an eve app’s session and service boundaries, then test that one customer cannot read another customer’s conversations or data. Check customer isolation in an existing eve application. This prompt follows a request from inbound authentication through session access to the credentials used by an external service. Open or import the project and provide the intended tenant-membership rules plus two synthetic customer accounts. The handoff includes the prompt, without your repository, identity-provider setup, or service secrets. Expect focused fixes and tests for cross-customer access, organization switching, and failure recovery. This is a bounded review of the chosen agent routes and connections; it does not certify every service or replace a wider security assessment. ## Agent prompt ```text Review and strengthen customer isolation for one existing eve agent's session routes and outbound service access. If the intended repository is unavailable, ask me to open or import it first. Read repository instructions and inspect the installed eve version, channels, inbound authentication, session storage, connections, and tests. Reuse the identity provider, tenant-membership store, package manager, and credential integration. Ask how users belong to or switch organizations if unclear. Do not migrate the authentication stack or change production membership data for this task. Consult the current documentation at https://eve.dev/docs and compare it with the installed eve version. Inspect the relevant package source, exported types, and examples before choosing APIs; resolve discrepancies rather than guessing or upgrading automatically. Trace the verified user and selected tenant from request authentication into the current turn. Derive membership from trusted server-side checks, never prompt text, model arguments, or an unverified header. Require authentication before model work and preserve fail-closed behavior when configuration or membership lookup fails. Check the effective production auth policy rather than relying on a local development identity. Keep test-stub and operator capabilities unavailable to ordinary users. Route authentication alone does not establish session ownership. Verify ownership and tenant access on session creation, continuation, streaming, cancellation, and other exposed session operations. Exercise direct requests instead of assuming the UI enforces these checks. For a user switching organizations, define whether the existing conversation remains bound to its original tenant or must be replaced; prevent old history from becoming visible under a different scope. Preserve existing persistence and memory boundaries and call out any unresolved cross-tenant storage path. Inspect each in-scope tool or connection's credential resolution. Select the credential from the verified current tenant and user, and reject missing or revoked membership before accessing the service. Do not fall back to a shared privileged token. For authenticated dynamic connections, use the installed version's stable, non-secret account or tenant identity and check token and discovery-cache separation, including when one user belongs to two organizations. Keep secrets out of model input, results, logs, and client bundles. Use two synthetic tenants, separate users, and a user belonging to both. Test allowed access, forged tenant input, another tenant's session identifier, organization switching, removed membership, missing credentials, and dependency failure followed by recovery. Mock the identity/service boundaries where necessary but keep membership, authorization, and connection-selection logic real. Confirm rejected requests perform no downstream model or service work. Document which runtime and deployment boundaries remain untested. Run the relevant build, type, and focused tests, then smoke-test the implemented flow locally, including a success case and a meaningful failure or recovery case. Use fixtures where external services are unavailable, and report what ran, what passed, and what remains unverified. Ask before changing shared authentication settings, using customer data, making paid requests, or deploying. Report the concrete issues fixed, actual checks and results, local fixture setup, unrun cases, and remaining isolation risks. ``` ## Related resources - [eve authentication](https://eve.dev/docs/guides/auth-and-route-protection): Protect inbound agent routes and distinguish route access from service credentials. - [Multi-tenant outbound authentication](https://eve.dev/docs/patterns/multi-tenant-auth): Resolve service credentials from verified customer membership. - [eve connections](https://eve.dev/docs/connections): Choose connection credentials, tool filters, and account identity. ## Try other prompts - [Connect your eve agent to a read-only MCP service](/kb/prompts/add-eve-mcp-connection): Add one approved MCP service to eve with reviewed read operations, explicit account credentials, and checks for denied or expired access. - [Add regression tests for a critical user flow](/kb/prompts/add-critical-flow-regression-tests): Protect a key Next.js user journey with isolated tests for visible outcomes, failure recovery, and relevant access boundaries. ## Reference Architecture Choose a stack and work through the decisions behind it, with curated documentation, guides, templates, and courses to help you build. - [Agent stack](/kb/architecture/agents): Build and operate agents with models, tools, and durable workflows. - [Web applications](/kb/architecture/web): Choose rendering, data, authentication, and caching approaches. - [Backends](/kb/architecture/backends): Choose a runtime, connect services, and run background work. [Browse all stacks](/kb/architecture) ## Build with prompts Build an app, extend an agent, or improve your project with ready-to-use prompts for your coding agent. [Browse the prompt library](/kb/prompts) · [Read the Markdown index](/kb/prompts.md)