Replit Security Guide: controlling the Agent, secrets, databases and publishing

Replit lets an AI agent write, run and publish a full application in one workspace, so the line between experimenting and changing production is a matter of configuration rather than habit. Instructions to an agent are not permissions, so roles and settings carry the weight. This guide covers how identity and roles work in Replit workspaces, how secrets and the development and production databases are separated, how checkpoints and Plan mode limit damage, which admin settings govern publishing, what the audit log records and a hardening baseline. It goes deeper on Replit than our cross-product AI App Builder Security Guide. Facts come from Replit's own documentation, checked on 8 November 2026; several controls are Enterprise only, and the product changes often, so re-check settings before enforcing them.

This is an independent guide from NHI Mgmt Group, based on Replit's public documentation as of November 2026. It is not sponsored or reviewed by Replit. Product features change, so confirm settings against Replit's current documentation.

Key takeaways

• The Agent cannot write to production data. Replit's docs state the Agent can modify only the development database and reads production through a read-only replica; schema changes reach production when a human publishes.
• Production secrets are a separate list. Published apps use Production app secrets set under Publishing, and DATABASE_URL points to a different database in each environment, so check both before every first publish.
• Secret values are not hidden from collaborators. Multiplayer collaborators see values, and organisation members without the Owner role can still print environment variables, so treat every editor as able to read every secret.
• Publishing is the control point. Private deployments, required security scans, blocking at a severity and deployment geography are workspace settings an admin should set before people start building.
• Audit logs need streaming. Enterprise audit logs keep 30 days by default; stream them to your SIEM through Log Streams if you want an investigation window longer than a month.

How identity and access work in Replit

Replit organises users into an account (billing, seats and account-wide security) containing one or more workspaces. SAML SSO is available only on the Enterprise plan; the setup wizard offers Microsoft Entra ID, Google Workspace, Okta and an "Other provider" option. There is no separate enforcement toggle: once SSO is active, users whose email matches a claimed domain must use SSO and their earlier email or social login stops working. Public domains cannot be claimed, and claimed domains must match an admin's email domain.

• SAML is authentication only: signing in with SAML does not invite users, and removing a user in the IdP does not deprovision them in Replit on its own. Use SCIM (Enterprise) for provisioning, deprovisioning and role sync.
• SCIM assigns roles: when SCIM is in use, roles are assigned through synced IdP groups rather than the members page, which brings Replit roles into your normal group reviews.
• Development previews: "Require private development URLs" forces authentication, including SSO where SAML is enabled, for development previews, and applies to existing apps. The docs note private previews are not supported for Expo Go, simulators or the Replit mobile app.

Enforce MFA in the identity provider for the Replit application. See the SCIM Provisioning Guide for leaver timing.

Admin roles and privileged access

Enterprise custom groups add access on top of a role, with workspace permission levels Owner (reserved for admins), Billing manager, Manager, Editor and Viewer. The most useful separation is between Editor and Publisher at app level: builders, and the Agent working in their session, can change code and the development database, while a smaller group publishes. On Core and Pro the account admin is the only admin. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Secrets

Project secrets are encrypted (AES-256 at rest, TLS in transit) and exposed to code as environment variables, added through the Secrets tool. Account secrets live in Account Settings and can be linked to projects you own, staying in sync until unlinked. Production secrets are managed separately under Publishing, Adjust settings, Production app secrets, and published apps run with REPLIT_DEPLOYMENT=1 so code can tell the environments apart.

Replit's guidance is to enter credentials in the Agent's secure form, never in chat; values collected that way are scoped to that private chat. Use development credentials with only the permissions required. For external secrets managers, provider modules configure short-lived provider credentials (loaded for non-interactive commands from ~/.config/replit-oidc/env.sh) and the Agent then retrieves only the secrets the app needs; the docs warn that a token helper's output must be kept out of logs and chat. That pattern is better than long-lived keys pasted into Secrets. See the Secrets Management Guide.

Integrations and API keys

Connectors and integrations give the Agent access to third-party services. Enterprise admins can disable "Integrations", which blocks members from connecting or configuring integrations and hides integration suggestions from the Agent. Audit log access through the Compliance API uses an API key; the compliance:messages:read scope returns full prompt text for project.message_sent events, which may contain sensitive data, so give that key to one system with an owner.

Development and production separation

Every Replit app has two databases. The development database is created automatically; the production database is created at first publish. The docs state "Agent is not able to modify the production database": it can create and modify development tables and can only read production through a read-only replica, which may lag. A human can edit production data in the Database tool by selecting production, opening My Data and turning on Enable Editing.

• Schema on publish: structural changes made in development are applied to production at publish. The process handles tables, columns, indexes, constraints, views and row-level security policies, but not domains, functions, procedures, triggers or grants, and has limited role support. Publish flags risky changes such as dropping or renaming columns with data, and you can test a migrated copy of production in a preview before approving.
• Connection strings: DATABASE_URL points to development in the workspace, Shell and Agent sessions and to production in the published app. REPLIT_ENVIRONMENT=production describes the platform, not your database.
• Recovery: on current infrastructure a database can be restored to any checkpoint through rollback; legacy Neon databases support point-in-time restore within the retention window. A removed production database enters a seven-day soft-delete period and can be recovered by Replit Support within that window.

Two gaps remain your responsibility: triggers, functions and grants must be migrated by hand, and the person approving the publish is the last human check on Agent-generated schema changes. See the Database Security Guide.

Agent checkpoints, Plan mode and approvals

Checkpoints appear in the Agent panel History with "Rollback here" and "Changes" controls. Rolling back opens a confirmation that lists what will be affected: files, Agent memory, tasks and a Database checkbox. Plan mode, toggled in the prompt composer, makes the Agent think first and wait for approval before changing files; the plan lists what and why, success criteria, out-of-scope items and numbered build steps.

Know the recovery path, including checkpoint rollback, before you need it. See the Human-in-the-Loop for AI Agents Guide.

Publishing and deployment controls

Admins set these under Settings, Advanced:

• Private deployments: Off, Require (all newly published apps private) or Require for non-admins. Applies to new apps only; review existing public apps separately and use Public publishing exceptions, Manage, to revoke exceptions.
• Password-protected deployments: Enabled, Disabled or Disabled for non-admins. For stronger access control, prefer private deployments behind SSO.
• Deployment geography: limits publishing to a region (North America, South America, Europe (EU), Asia or Australia). The docs note it does not guarantee that external services the app calls process data in that region.
• Require security scan and Block publishing at severity: scans run during publishing and block at the chosen minimum severity, which defaults to critical only. Lower it to high.
• Workspace Security Center and Auto-Protect: dependency scans against public vulnerability records, with a "Fix with Agent" action; Auto-Protect prepares patches for newly disclosed dependency vulnerabilities above a severity threshold for review. Replit notes the scans do not include deeper source-code analysis and a clean scan is no guarantee. Set Security alert recipients to a shared list.

HTTPS is enabled by default for published apps. Replit's own 16-item security checklist (HTTPS, input validation, no keys in front-end code, authorisation checks, SQL injection prevention, rate limiting and more) is a good review template for Agent-built code. See the Dependency Update Automation Guide.

Logging and detection

Audit logs are Enterprise only and enabled by an account admin under Settings, Advanced, Audit Logs. Audit Logs V2 adds more than 65 events across deployments, access and identity, workspace administration, project activity, secrets, connectors, domains, agent activity and SCIM provisioning, with a published event schema catalogue. Admins can search, filter and bulk export in the portal. Events can stream in real time through WorkOS Log Streams to Datadog, Splunk, Amazon S3 or a generic HTTP endpoint. Default retention is 30 days.

Detections worth building: a deployment made public or a public publishing exception added; changes to production secrets; new connectors; secrets read or changed by a user outside the app team; publishing by an account that is not on the app's Publisher list; SCIM deprovision events followed by activity. Map these to T1078.004 Cloud Accounts for misuse of valid accounts and T1485 Data Destruction for destructive agent actions.

Metrics: share of published apps that are private; publishes blocked by scan per month and median time to fix; open critical and high dependency findings older than 14 days; number of people holding Publisher or account admin; days of audit history retained outside Replit (target at least 365).

Hardening baseline

1. Identity: claim your domains, configure SAML SSO and SCIM, enforce MFA in the IdP, and map roles to IdP groups.
2. Admins: limit account admins; delegate with workspace admins; grant Publisher per app to a small group.
3. Publishing: set Private deployments to Require, disable password-protected deployments for non-admins, require private development URLs and set deployment geography.
4. Scanning: turn on Require security scan, block at high, enable Auto-Protect and route alerts to a team list.
5. Agent: set the PII filter to Redact or Detect, disable Integrations until reviewed, and decide on Memory; require Plan mode for sensitive work by team rule.
6. Secrets: move long-lived keys to an external manager with short-lived credentials; review Production app secrets before first publish.
7. Logging: enable audit logs and stream them to your SIEM on day one.
8. Test and roll back: pilot settings in one workspace for two weeks, then widen. Settings changes are reversible in the console, but Private deployments and password settings apply to new apps only, so audit existing apps separately.

Common misconfigurations

• Trusting a freeze instruction: telling the Agent not to change things is not a control. Use roles and the development-only database.
• Forgetting production secrets: testing with one set of credentials and publishing with missing or development credentials, or reusing an over-privileged development key in production.
• Assuming hidden values are safe: non-Owner organisation members can print environment variables; anyone with edit access should be treated as able to read secrets.
• Public by default: leaving Private deployments Off, so internal tools built in an afternoon are published to the internet.
• Critical-only scan blocking: the default lets high-severity dependency issues ship.
• 30-day audit window: not streaming logs, then discovering during an investigation that the relevant events have aged out.

Practitioner checklist

• Claim domains, enable SAML SSO and SCIM, and enforce MFA in the IdP.
• Keep account admins to a named few; use workspace admins and app-level Publisher grants.
• Set Private deployments to Require and require private development URLs.
• Turn on Require security scan and block publishing at high severity.
• Review Production app secrets before every first publish; prefer short-lived external credentials.
• Set the on-device PII filter to Redact or Detect for teams handling personal data.
• Rehearse a checkpoint rollback, including the Database option, on a test app.
• Migrate triggers, functions and grants by hand and review risky-change flags at publish.
• Enable audit logs and stream them to your SIEM with at least a year of retention.

Standards and references

• Replit: Production databases
• Replit: Secrets
• Replit: Privacy and deployment settings
• Replit: Security (Enterprise)
• Replit: Audit logs
• Replit: Roles, groups and access
• Replit: SAML single sign-on
• Replit: Build with Agent

Related NHI Mgmt Group resources: AI App Builder Security Guide · Vibe Coding Security Guide · AI Coding Agent Incident Playbook