Quick answer: Replit stores credentials in the Secrets pane — AES-256 encrypted, injected as environment variables at runtime. Replit Agent can read every secret in your workspace while it builds. There is no per-session scoping, no audit trail of which API calls the agent made on your behalf, and no isolation between what the agent can access and what your deployment uses. The risk compounds because Agent sometimes writes secrets into plain .env files or into client-side code with framework prefixes that browsers download directly.
How Replit handles credentials
Replit's Secrets pane is the right place to store credentials. Secrets are encrypted at rest with AES-256, transmitted over TLS, and injected as environment variables available to your running app via process.env or os.getenv(). They're separate from your project files — not visible in the code editor, not included when someone forks your Repl, not committed to version history.
There are two credential surfaces in a Replit workspace:
The Secrets pane — encrypted storage, accessible as environment variables. This is what you want to use. Secrets work in development and in deployed apps (all deployment types except Static Deployments).
.env files — plain text files inside your project tree. These are not encrypted, not hidden, and are visible to anyone with access to the Repl. A .env file is just a file.
Replit Agent knows about both. When it connects a third-party service for you, it usually reaches for the Secrets pane — but if your prompt mentions a key directly, or a tutorial it copied uses .env conventions, Agent may write the credential into a plain text file instead.
What Replit Agent can access
When Replit Agent is building in your workspace, it operates in the same environment as your running code. That means it has access to all the Secrets you've defined — the same credentials your deployment will use.
This is not a design flaw. It's the same model used by most development environments. The problem is the scope: Agent has access to every Secret in the workspace, regardless of what the current task requires. If you're building a feature that needs only an OpenAI key, Agent also has access to your Stripe secret key, your GitHub token, your database connection string, and anything else in the Secrets pane.
There is no per-session credential scoping in Replit's native model. And there is no audit trail of which external API calls the Agent made on your behalf — only what Replit logged at the shell or console level, which shows what ran, not what external services authorized.
Three Replit-specific risk patterns
Beyond the standard shared-credential problem, Replit Agent has patterns worth knowing about specifically:
The .env file leak. Agent may write a credential into a .env or .env.local file rather than the Secrets pane, especially when following a tutorial it scraped or when you mention a key value directly in your prompt. Plain text files in the project tree can be read by anyone with Repl access, committed to version history, and — on free Repls, which are public by default — indexed by scrapers within minutes of the key appearing. Open the project file tree alongside the Secrets pane and check that no credential exists in both places.
The client bundle leak. JavaScript frameworks (Vite, Next.js, Create React App) inline any environment variable with a specific prefix — VITE_, NEXT_PUBLIC_, REACT_APP_ — into the static JavaScript bundle that every browser downloads. Replit Agent, when wiring up a frontend call to Stripe or OpenAI, sometimes reaches for these prefixed variable names because the preview runs immediately. A secret stored securely in the Secrets pane but referenced with a VITE_ prefix lands in every visitor's browser. Check your client-side code for these prefixes on any variable that holds a real credential.
The forked Repl. Secrets are not copied when a Repl is forked — this is intentional and a good security boundary. However, if a credential appeared in a file (not the Secrets pane) at any point in the project's history, that history is preserved in forks. Removing a key from a file doesn't remove it from history.
The shared-credential problem
The fundamental issue is that Replit Agent — like any code running in the workspace — can reach any service covered by your Secrets. A runaway build step, a malicious dependency, or an Agent prompt injection can attempt API calls against your Stripe account, GitHub repositories, or database using the full credentials you've stored.
Prompt injection is the specific risk for AI agents: Agent fetches external content (documentation, a webpage, a package README) as part of building, and if that content contains a malicious instruction, it can redirect Agent's next action. An agent with full Stripe access that encounters a prompt injection has full Stripe access during the attack. An agent scoped to the one operation its current task requires has only that operation available. See what happens when you paste an API key into an AI agent's prompt for how this plays out in practice.
A better pattern
The fix is to keep Replit Secrets for what they're good at — securely storing credentials in your workspace — and route Agent's API access through a credential broker instead of passing the full key directly.
The agent's tools point at an MCP endpoint. That endpoint holds the actual service credentials. When Agent calls a tool, the broker checks the current access profile, issues a scoped token for the specific operation the task requires, logs the request, and returns the result. The raw Stripe or GitHub key never reaches the agent's context.
For each agent session this gives you:
- Scope limited to the task. An Agent session configured for "create Stripe payment intents" can't issue refunds, read customer records, or update subscription plans — even if the underlying Stripe key can do all of those things.
- Per-session audit log. Every tool call includes the service, the operation, and a timestamp. You can see exactly what the Agent attempted, not just what Replit executed at the shell level.
- Revocation without rotating Replit Secrets. If a session behaves unexpectedly, you revoke the broker token. Your Secrets are untouched. The next Agent session starts fresh with a new scoped token.
For the broader credential broker pattern, see MCP security: what developers need to know.
Connecting Replit Agent to Gazebo's MCP endpoint
1. Create an access profile in Gazebo.
Log in to Gazebo and create a new access profile for your Replit Agent session. Add the services the current build task needs and set the operation scope — for a billing feature, that might be Stripe payment intent creation only; for a deployment task, GitHub read access and Vercel deployment triggers.
2. Copy the MCP endpoint URL and agent token.
Gazebo generates a unique MCP endpoint URL and bearer token per access profile. Copy both.
3. Add the MCP server to Replit Agent's tool configuration.
In Replit Agent, configure the Gazebo MCP server as a tool source:
URL: https://mcp.gazebohq.com/YOUR_PROFILE_ID
Authorization: Bearer YOUR_AGENT_TOKEN
4. Instruct Agent to use the MCP tools for external service calls.
Tell Agent to reach external services through the MCP tools rather than reading credentials directly from the environment. The prompt context matters here — explicitly directing Agent to the MCP endpoint prevents it from falling back to process.env reads.
5. Verify in the access log.
After the first Agent run, check the Gazebo access log to confirm the expected operations appear with the correct profile identity. Any operation the Agent attempted that falls outside the profile scope will show as denied — which is the correct behavior.
6. Keep Replit Secrets for non-agent code.
Your database connection string, internal service keys, and other credentials that deterministic (non-agent) code uses stay in Replit Secrets. Only the credentials that Agent needs to call external APIs on your behalf route through the broker. This keeps the Secrets pane clean and means narrowing Agent's access doesn't affect the rest of your deployed app.
What you gain
Replit's credential model is correct for most workloads — encrypted storage, clean environment variable injection, good deployment integration. The gap is specific to AI agent sessions where the principal making decisions is not a deterministic workflow you designed, but an agent deciding what to do next.
Routing Agent's external API access through a credential broker closes that gap without changing how Replit Secrets work for the rest of your app. Agent gets scoped, logged, revocable access for the current task. Your Secrets stay in the Secrets pane where they belong, and they don't need to be the thing Agent reads directly.
See AI agent permissions: how to set granular access for how to scope access profiles correctly across service, operation, and data dimensions.
Gazebo gives every Replit Agent session its own scoped identity — credentials limited to what the current task needs, logged per session, revocable without touching your Replit Secrets. See how it works or get started free.
Last reviewed: August 2026. Independent editorial — not affiliated with or endorsed by Replit. Replit's Agent and Secrets features evolve quickly — verify against current Replit documentation before making changes.