How to Run Claude Code and Cursor Agents Against Real Infrastructure Without Production Credentials

Key Points:

• The safe pattern is four parts: one ephemeral environment per agent task or pull request, a scoped identity with short-lived tokens, deny-by-default permissions with a policy check on every change, and an audit trail tied to a revocable identity. The agent never holds a production credential, not even read-only.
• Never give an agent a long-lived key. Use identity-based, short-lived credentials: AWS IAM roles assumed via OIDC (STS sessions default to 1 hour, cap at 12), GCP Workload Identity Federation, Azure Workload Identity, or Kubernetes projected service account tokens (1-hour default, bound to one namespace and audience).
• "Read-only production access" is not a safe middle ground. Real customer data lands in the model's context window, in agent logs, and in test fixtures the agent writes, and read access alone is enough for exfiltration through prompt injection.
• Cursor's and Claude Code's permission controls are real and worth enabling, but they govern the agent's local behavior, not who is authorized to call your cloud APIs. Cloud-side authorization has to be enforced separately with IAM and RBAC.
• Qovery provides the environment and identity boundary this pattern needs: preview environments per pull request, per-environment RBAC, environment auto-stop for non-production, and git-push deployments, all BYOC inside your own AWS, GCP, Azure, Scaleway account or existing Kubernetes cluster, so the data and the cloud bill stay yours.

The safest way to run Claude Code or Cursor against real infrastructure is to give each agent its own ephemeral environment in your own cloud account, authenticated with a short-lived, identity-based token scoped to that environment alone, deny-by-default everywhere else, and an audit trail tied to an identity you can revoke in seconds. The agent receives URLs, logs, and test results. It never receives a production credential, not even read-only, and when the task ends the environment is destroyed and the token dies with it.

Teams keep asking me how to give an agent safe access to production. The better question is why the agent needs production at all.

This is not a niche worry anymore. The 2025 Stack Overflow Developer Survey found 84% of developers using or planning to use AI tools, while only 29% trust the accuracy of what those tools produce. You have thousands of developers pointing autonomous agents at their codebases and, increasingly, at the infrastructure that codebase runs on. The blast radius of an agent equals the blast radius of the credential it holds, so the whole game is shrinking the credential, not perfecting the prompt.

What is the safest way to give Claude Code or Cursor access to our infrastructure?

The safest setup gives the agent its own disposable environment in your cloud account and never a production credential. Four controls make it work, and you can lift them as a checklist:

1. An isolated ephemeral environment per task or pull request, created on demand and destroyed when the task ends.
2. A scoped identity with short-lived tokens, issued through OIDC or workload identity federation and expiring in minutes to an hour.
3. Deny-by-default permissions with a plan-then-approve policy check on every infrastructure change.
4. An audit trail tied to one revocable identity, so you can answer "which identity did this" and cut it off fast.

"Read-only production access" feels like a reasonable compromise and it is not one. The moment an agent reads a real database, live customer data flows into the model's context window, into agent logs, and into the test fixtures the agent writes to disk. Read access is also enough to exfiltrate: an injected instruction can tell the agent to read a secrets table and paste it somewhere the attacker can see it. Read is a data path, not a safe zone.

Local mocks and sandboxes are necessary and not sufficient. An agent that touches a managed Postgres, an SQS queue, an IAM policy, or a DNS record passes every local test and then breaks against the real managed service, because the mock never modeled the IAM condition or the connection limit. You need real managed services in the loop, just not the production ones.

Two threat models hide inside "agent access," and they need different controls. The code the agent writes runs in your infrastructure later, and normal code review plus CI catch most of that. The cloud API calls the agent itself makes right now are the sharper edge, and those are governed by the identity and the environment you hand it. Keep them separate in your head.

A few terms, defined once so the rest of this stands on its own. An ephemeral (or preview) environment is a full running copy of your app, created per task and thrown away. OIDC token exchange, which cloud providers call workload identity federation, trades a workload's signed identity for a short-lived cloud credential with no stored key. A projected service account token is the Kubernetes version, a short-lived JWT bound to one namespace and audience. BYOC (bring your own cloud) means the workload runs in your account, not a vendor's.

Why should AI agents get an ephemeral environment instead of shared staging or production?

Ephemeral environments are the single most effective control because they bound damage in both time and scope: created for one task, seeded with fake or masked data, holding no production credentials, and destroyed on merge, so a confused or hijacked agent has nothing valuable to reach.

One environment per pull request or per agent task means several agents work in parallel without colliding with each other or corrupting a shared staging box. Each gets a clean slate and takes its mess with it when it goes.

For data, prefer in this order: synthetic fixtures first, then anonymized and subsetted snapshots, and never a production replica wired to live credentials. If you need realistic data, Replibyte is the open-source tool we built at Qovery to seed a database with masked production data.

Shared staging is a trap for exactly this use case. Over months it accumulates real third-party API keys, real integrations, and real data, which is the precise thing you were trying to keep away from the agent. A long-lived shared environment slowly becomes production with worse monitoring.

Ephemeral does not have to mean expensive. Flexera's State of the Cloud surveys have consistently found organizations estimate roughly a quarter of cloud spend is wasted, much of it idle non-production capacity. A TTL, auto-stop on inactivity, and destroy-on-merge keep agent-driven environments from becoming the next line item nobody remembers approving.

Define these environments from git so every agent change shows up as a reviewable diff instead of untracked console drift. Here is what must never exist inside an agent environment:

• Production database endpoints or connection strings.
• Live payment or third-party API keys.
• Production DNS write access.
• Shared machine-user credentials that humans also use.

How do you scope credentials for an AI coding agent so it can never touch production?

Replace static keys with short-lived, identity-based credentials scoped to a single environment: AWS IAM roles assumed via OIDC with a strict trust policy and permission boundary, GCP Workload Identity Federation with service account impersonation, Azure Workload Identity with managed identities and Azure Policy, or Kubernetes projected service account tokens bound to one namespace and audience. Every one of these expires on its own, which is the whole point.

The hard rules, scannable so you can enforce them:

• Zero long-lived access keys in agent config, environment files, or dotfiles. Datadog's State of Cloud Security 2025 found 59% of AWS IAM users still carry an access key older than a year. Do not add an agent to that pile.
• No wildcard resource ARNs and no *:* policies.
• A separate account, project, or subscription for agent environments.
• An explicit deny on anything tagged production.

Secrets go in as references, not values. Inject them at runtime from a secret manager into the workload, and keep the raw values out of the context window and out of any file the agent can read. The agent should know a secret exists without ever seeing it.

Restrict egress too. An agent environment with open outbound network is an exfiltration channel, so allow-list the destinations, allow-list the MCP servers and tools, and turn on the local permission controls that Claude Code and Cursor actually ship (more on those in the comparison below).

Set a revocation target and test against it: if you cannot invalidate every credential the agent held in under a minute, the design is wrong. The table shows the per-platform mechanics, all from primary docs.

What actually goes wrong when an agent holds real credentials?

The failure modes are documented, not hypothetical, and each has one control that neutralizes it. The pattern is always the same: untrusted input reaches a trusted, over-permissioned identity.

Prompt injection is the headline risk. Invariant Labs showed a toxic agent flow against the GitHub MCP server where a malicious public issue hijacked an agent into leaking data from the user's private repositories, and they named tool poisoning, where instructions hide inside a tool's own description. General Analysis demonstrated the same class against a Supabase MCP server, exfiltrating a private table because the agent ran under a credential that bypassed row-level security. Wiz's MCP security briefing frames the root cause plainly: an LLM cannot reliably tell instructions from data. Anthropic says so itself in the Claude Code security docs: "no system is completely immune to all attacks," and "you're responsible for reviewing proposed code and commands for safety before approval." Permission prompts help; they are not a boundary.

Secret sprawl makes injection pay off. GitGuardian's State of Secrets Sprawl detected 23.8 million new secrets leaked in public GitHub repositories in a single year, and found 70% of secrets leaked back in 2022 were still valid. An agent that can read raw secret values is one injected prompt away from becoming a leak of its own.

Over-permissioned non-human identities widen the blast. CyberArk's 2025 Identity Security Landscape counts roughly 82 machine identities for every human, with 42% holding privileged or sensitive access. Agents are now joining that population, and most of them inherit far more than they need.

Stolen credentials are still how breaches happen. Verizon's 2025 DBIR puts the human element in about 60% of breaches and use of stolen credentials at 22%, the most common initial access vector. IBM's 2025 Cost of a Data Breach reports a mean 241 days to identify and contain a breach, and about $4.67M when compromised credentials are the entry point. A credential that lives an hour is a much smaller prize than one that lives a year.

Destructive actions round it out. An agent that "fixes" a failing test by running a drop, a delete, or a terraform destroy against a live resource is a well-known class of failure, and the control is a plan-then-approve gate so nothing irreversible executes without a human. The mapping:

How do the options compare: cloud-native IAM, agent settings, PaaS review apps, or a platform?

No single layer solves this, and most teams end up combining two of them. Cloud IAM gives you the credential primitives but no environment lifecycle. Cursor and Claude Code gate the agent's local behavior but not cloud API authorization. PaaS review apps nail per-PR environments but run in the vendor's account. An internal developer platform ties ephemeral environments to scoped identities inside your own account.

Give the agent tools real credit. Claude Code ships permission modes and allow/deny rules in settings.json plus a Bash sandbox, and Cursor ships Run Modes with an allowlist, a sandboxed terminal, and privacy mode. Turn all of it on. Then be precise about what it governs: these controls decide what the agent does on the local machine, not who is allowed to call your cloud APIs. That authorization lives in IAM and RBAC, and no agent setting can enforce it.

Heroku Review Apps and Vercel preview deployments genuinely nail per-PR environments, and for a stateless web app they are hard to beat. The honest differentiator is whose account the workload and data live in. For regulated data, or for teams sitting on cloud commitments and Savings Plans, running the workload in a vendor's account is a non-starter. Cloud-native IAM plus your own automation is the most flexible option and the most engineering to build and keep running. Terraform or OpenTofu with Atlantis, HCP Terraform, or Spacelift, paired with OPA or Kyverno, covers the plan-then-approve gate on any change an agent proposes.

Qovery's role here, stated without overclaiming: it provides the environment and identity boundary this pattern needs. Preview environments per pull request, per-environment RBAC, environment auto-stop for non-production, git-push deployments, managed cluster upgrades, and databases backed by managed cloud services, all BYOC inside your own AWS, GCP, Azure, Scaleway account or existing Kubernetes cluster, so data residency, the cloud bill, and any Savings Plans stay with you.

What does a working setup look like end to end?

A platform engineer can stand this up in five steps this week, and the agent never sees a production credential at any step. Here is the reference flow.

Step 1, isolate. Give agent environments a dedicated account, project, subscription, or set of namespaces, with an org-level SCP or policy that denies access to production resources and production tags.

Step 2, provision. The agent opens a pull request; CI or the platform creates an ephemeral environment from the repo definition, seeded with synthetic or masked data.

Step 3, authenticate. The workload receives a short-lived token through OIDC or workload identity, scoped to that environment only. The agent gets URLs, logs, and test results, never keys.

Step 4, gate. Infrastructure changes go through plan-then-approve with a policy check, application changes through normal code review, and a human approves anything headed for production.

Step 5, expire and destroy. The environment auto-stops on inactivity and is destroyed on merge or PR close, credentials expire on their own, and the audit log records who did what and when.

One extra worth doing: give the agent a narrow, purpose-built surface (deploy, get logs, run tests, get environment URL) through a CLI, API, or MCP server instead of raw cloud access. It shrinks the attack surface to a handful of verbs. A minimal Kubernetes projected token, scoped and time-boxed, looks like this:

volumes:
  - name: agent-token
    projected:
      sources:
        - serviceAccountToken:
            audience: agent-env-api   # rejected anywhere else
            expirationSeconds: 3600   # 1 hour, kubelet auto-rotates
            path: token

How do you audit and revoke what an agent did?

Every agent action must map to one distinct, revocable identity and one immutable log line. If you cannot answer "which identity did this, and can I kill it right now," the agent is an unmanaged admin with a chat interface.

Use one identity per agent per environment. Never a shared machine user that humans also touch, and never a credential reused across environments, because both destroy attribution the moment something goes wrong.

Read from both sides. On the cloud side, filter AWS CloudTrail, GCP Cloud Audit Logs, or Azure Activity Log by the agent's role or principal, plus Kubernetes audit logs for namespace-scoped actions. On the platform side, keep deployment history tied to a git commit and an actor, with per-environment RBAC so a reviewer can see exactly what scope existed at the time.

Keep a break-glass runbook and run it in order: revoke the role trust policy or federated credential, rotate the OIDC provider audience, delete the namespace, destroy the environment, then review the log. Practice it before you need it.

Track four numbers monthly: long-lived keys in use (target zero), median credential lifetime, the share of agent actions attributable to a unique identity (target 100%), and median time-to-destroy for agent environments. If those trend the right way, the agents are staying inside the box.

Agents ship fast, and guardrails are what let you keep them fast without keeping you up at night. Give each one a disposable environment and a credential that expires, and the worst-case incident becomes a destroyed sandbox instead of a breach report. If you want to compare notes on how other teams are doing this, come find us in the Qovery Discord.