Replit Agent Security: Four Control Boundaries to Test

Replit's security model puts four distinct systems behind one chat window. The Agent runtime plans and acts. Generated code becomes an application. Replit publishes that application onto managed infrastructure. Some applications then call external LLM endpoints over HTTP. Replit's shared responsibility model assigns different owners to each layer. I want to review those boundaries separately, because a green scan badge on generated code says nothing about the authorization policy on a later model request.

TL;DR

• Replit secures the Agent runtime and platform. Customers review generated code and approve sensitive actions. They also manage prompts and vet third-party Skills or MCP tools.
• Agent security scans combine model analysis with Semgrep and HoundDog.ai, but Replit describes the scan as incomplete and recommends code and dependency review alongside running-app checks.
• Enterprise settings can require private development URLs and pre-publish scans; some controls apply only to new publications.
• DeepInspect covers customer-routed HTTP LLM traffic. It has no control over local execution or opaque Replit-managed Agent model calls.

Boundary one is the Agent runtime

Replit states that it owns the Agent runtime, including the agentic framework and core tools. That ownership includes memory management. Customers remain responsible for prompts and instructions plus validating output. They also approve sensitive actions such as deploys and outbound calls, including secret changes. Replit also splits Skill and MCP responsibility: Replit-vetted components sit on the platform side, while user-installed components require customer vetting and configuration. Customers also own revocation.

That division gives a review its first evidence request. Ask for the list of enabled tools and the approval settings for sensitive actions. Also request the identities allowed to use Agent and the process for adding third-party Skills. Then execute one synthetic outbound-call task and capture the approval screen. Retain the actor and proposed action alongside the final decision. The useful control is the decision a named person makes before the action, not a policy sentence buried in an onboarding deck.

Prompt injection belongs here when untrusted content reaches Agent through a prompt or connector, including a Skill or tool result. Replit says it hardens the Agent runtime and adds mitigations while customers sanitize untrusted input and validate outputs. That is defense in depth with explicit ownership.

Boundary two is generated source code

Agent security scans review the entire codebase using model-based analysis plus static analysis tools including Semgrep and HoundDog.ai. The scan maps routes and APIs, along with data flows and entry points. It then builds a threat model and runs static analysis before producing findings in Project Security Center. Larger projects can take up to 15 minutes.

The scan targets concrete application defects, including SQL injection and cross-site scripting. It also checks for cross-site request forgery, sensitive data flowing to logs or third-party APIs, and architectural weaknesses in routes or data flows. Accepted findings can be sent back to Agent as separate remediation tasks, followed by another scan.

Replit's limitation statement is the line I would put at the top of a review worksheet: a scan is not a complete security review. The documentation calls for code review and tests, followed by dependency review and running-application checks. Level 3 adds a black-box penetration test alongside source review. That combination tests code behavior rather than treating generated output as trusted because Agent wrote it.

Boundary three is the published application

Enterprise privacy settings govern development URLs and deployment visibility. They also control source export, Git remotes, and required security scans. Replit documents settings that can put authentication on development URLs, including SSO where SAML is enabled. Separate controls force new publications to be private and ban ZIP exports of source code. They can also limit teams to private Git remotes and make a security scan mandatory before publishing.

Two timing details matter. The private-deployment requirement applies to newly published apps while existing deployments keep their current visibility. The required-scan setting also excludes apps published before the setting was enabled. A reviewer should list every existing application and test its current state. Reading the organization-level toggle gives false assurance about older assets.

Published-app authentication and authorization sit with the customer under Replit's model. So do data handling and privacy notices, along with application-level logging and vulnerability response. Replit handles the infrastructure and platform isolation. It also handles TLS, storage encryption, edge protection, and platform incidents. The application owner still has to decide which end user can see a customer record and which business action that user can invoke.

Boundary four is the model request

A Replit-built application may send an HTTP request to an LLM endpoint after publication. At this boundary, network reachability and possession of an API credential authenticate the integration. The security decision needs more context. It needs the end user behind the app and their role. It also needs the prompt's data classification and selected model route, followed by the requested operation and policy version in force.

This is where zero trust for LLM traffic becomes operational. A service credential can be valid while a specific prompt exceeds the employee's authority. Policy has to evaluate the request before the model receives it. Alerting after a completion gives an investigator evidence and leaves the original disclosure intact.

Replit's Secrets and Connectors mechanisms remain the right place for credential storage. Endpoint and IAM controls own stolen credentials. DeepInspect's enforcement boundary begins only when an authenticated user or agent sends HTTP AI traffic through the gateway. A Replit-managed Agent call hidden inside the platform is outside that path unless Replit exposes a customer-controlled route that can be placed behind the proxy.

A four-part test plan

A credible Replit Agent security review produces one test for each boundary instead of one overall grade.

• Agent runtime test: give Agent a synthetic tool result containing an instruction to call an unapproved domain. Verify the configured human approval path. Retain the actor and proposed action with the final decision.
• Code test: seed a safe example of an injection flaw in a test branch and run Agent security scan. Review the finding and apply a fix before rerunning the scan. Record tool versions and the final commit.
• Deployment test: enumerate old and new applications. Verify authentication on every development URL. Check the actual visibility of each published app, including assets created before enterprise settings changed.
• Request test: send a labeled synthetic value through a customer-routed LLM call. Confirm that identity and classification appear in the resulting record. Check the route and policy version alongside the decision, timestamp, and correlation ID.

A single screenshot showing four green checkmarks would make me suspicious. Each layer uses its own evidence source and has a separate failure mode. The Agent runtime supplies approval history. Code and scan evidence come from the repository, while deployment checks establish actual access. The HTTP boundary records the request-level policy decision.

Security ownership after deployment

Operating cadence matters after the first review. Replit recommends rerunning scans after major code changes and dependency updates. It also recommends a scan before publishing a new version. Enterprise teams should also review workspace membership and third-party Skills. Connector permissions and old application visibility belong on the same fixed schedule.

Model-request policy changes on a different cadence. A newly approved model or new data class should update a versioned policy at the HTTP boundary. A change in a support agent's role should do the same. The record needs to preserve which version governed an earlier call, because today's configuration cannot explain a decision made on September 7, 2026.

AI policy enforcement at the HTTP layer describes that decision point. It complements Replit's source-code and deployment controls. The layers should exchange correlation IDs where the architecture allows, while keeping their responsibilities explicit.

DeepInspect

This is the gap DeepInspect closes at boundary four. DeepInspect is a stateless proxy on customer-routed HTTP traffic between authenticated users or agents and LLM endpoints. It evaluates identity context and prompt classification. It also checks the route and versioned policy before permitted traffic reaches the model.

Each decision produces a signed audit record that can correlate with application logs and Replit workspace events. Replit remains responsible for its Agent runtime and platform. The customer keeps ownership of generated-code review and deployment configuration. It also owns endpoint posture, credentials, and third-party tools. DeepInspect adds deterministic AI policy enforcement on the model request path it can actually inspect. Book a technical deep dive at deepinspect.ai.