AWS Builder Center

Builder Center

AIdeas: FTL, a Zero-trust Execution Layer for Coding Agents

AIdeas: FTL, a Zero-trust Execution Layer for Coding Agents

FTL is THE zero-trust execution layer for AI coding agents. Run your coding agent inside a sandbox environment with shadow credentials, parallel adversarial testing, and human-in-the-loop approval without ever giving the agent access to your real secrets or filesystem. Security, faster than light.

Vishnu Vennelakanti

developer
Category: Commercial Solutions
YOU CAN TRY OUT FTL HERE:
👉 github.com/vvennela/ftl | DOCS: https://vvennela-ftl-18-95.mintlify.app/introduction

My Vision:

Since the release of Claude Code, coding agents have taken off. Development is literally at the speed of thought and we're able to ship increasingly complex projects faster than ever. At large enterprises like Google, as much as 25% of code is being written wholesale by AI .
At the same time, coding agents have become a nightmare on the security front. We've all heard the horror stories: Claude Code ran rm -rf and deleted weeks of work, or Codex dropped a production database. Take a look at this developer's tweet from mere days ago:
To compound problems, developers are shipping code they don't read nor do they test. The creator of OpenClaw famously remarked: "I ship code I don't read." If this is the new normal, it's not just debt that accumulates, it's risk.
Here's the uncomfortable truth: every time you run Claude Code in your project directory, you're handing an AI agent your Stripe live keys, your AWS credentials, your database passwords, and write access to your entire codebase.
We've been trusting agents we built specifically not to trust.
FTL fixes that.
Introducing FTL, an open-source, provider-agnostic, zero-trust execution layer.
FTL is a control plane for AI coding agents. It wraps Claude Code, Codex, Aider, or Kiro in an isolated Docker sandbox and enforces four guarantees:
  1. Your real API keys never enter the sandbox. Shadow credentials replace them.
  2. The agent never touches your real filesystem. Everything runs in an isolated container.
  3. Adversarial tests run in parallel while the agent codes at zero added latency.
  4. Nothing merges without your explicit approval. Every change goes through a human diff review.
1
ftl code "build a login component"
That's it. That's all you need to type, FTL handles the rest.

Why this matters

AI agents and model providers have already won the productivity argument. The question is no longer whether to use coding agents; it's whether you can use them without accepting risks that would have been unthinkable two years ago.
Right now, all coding agents require your implicit trust: the agent gets your filesystem, your environment variables, and your secrets, and you hope it doesn't do anything catastrophic. Security wise, this forces you into the backseat of your own project!
For individual developers, the stakes are high: a leaked Stripe key or an accidental deletion of the database can destroy months of work. Enterprises may fail to meet compliance standards due to the unsafe nature of coding agents. When something goes wrong, nobody can answer the questions that matter: what did the agent access, what did it produce, who approved it, and can we prove it?
No current coding tool answers those questions as they're built for developer productivity, not team accountability.
FTL is built for the world where AI-assisted development is the default and where that means security, auditability, and human oversight can't be afterthoughts. FTL exists so that when your CTO asks "what did our agents do last quarter," you have an answer.

What I built:

When you run a task, FTL runs a precise pipeline:
  1. SNAPSHOT: FTL takes a snapshot of your project state. This enables Git-style rollbacks and ensures the agent starts from a known-good baseline every time.
  2. BOOT: FTL spins up a project-scoped, persistent sandbox. By reusing warm containers, FTL achieves sub-second startup times while maintaining isolation between different development projects.
  3. INJECT: FTL automatically scans for .env and secret files, replacing real keys with "Shadow Credentials."
  4. CODE + TESTING: FTL runs two models in parallel. While your coding agent (Claude Code, Codex, etc.) generates logic, a separate adversarial model (e.g., Amazon Nova) generates unit and integration tests in parallel.
  5. RUN TESTS + CODE REVIEW: The moment the agent finishes, tests execute. FTL’s HTTPS proxy intercepts shadow credentials and hot-swaps them with real secrets at the network boundary. You get a verified API integration without the agent ever "knowing" the real key. An optional step here is the "reviewer" which does a security scan and analyzes if the code generated adheres to the prompt.
  6. LINT: A static analysis layer scans for destructive commands (eg dropping tables, file deletes) and PII information.
  7. DIFF: FTL provides a comprehensive, file-level Git diff.
  8. MERGE: A human reviewer can interrogate the agent about its changes, request edits, or merge the verified sandbox code back to your local system with a single command.
The agent runs entirely inside Docker. It never sees your real API keys or your host filesystem. Nothing touches your project without explicit approval.
Here's a quick demo of how FTL works:

1. The Core Innovation: Shadow Credentials

When you run a task, FTL reads your .env file and generates fake shadow values before your sandbox (and therefore your agent) even boots.
1
2
3
4
5
6
7
# Your .env (never enters the container)
STRIPE_SECRET_KEY=sk_live_abc123
OPENAI_API_KEY=sk-proj-xyz789

# What the agent sees inside the sandbox
STRIPE_SECRET_KEY=ftl_shadow_stripe_secret_key_7f8a2b3c
OPENAI_API_KEY=ftl_shadow_openai_api_key_4d9e2a1f
The agent writes production-quality code with these shadow credentials. If it accidentally hardcodes one, FTL's credential linter catches it before you even see the diff.
For features that require testing, FTL's network proxy layer catches requests, swaps the shadow values with the real values in the .env file at the HTTP layer. So, you can verify that your Stripe integration or OpenAI call works correctly, while never exposing your true secrets.
1
2
3
Container sends: Authorization: Bearer ftl_shadow_stripe_secret_key_7f8a2b3c
Proxy rewrites: Authorization: Bearer sk_live_abc123
Stripe receives: Authorization: Bearer sk_live_abc123 ✓

2. Zero latency testing

While the agent is writing code, FTL simultaneously generates adversarial tests using a separate model. The tester doesn't see the implementation; it only sees the task description, which forces it to think like an attacker:
"Generate adversarial tests for this task. Focus on edge cases, null inputs, boundary conditions, and unexpected usage. Your goal is to find bugs."
Because tests generate in parallel, they're ready the instant the agent finishes writing code. You waste zero time for test-generation.
The moment the agent completes, FTL runs the tests automatically. Test failures are surfaced before you even see the diff, giving you a second opinion from an adversarial model that had no stake in the implementation.

3. The Human Review Gate

After the agent finishes and tests run, FTL shows you a complete Git-style file-level diff and waits:
1
2
3
4
19 file(s) changed | +1050 insertions | -0 deletions | 19 created | 0 modified | 0 deleted

[A]pprove [R]eject [Q]uit or ask a question
>
You can ask the model questions directly in the review prompt and get an answer before committing. Nothing touches your real project until you type a.
The diff is computed inside the Linux container against the snapshot, not through Docker's VirtioFS layer, keeping it fast even on large projects.

AWS Integrations for Teams who want to ship safe code:

For individual developers, FTL locally works out of the box. But for teams, AWS integration transforms FTL from a personal sandbox into a full governance and audit layer for AI-assisted development.
Think about what a security engineer or team lead actually needs when their developers are shipping AI-generated code:
  1. What can agents access? AWS Secrets Manager centralizes secrets. No developer has production keys in a .env file. FTL pulls credentials from Secrets Manager at session start and the shadow credential system takes over from there.
  2. What did agents produce? Bedrock Guardrails hard-blocks any diff containing credentials or PII before a human even sees it. The security team configures the policy. Developers can't override it.
  3. What did agents actually do? CloudWatch Logs emits a structured, immutable audit trail of every session: every tool call, every file touched, every task approved or rejected, across every developer on the team.
  4. What actually merged? The human approval gate is non-bypassable. Every change that reached production had a human sign off on it.
Every FTL task begins with a snapshot. For individual developers, snapshots can be stored locally but for teams, you can configure S3 as the backend. Configuring S3 as the snapshot backend gives you three things local snapshots can't:
Durability: A snapshot is a point-in-time record of exactly what your project looked like before an AI agent touched it.
Portability: With S3 snapshots, a developer can start a task on their laptop and continue it on a remote dev box.
Team visibility: Combined with CloudWatch tracing, S3 snapshots give you the full picture: the audit log tells you what the agent did, and the snapshot tells you what the project looked like when it did it. Together that's a complete forensic record of agentic development on your team.
This is a level of auditability and traceability that no other coding agent at present offers. Cursor, Codex, not even Kiro-CLI give you in-depth analytics for software development.

FTL is incredibly customizable

One of FTL's core advantages is that it is modular. For instance, developers can set S3 as their backend and resume all development locally. FTL also allows to mix and match model providers as it is truly model-agnostic.
The coding agent supports three models: Claude Code, Aider, and GPT Codex. (Kiro-CLI is architecturally incompatible; see "What I Learned" below). The tester and reviewer support ANY LiteLLM compatible model.
The design principle: the agent that writes code should never be the same model that tests it. A genuinely different model attacking the implementation catches blind spots a single model would share with itself.

How I used Kiro

Kiro played a central role in FTL's development, specifically for adversarial test generation and automated code review. Rather than manually writing tests, I used Kiro to test FTL's own components: the shadow credential proxy, the diff computation, and the merge gate.
Kiro also helped me build the lint scanner and the adversarial tester. For the former, I used Kiro to analyze the CVE database, and the latter to refine the system prompt for the agent.
FTL, a tool used to safely run coding agents, was itself built and audited using one.

What I Learned

Open source is the only credible security claim. Any tool that asks you to trust it with your API keys, without showing you the code that handles them, is asking for faith you shouldn't give. The only way to say "your keys are safe" and mean it is to let anyone verify it.
Building FTL surfaced some sharp technical issues:
  1. Initially, I wanted to support Kiro-CLI as well for FTL, so that we can write safe code faster than light. But, I soon found out that Kiro-CLIs's architecture is incompatible with FTL. The agents that FTL supports are headless, which means that they run without a browser. Kiro CLI, on the other hand, is architecturally a thin IPC client that gets auto-started by shell integration sourced from bashrc. When FTL runs docker exec,kiro-cli chat crashes immediately. It's the same reason you can't run VS Code headlessly without the Electron client process already running. The "CLI" is a remote control for a desktop app, not a standalone tool. Claude Code was purpose-built for exactly this environment from day one, no daemon required. That's why it fits FTL's sandbox architecture naturally, and why it became the primary supported agent.
  2. Firecracker was the right idea, but Docker is the right tool. The original design called for Firecracker microVMs: AWS-built and sub-100ms boot time. The problem is Firecracker requires a Linux kernel, which makes local development and testing on my Macbook impossible. Rather than build something I couldn't test, I swapped to Docker. Docker is a bit slower (1-2s boot times), it still does the job well. Firecracker support for enterprise deployments is on the roadmap, and the S3 snapshot backend is already designed with remote execution in mind.
  3. My original design included a planner, but I decided to switch to a reviewer instead. The original design included a planning step before code generation, where a model would interpret intent and structure the task before the agent started. In practice, agents usually have sophisticated internal planners that outperform anything I'd build on top. Adding a planning layer created latency without adding value. Rather than plan the input, an AI reviews the output: running in parallel with test execution to produce a plain-English change summary, a security scan, and a prompt adherence check: did the agent actually do what you asked? By the time tests finish, the review is ready. The human sees not just a raw diff but a complete picture of what changed, what looks risky, and whether the agent followed the task. Net latency addition: zero.

What's Next for FTL

I plan to add these three features to further boost FTL's value proposition:
  1. Firecracker sandbox backend. Docker works well for individual developers, but enterprise teams need sub-100ms boot times and hardware-level isolation. Firecracker microVMs are the right answer. The S3 snapshot backend is already designed with remote execution in mind, so the infrastructure is ready when the runtime is.
  2. Remote execution. Run FTL in the cloud, from any machine, anywhere. A cloud sandbox that initializes fast is useful for CI/CD teams and pipelines that want fully centralized agent execution with no local Docker overhead.
  3. Multi-agent parallelism. This is where the planner comes in. Multi-agent parallelism would allow multiple agents to take on a task, which would greatly speed up development time. The planner fans out independent subtasks to multiple agents simultaneously, merging results through the same approval gate.
  4. IDE integration. There are still developers who rely on IDE development who want secure, safe code. FTL as a VS Code extension would enable developers to still take advantage of AI productivity gains.
My north star: FTL's end goal is a natural language interface for your computer. FTL should be able to execute tasks such as "write some code, change my playlist, push it to github and send brian a slack that the pull request is live" by decomposing each command into a series of tasks. Coding tasks go through the full pipeline. Tool actions go through a lightweight approval step. The human stays in the loop at every stage, but the cognitive overhead of orchestrating across tools disappears.
FTL isn't just a safer way to run coding agents. It's the foundation for a natural language interface to your entire development workflow.
# aideas-2025# commercial-solutions# NAMER
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article