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.
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.