DEV Community

Cover image for Secretless AI-powered development flow
Riptides
Riptides

Posted on

Secretless AI-powered development flow

#webdev #programming #ai #security

Modern development increasingly happens inside different environments: local machine, containers, VMs, remote dev servers. At the same time, AI coding assistants like GitHub Copilot have supercharged developer productivity, but they've also amplified a critical security problem.

When you're using AI to generate infrastructure code, write boto3 scripts, or build Terraform configs at 10x speed, credential management is your primary failure point and the biggest security risk.

How do you securely give a VM or container access to cloud APIs without mounting credential files, passing secrets as environment variables, or copying keys into the environment, especially when AI assistants are generating code that needs those credentials?

And here's the real concern: With AI generates code you didn't write line-by-line, how confident are you that it won't accidentally log secrets, echo environment variables, or write credentials to temp files? Running AI-generated code in an environment with zero access to credentials means you can sleep better at night.

The conventional answer is still based on secrets: copy your ~/.aws/credentials file, mount it as a volume, set AWS_ACCESS_KEY_ID in your shell, or use instance profiles if you're lucky enough to be running in the cloud already.

But this approach has serious flaws:

Credential material tends to proliferate (copied into VM images, accidentally committed, or left behind in shared environments), the blast radius expands (every developer/VM/container with access can leak it), rotation becomes manual and painful (you have to chase down every place the secret landed), and you still get poor auditability (it’s hard to answer “who used which credentials, when?” and “which process touched what API?”).

This post shows a different approach: secretless development environments powered by Riptides. We'll use Lima VMs on macOS with GitHub Copilot as a practical example, but the same pattern applies to Docker containers, remote SSH sessions, cloud dev environments, or any workspace where your AI-generated code runs.

Why sandboxed environments matter for AI-generated code: Treat AI-generated code as untrusted by default, run it in a sandboxed VM or container with zero credential access so even accidental logs, debug outputs, or file writes can't leak credentials.

The problem with development credentials

Let's say you're a macOS developer building cloud-native applications. You want a clean Linux development environment, so you use Lima to run a lightweight Ubuntu VM. Now you need to run AWS CLI commands, test Terraform configs, or call AWS APIs from Python scripts inside that VM.

The standard approach: Copy your credentials

The typical workflow looks like this:

  1. Export AWS credentials on your Mac: 
   export AWS_ACCESS_KEY_ID=AKIA...
   export AWS_SECRET_ACCESS_KEY=...
Enter fullscreen mode Exit fullscreen mode
  1. Pass them to the VM via environment or mount: 
   # Lima config
   env:
     AWS_REGION: us-west-2
     AWS_ACCESS_KEY_ID: AKIA...
     AWS_SECRET_ACCESS_KEY: ...
Enter fullscreen mode Exit fullscreen mode
  1. Or mount your credentials directory: 
   mounts:
     - location: "~/.aws"
       writable: true
Enter fullscreen mode Exit fullscreen mode
  1. Run AWS commands inside the VM: 
   limactl shell default
   aws ec2 describe-instances
Enter fullscreen mode Exit fullscreen mode

This works. But you've just copied possibly long-lived secrets into an isolated environment where they're harder to rotate, easier to leak, and completely unaudited.

What can go wrong?

Credential files are persistent (they remain on the VM filesystem until manually deleted), and VM snapshots or “golden images” can quietly capture secrets as a side effect of reproducibility. Shared VM templates often turn into shared secrets, any process in the VM may be able to read credential files, and while AWS CloudTrail can tell you which IAM principal made a call, it usually won’t tell you which process or which workload inside your dev VM did it. When credentials expire or are compromised, rotation becomes a manual update process across every VM/container/config you touched.

Even if you use temporary credentials via AWS STS, you're still handling and storing secrets, they just happen to be short-lived secrets.

The AI coding assistant paradox

GitHub Copilot in VS Code promises 10x developer productivity. It generates infrastructure code, writes AWS automation scripts, and builds Terraform configurations in seconds.

But this productivity gain is bottlenecked by credential management:

Copilot can generate Terraform code, or a deployment script in seconds—yet you still end up stopping to configure AWS credentials, copy secrets into the VM, or manage API keys and access tokens.

The faster you code with AI, the more you're fighting with credentials.

And worse: the more code AI generates, the more opportunities for credential leakage. AI-generated scripts that echo variables, log debug output, or write to temporary files can accidentally expose secrets that weren't there before.

The security benefit: AI code + sandboxed environments + zero credentials

With that setup, you get multiple layers of protection:

AI-generated code runs in an isolated VM/container rather than on your host; there are no credentials on disk to leak even if the code behaves unexpectedly; and Riptides can tie credential injection and telemetry to the calling process.

This means you can trust AI to generate code at high speed without worrying about accidentally creating security vulnerabilities. Run it, test it, iterate, knowing that even if something goes wrong, credentials were never in play.

How Riptides solves the problem

Riptides eliminates stored secrets by injecting credentials dynamically at runtime, directly into the network requests that need them. The workload never stores, reads, or manages AWS credentials directly.

Here's how it works:

  1. Every process gets a kernel-enforced identity

    Riptides assigns a SPIFFE-based workload identity to each process, verified and enforced at the kernel level.

  2. Credentials are injected on-the-wire

    When a process (like the AWS CLI) makes an HTTPS request to AWS APIs, Riptides intercepts the connection in kernel space, fetches short-lived credentials, and injects them directly into the request using libsigv4.

  3. No secrets on disk, ever

    The AWS CLI runs normally, but it never sees credentials. No ~/.aws/credentials file. No environment variables. No mounted volumes.

  4. Automatic rotation and refresh

    Credentials are scoped to a single request or short time window. They expire quickly and are automatically refreshed.

  5. Full auditability

    Every credential usage is logged: which workload, which process, which API call, when.

If you're familiar with our earlier credential injection posts, this is the same approach applied to development environments:

The difference is that here we're applying it to a local development environment on macOS, making secure, secretless workflows practical for everyday AI-assisted coding.

Why this matters for GitHub Copilot (and other AI coding tools)

GitHub Copilot excels at generating cloud infrastructure code. But it can't solve the credential problem—it just makes it worse:

Workflow Without Riptides With Riptides
Copilot generates AWS code You manually configure credentials Credentials are injected automatically when the code runs in a jailed environment
Copilot writes Terraform You mount ~/.aws into your VM No credential configuration needed; run in an isolated VM
Copilot builds deployment scripts You copy secrets into environment variables Scripts execute securely in jail without ever seeing secrets
Result Slow, manual, error-prone credential management that negates AI gains AI-accelerated development with defense in depth and near-zero credential overhead

You get the productivity of AI code generation without the security risks of credential sprawl or running untrusted code with full system access.

Note: While this post focuses on GitHub Copilot in VS Code, the same pattern should work with other AI coding environments like Cursor, Continue, Cody, and similar tools that support remote development or SSH workflows.

Why Lima VMs?

Lima is a lightweight Linux VM manager for macOS. It provides:

Lima gives you fast, native-ish integration (file sharing, port forwarding, and shell access) while still running a full Linux kernel—so Riptides can load its kernel module (unlike many desktop container setups). It’s also relatively lightweight and automation-friendly thanks to declarative YAML configuration and CLI tooling.

Lima is ideal for running Riptides in development because Riptides operates at the kernel level, requiring a Linux environment where kernel modules can be loaded. On macOS, Lima provides exactly that.

Architecture overview

Architecture overview: macOS host (VS Code + Copilot via Remote-SSH) into a Lima VM running jailed AWS CLI/Terraform with Riptides agent + kernel module injecting credentials

How requests flow:

  1. VS Code on macOS connects to the Lima VM via Remote-SSH
  2. You use Copilot to generate code/commands, and run tools like AWS CLI and Terraform inside the VM
  3. AWS CLI / Terraform attempts an HTTPS request to AWS APIs (for example ec2.amazonaws.com)
  4. The Riptides kernel module intercepts the connection
  5. The Riptides agent:
    • Verifies the process identity
    • Fetches short-lived AWS credentials (via federation or local provider)
    • Passes credential material to the kernel module
  6. The Riptides kernel module:
    • Signs the HTTP request using libsigv4
    • Injects the signed headers into the request
  7. The request proceeds to AWS, fully authenticated
  8. AWS CLI / Terraform receives a successful response — without ever seeing credentials

Setting up Lima with Riptides

Prerequisites

You’ll need macOS with Homebrew, Lima installed (brew install lima), and access to the Riptides kernel module + agent (currently closed source; contact Riptides Labs to request access—open source release planned for later in 2026).

Step 1: Start a Lima VM

Create a Lima VM configuration file riptides.yaml:

vmType: "vz"
os: "Linux"
arch: "default"

images:
  - location: "https://cloud-images.ubuntu.com/releases/24.04/release/ubuntu-24.04-server-cloudimg-amd64.img"
    arch: "x86_64"
  - location: "https://cloud-images.ubuntu.com/releases/24.04/release/ubuntu-24.04-server-cloudimg-arm64.img"
    arch: "aarch64"

cpus: 4
memory: "8GiB"
disk: "100GiB"

mounts:
  - location: "~"
    writable: true
  - location: "/tmp/lima"
    writable: true

provision:
  - mode: system
    script: |
      #!/bin/bash
      apt-get update
      apt-get install -y build-essential curl git awscli
      snap install terraform --classic

containerd:
  system: false
  user: false
Enter fullscreen mode Exit fullscreen mode

Start the VM:

limactl start riptides.yaml
Enter fullscreen mode Exit fullscreen mode

Step 2: Install Riptides

Once you have access to the Riptides repository, install via apt inside the Lima VM:

limactl shell riptides

# Add Riptides repository (provided after contacting Riptides Labs)
# Install Riptides (includes kernel module, agent, and systemd service)
sudo apt-get update
sudo apt-get install riptides

# Verify the kernel module is loaded
lsmod | grep riptides
Enter fullscreen mode Exit fullscreen mode

Step 3: Connect VS Code Remote-SSH

To use GitHub Copilot in the Lima VM, connect via VS Code Remote-SSH. Lima VMs integrate seamlessly with VS Code Remote-SSH—see the Lima VS Code integration guide for more details.

Add the SSH config to your ~/.ssh/config:

limactl show-ssh riptides >> ~/.ssh/config
Enter fullscreen mode Exit fullscreen mode

Then connect via the VS Code Command Palette (Remote-SSH: Connect to Host).

Connecting to Lima VM via VS Code Remote-SSH

For other AI coding tools: Environments like Cursor, Continue, and Cody that support SSH remote development should work with the same configuration.

Step 4: Configure Riptides workload identities

To enable secretless AWS access, configure Riptides to recognize AWS CLI and Terraform processes and inject credentials automatically.

Define the AWS service

Create a Service resource that matches all AWS API endpoints:

apiVersion: core.riptides.io/v1alpha1
kind: Service
metadata:
  name: amazonaws
  namespace: riptides-system
spec:
  addresses:
  - address: "*.amazonaws.com"
    port: 443
  external: true
  labels:
    svc:name: amazonaws
Enter fullscreen mode Exit fullscreen mode

This tells Riptides to intercept HTTPS connections to any *.amazonaws.com domain.

Configure workload identity for AWS CLI

Create a WorkloadIdentity for the AWS CLI process:

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: awscli
  namespace: riptides-system
spec:
  workloadID: awscli
  connection:
    tls:
      intercept: true
  scope:
    agent:
      id: riptides/agent/local-copilot-lima
  selectors:
  - process:name: aws
Enter fullscreen mode Exit fullscreen mode

This configuration:

This assigns identity to any process named aws, enables TLS interception so Riptides can inject credentials into HTTPS requests, and scopes the rule to the Lima VM agent (local-copilot-lima).

Configure workload identity for Terraform

Similarly, create a WorkloadIdentity for Terraform:

apiVersion: core.riptides.io/v1alpha1
kind: WorkloadIdentity
metadata:
  name: terraform
  namespace: riptides-system
spec:
  workloadID: terraform
  connection:
    tls:
      intercept: true
  scope:
    agent:
      id: riptides/agent/local-copilot-lima
  selectors:
  - process:name: terraform
Enter fullscreen mode Exit fullscreen mode

With these workload identities in place, both AWS CLI and Terraform processes receive:

With these workload identities in place, both AWS CLI and Terraform gain identity-scoped credential injection, per-process connection telemetry (domain/port/protocol), automatic SigV4 signing, and better audit context (Riptides records workload identity + process details while CloudTrail records the resulting AWS API calls).

Complete the credential binding

After defining these resources, create an AWS CredentialSource and WorkloadCredential, then reference that credential from the WorkloadIdentity egress rule (as shown in our AWS credential injection guide). For AWS IAM trust relationship setup (OIDC + subject mapping), see Federating non-human identities with external IdPs.

Configure AWS CLI for TLS interception

Since Riptides intercepts TLS connections to inject credentials, you need to configure the AWS CLI to trust Riptides' CA certificate. Create or update ~/.aws/config:

[default]
output = json
region = eu-west-1
ca_bundle = /sys/module/riptides/certs/ca-certificates.crt
Enter fullscreen mode Exit fullscreen mode

The ca_bundle points to the CA certificate that Riptides uses for TLS interception. (Depending on install/version, you may instead set AWS_CA_BUNDLE to a path like /sys/kernel/riptides/ca-certificates.crt.)

Using secretless AWS access in the Lima VM

Once Riptides is running, AWS CLI commands work without any credential configuration:

# No ~/.aws/credentials file
# No AWS_ACCESS_KEY_ID env var
# Just run AWS commands

aws ec2 describe-instances
Enter fullscreen mode Exit fullscreen mode

Behind the scenes:

  1. Riptides detects the aws process execution
  2. The agent matches it against configured rules
  3. The process is assigned a workload identity based on its runtime attributes
  4. As the AWS CLI makes HTTPS requests, Riptides intercepts them
  5. Short-lived credentials are injected into the request at the kernel level
  6. The request proceeds to AWS, fully authenticated
  7. The AWS CLI receives the response — never knowing credentials were involved

Real-world GitHub Copilot workflows with Riptides

These examples show how GitHub Copilot works seamlessly with Riptides—generating code that executes securely in a jailed environment without credential configuration.

(Here, “jailed” refers to running inside the Lima VM; Riptides’ core contribution is secretless, identity-scoped credential injection and per-process visibility.)

Copilot-generated Terraform workflow

Ask GitHub Copilot: "Help me query my EC2 instances with Terraform"

Copilot can help generate the AWS CLI command to list your instances:

GitHub Copilot generating EC2 list command

First, list your existing EC2 instances:

EC2 instances listed without any credential configuration

Copilot can help generate the Terraform configuration. Create main.tf:

Copilot generating Terraform configuration

# No credentials configured - Riptides injects them automatically
provider "aws" {
  sts_region = "us-east-1"
}

# Query all running EC2 instances
data "aws_instances" "running" {
  filter {
    name   = "instance-state-name"
    values = ["running"]
  }
}

# Get details for each instance
data "aws_instance" "details" {
  for_each    = toset(data.aws_instances.running.ids)
  instance_id = each.value
}

# Output instance information
output "instances" {
  value = {
    for id, instance in data.aws_instance.details : id => {
      id            = instance.id
      instance_type = instance.instance_type
      ami           = instance.ami
      private_ip    = instance.private_ip
      public_ip     = instance.public_ip
      tags          = instance.tags
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Run Terraform:

terraform init
terraform plan
terraform apply

# View the discovered instances
terraform output -json instances
Enter fullscreen mode Exit fullscreen mode

After running the Terraform workflow, the Riptides UI shows exactly how many times credentials were injected for Terraform. In this example, you can see that the UI displayed 9 credential injections for the Terraform process:

Riptides UI showing 9 credential injections for Terraform

Key point: Notice there's no credential configuration anywhere in the Terraform code or environment:

Key point: Notice there's no credential configuration anywhere in the Terraform code or environment—no ~/.aws/credentials file, no AWS_ACCESS_KEY_ID environment variable, and no credential blocks in the provider configuration. It’s just a plain provider with a region.

Terraform executes successfully because Riptides intercepts AWS SDK calls from the Terraform binary and injects credentials transparently at the kernel level.

The key difference: With Riptides, you can use Copilot to generate infrastructure code at full speed, then run it immediately in a jailed VM—no credential setup interrupting your flow, and no risk of the generated code accessing credentials it shouldn't.

You can confidently run AI-generated code knowing the VM jail restricts filesystem access, no credentials exist to leak, and even if Copilot generated code with unintended side effects, the blast radius is minimal.

Key benefits for AI-powered development

Security without friction, at AI speed

Riptides removes credential management from the loop: you never copy/mount/configure AWS credentials (even for Copilot-generated code), and you don’t need application changes—CLI commands, scripts, and Terraform configs just work. Protection is automatic for configured AWS-calling processes, so the flow becomes generate → run in jail → iterate without pausing to wire up secrets. The payoff is peace of mind: AI-generated code runs in an isolated environment with zero credential access.

Better collaboration

With no embedded secrets, VM templates can be shared, versioned in git, and distributed safely. Onboarding gets faster (less “here’s how to set up your AWS credentials” documentation), and teams get more consistent dev environments.

Improved auditability

Riptides logs which process made which call and makes it practical to correlate workload/process context with CloudTrail. Unexpected processes reaching for AWS APIs become visible, logged, and easier to investigate.

Complete network observability

Riptides provides real-time visibility into every network connection from your development environment.

Riptides UI showing network connections

See exactly which processes connect where: GitHub Copilot's Node.js runtime to api.individual.githubcopilot.com:443, AWS CLI to AWS service endpoints, Terraform to AWS APIs—all in real-time with full process-level detail. Essential for verifying AI-generated code behavior before trusting it.

Beyond Lima: Apply this pattern anywhere

While this post uses Lima VMs on macOS with GitHub Copilot as a concrete example, the same pattern applies to:

Docker containers (no more -v ~/.aws:/root/.aws mounts), remote dev servers over SSH, CI/CD pipelines, Kubernetes dev clusters, and cloud IDEs like Codespaces/Cloud9/Gitpod can all benefit from the same idea. In practice, it should also work with other AI coding environments (Cursor, Continue, Cody, etc.) as long as they support SSH or remote development.

The core principle remains the same: jailed environments + workload identity + zero credentials = AI code you can run confidently.

Conclusion

Development environments are often the weakest link in cloud security. Credentials get copied, mounted, committed to git, or left lying around in VM snapshots.

Riptides eliminates this problem by bringing the same secretless, identity-based security model that we've demonstrated for production workloads (AWS, GCP, OCI) to local development environments.

Key takeaways:

Key takeaways: AWS CLI, Terraform and other tools work without credential configuration—whether you wrote them or Copilot did. Isolation and credential injection are enforced at the OS/kernel layer (not in application code), the generated scripts/configs run unchanged in jailed environments, and credential usage becomes auditable with process-level detail. Most importantly, Copilot’s productivity isn’t throttled by credential setup, and you can run AI-generated code with confidence because credentials never exist in the environment.

Whether you're using Lima VMs, Docker containers, remote SSH sessions, or cloud-based development environments, Riptides provides a path to secretless development that doesn't compromise productivity.

Learn more

Top comments (0)