Add Identity, Secrets, and Integrations

Authentication establishes who a user is. Authorization decides what that user may see or do. A signed-in user should not automatically see every record. Define roles, ownership, tenant or organization boundaries, and action-level permissions. Enforce them on the server for every protected read and write.

Replit offers two Agent-provisioned choices. Replit Auth requires users to sign in with Replit accounts and keeps Replit branding. Clerk Auth gives the app an independent user store and customizable branding; its development and production environments have separate users and keys. Choose before real users exist. Changing identity systems later is a user-data migration, not a visual setting. In either case, keep domain permissions explicit rather than scattering provider-specific checks through the interface.

Decide whether a record belongs to one user, a team, an organization, or the entire application. Store the relevant ownership relationship and filter every query by the authenticated scope. Test horizontal access: one ordinary user must not retrieve or mutate another user's record by changing a URL or request identifier.

Administrative capability needs its own boundary and audit history. Avoid a single hidden boolean that unlocks everything without explanation. Name administrative actions, require appropriate roles, and record who performed them. Consider a separate admin view when ordinary and privileged workflows differ substantially.

API keys, tokens, signing secrets, and connection strings do not belong in source code, prompts, screenshots, or Git history. Store them in Replit's Secrets tool and read them as environment variables on the server. The browser should receive only values explicitly designed to be public.

A secret has a lifecycle: creation, least-privilege scope, named owner, rotation, revocation, and incident response. Keep development and production values separate. If a secret is exposed, remove it from visible history where practical, revoke it at the provider, create a replacement, update the intended environment, and verify the old value no longer works.

Secrets are encrypted storage, not isolation from every collaborator who can run the app. A Multiplayer collaborator can view App Secret values. In an organization, a non-owner may not see a value in the pane but can still access it through the running environment. Treat project edit or runtime access as potential secret access, invite only trusted collaborators, prefer narrowly scoped development credentials, and revoke access when collaboration ends.

A connector or API grants the project access to another system. Begin read-only when possible and request the narrowest account and scopes. Verify which project, environment, and user owns the connection. Never assume Agent can see a service merely because you can access it in another browser tab.

Separate integration reads from writes. A read can still expose private data, but a write can notify people, change records, or spend money. Put consequential writes behind server authorization, validation, an explicit user action or approval, idempotency, and an attempt log. Use synthetic destinations until the workflow is proven.

External services fail. Design pending, succeeded, failed, and retryable states. Store a safe provider reference and last attempt time. Tell the user whether their request was accepted locally, whether the external action completed, and what will happen next. Never show success before the authoritative system confirms it.

Set timeouts and bounded retry policies. Retry automatically only when the operation is idempotent or protected by a stable idempotency key. For ambiguous outcomes, reconcile by querying the provider with the local operation identifier rather than sending the action again blindly.