--- title: "Replit Agent Credentials: Scope Agent Access" description: "Replit Agent can read every Secret in your workspace — no per-session scoping, no audit trail. A scoped MCP connection gives each Agent session its own identity, audit log, and revocable access." publishedAt: "2026-08-13" readingTime: "7 min" url: "https://gazebohq.com/writing/replit-agent-credentials" --- **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](/writing/pasting-api-key-into-agent-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. Gazebo's MCP endpoint checks the agent's service and declared-method policy, logs retrieval, and returns the actual stored provider credential—not an operation result or a new per-call token. The runtime receives the key. Keep it out of prompts and logs, trust the runtime's host, and use provider scopes to restrict subsequent actions. 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](/writing/mcp-security). ## Connecting Replit Agent to Gazebo's MCP endpoint **1. Create an access profile in Gazebo.** Log in to [Gazebo](https://app.gazebohq.com) 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. Create an agent token.** Create the agent bearer token at [Agents](https://app.gazebohq.com/agents). The MCP endpoint is `https://app.gazebohq.com/api/mcp`. **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://app.gazebohq.com/api/mcp 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](/writing/ai-agent-permissions) 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](/security) or [get started free](https://app.gazebohq.com/signup). --- *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](https://docs.replit.com) before making changes.* ## Frequently asked questions **Q: Can Replit Agent read my Secrets?** Yes. Replit Agent runs in your workspace environment and has access to all Secrets you've defined — the same credentials your deployment uses. There is no per-session scoping in Replit's native model. **Q: What is the risk of Replit Agent writing credentials to .env files?** A .env file in your project tree is plain text, not encrypted, and visible to anyone with Repl access. On free Repls, which are public by default, scrapers can find credentials within minutes. Replit Agent sometimes writes keys to .env files rather than the Secrets pane, especially when following tutorials or when a key is mentioned directly in a prompt. **Q: How can VITE_ or NEXT_PUBLIC_ prefixes expose credentials in Replit?** JavaScript bundlers inline any environment variable with the VITE_, NEXT_PUBLIC_, or REACT_APP_ prefix into the static JavaScript bundle — meaning every browser that loads your app receives the value. Replit Agent sometimes uses these prefixes when wiring up frontend API calls, which puts secrets into the client bundle even if they were stored correctly in the Secrets pane. **Q: How do you revoke a Replit Agent session's access without rotating your Secrets?** If the Agent session routes external API calls through a credential broker rather than reading Replit Secrets directly, you revoke the session's broker token. The underlying Secrets are untouched and the rest of your app keeps running. **Q: Do Replit Secrets work in deployed apps?** Yes, Replit Secrets are available in all deployment types except Static Deployments. Static Deployments cannot read Secrets at runtime — build-time inlining is the only path, which forces secrets into the client bundle.