Tines 3B keeps API keys out of AI hands: a real teardown
The problem with vibe-coding isn’t getting the AI to write working software. That part is mostly solved. The problem is what happens when that software needs to talk to something real: a database, an API, a SaaS you actually pay for. Credentials end up in a .env file, in a repository, or in a Supabase instance with a misconfigured auth rule. Roughly one in ten of 1,645 apps published to Lovable’s marketplace turned out to be leaking user data through an authorization flaw. That’s not a hypothetical risk. It’s the current state of the ecosystem.
Tines has taken a different approach with 3B, which feels less like a product update and more like a ground-up rebuild of the platform around one security principle: the AI never reads a credential. I’ve been using it to build three projects for my home lab and tested where its model breaks down. Here’s what I found.
️ What Tines 3B Is
3B is Tines’s new workflow automation platform built around AI coding. The old platform, Tines Stories, still exists, and there are supported migration paths from it. In 3B, you describe what you want, and the platform builds it for you as a set of containerized steps that talk to external services.
I built three things to test different aspects of the platform: a rental property tracker, a product price watcher, and a home lab monitoring dashboard. The dashboard ended up as a six-step application with a two-minute cron collector, a stateful evaluator that emails once per ongoing problem rather than once per poll, two API endpoints, and a React dashboard with trend charts and a threshold editor. The whole thing took about twenty minutes including back-and-forth to get a working first version.
Every step in a 3B workflow lives in its own subfolder with its own code, a config.toml, and its own Dockerfile. Each step is genuinely its own container. The collector and evaluator in my dashboard are Python on a standalone CPython build with dependencies managed by uv. The email step and both API endpoints are TypeScript on Bun. The dashboard is React bundled with Bun and styled with Tailwind at build time. 3B chose all of that. Steps talk to each other over stdin and stdout. If one step links to three others, all three get the same input and run in parallel.
How the Credential Model Works
In 3B, credentials live in something called a connector. Connectors are configured separately from any workflow. When a step makes an outbound request, the credential is injected into that request by a proxy sitting outside the execution environment entirely. The code never reads the credential and can’t print it even if prompted.
This is what the TrueNAS adapter that 3B wrote for me actually looks like at the top:
"""TrueNAS SCALE adapter.
Credentials are injected by the connector attached to this step, so requests are
made plain.
"""And then it makes plain HTTP requests:
req = urllib.request.Request(
base_url + path,
data=data,
method=method,
headers={"Content-Type": "application/json"},
)The auth only appears in transit. The code has nothing to exfiltrate. A model that gets prompt-injected by a page it fetched can use a credential’s authority to call a permitted service, but it can’t read the credential itself. On top of that, each connector has an allowlist of URLs it can reach. The Gmail connector, for example, only permits the two Google hosts that Gmail actually uses, scoped to Gmail’s own API paths, rather than waving through all of googleapis.com.
Tines has 1,032 connectors available. Around 85% inject a static secret (bearer token, header, basic auth, or query string). Another 54 fetch a token first and then use it. The remaining 53 hand off to named schemes that handle cryptography with the secret never leaving the proxy, including awsSigV4, oauth1HmacSha1, Akamai’s EdgeGrid signing, LDAP binds, and native Postgres, MySQL, and MongoDB auth.
The Runtime: gVisor, Not Docker
Tines says cross-contamination between runs or users is architecturally impossible. A standard Docker container wouldn’t get you there. Docker gives a workload namespaces and cgroups, which is a fence around a process that’s still making system calls into the same kernel its neighbors are using.
The actual runtime is a custom environment built on top of gVisor, Google’s sandbox runtime, with credential injection handled at runtime. gVisor implements a kernel in userspace that sits between the workload and the real kernel, so system calls get intercepted and serviced by that layer instead of being passed straight through. The amount of host kernel a hostile step can touch shrinks significantly as a result.
Tines has also been contributing upstream to gVisor. At the time of writing there are sixteen pull requests from them, covering a warm sentry mode for faster restore cycles, checkpoint and restore support for host networking, composable seccomp filters, and extension hooks for custom filesystem gofer backends. It’s not the same as giving every step its own VM, and a gVisor bug is still a real scenario, but it’s substantially more than a standard container.
Connecting to a Home Lab Without Port Forwarding
Reaching local machines from Tines’s cloud normally means port forwarding, a reverse proxy, or a VPN. 3B’s answer is a small container you run on your local network. It’s a Chainguard base image running as a non-root user, publishes no ports, and the entire application is a single 4.5MB static binary. There’s no ip command inside it.
The container connects to a gateway on a subdomain specific to your tenant and authenticates with mutual TLS using a client certificate issued by a private CA. Nothing needs to reach in, and no firewall rules need to change. There’s no VPN interface either: the container has no NET_ADMIN capability and no TUN device, so it can’t create a network interface. It’s a userspace proxy that dials out and forwards only what it’s allowed to forward. A variable called DESTINATION_CIDRS defines the allowed subnets. Mine reads 192.168.1.0/24,192.168.2.0/24.
Where the Model Breaks: the Ugreen NAS
Three of my hosts connected without much trouble. One didn’t: a Ugreen NAS running UGOS. The authentication flow requires three moves: request a public key from the device, RSA-encrypt your password with that key, post it back, and receive a session token. 3B analyzed the Home Assistant integration for UGOS, read the flow correctly, and explained the padding scheme and the key header format. Then it told me it couldn’t proceed.
The reason is the point of the whole system. RSA-encrypting a password requires having the password available inside the execution environment. That’s exactly what the 3B security model prevents. The proxy can inject a static credential or handle named signing schemes, but it can’t perform arbitrary cryptographic operations on a secret that the code needs to see first.
Tines confirmed that fully custom auth schemes aren’t supported at the moment, though it’s something the company is looking at. The architecture isn’t fundamentally incompatible with this kind of authentication; it just doesn’t have a connector for it yet. In the meantime, SSH is a workaround. Every mainstream service you’d actually want to automate is covered.
You Own the Code: Portability and the Export
You can download all the code 3B generates for any project. What you get is ordinary Python and TypeScript with its own requirements.txt and package.json. The exported code makes plain HTTP requests and expects something else to attach credentials, so you can’t run it untouched outside of Tines. But fixing that is exactly the kind of task an AI coding tool handles well: tell it to read credentials from environment variables and add whatever auth headers each service needs, and it’s running outside Tines quickly.
The export also includes a CLAUDE.md in the root that points to AGENTS.md, which is a 382-line specification of the entire platform written for a coding agent to read. Every project also ships with its own README, including a Mermaid diagram of the flow and a table showing which hosts are live and which aren’t. The home lab dashboard export is published on GitHub if you want to read through how it’s built.
Branches in 3B map one-to-one with git branches. A draft gets an isolated copy of persistent storage, so testing a change doesn’t affect what’s running. There’s also a self-healing feature with two distinct parts: Autofix watches execution logs and builds a branch containing a fix when it sees consistent errors, while Autotune does the same for optimizations. Neither touches what’s currently running. You get what is essentially a pull request to review, discard, or merge.
MCP Publishing and the AGENTS.md Design Choice
Workflows can publish themselves as MCP servers. You set an authentication level on a route, describe the tool in plain English, have it built, and then connect it to Claude, ChatGPT, or any compatible assistant. That’s a useful loop for solo operators who want to build tools and surface them directly in their AI assistant of choice.
The AGENTS.md design decision is worth noting on its own. It instructs the model not to ask non-technical users technical questions. Instead of asking them to pick volume scope, concurrency, exclusive writers, or branch state, it’s instructed to ask what should happen to the data, who owns it, and who needs to update it. The platform is built for both engineers and non-engineers, and it manages that without dumbing down the technical interface.
️ Pricing
The free tier is called Explore. It includes:
- Unlimited users
- Unlimited spaces
- Unlimited connectors
- Three live workflows
- The home lab tunnel (no longer Cloudflare-based)
- A one-time $50 AI credit allowance
The $50 credit can’t be topped up. After it’s used, you bring your own model. Tines expects most free-tier users to connect Claude or ChatGPT subscriptions they already pay for, which keeps Explore working indefinitely. Public-facing URLs aren’t available on the free plan, meaning you can’t publish a 3B-built tool to the open internet, though anyone in your tenant can still reach it.
The first paid tier starts at six figures. Tines is direct about 3B being an enterprise product priced as one. There’s no growth path for individuals or small teams between the free plan and a signed contract. For most operators, the free plan is where they’ll live, and given the three live workflows plus bring-your-own-model, that’s genuinely usable.
The Verdict
The credential isolation model is the most coherent answer to the vibe-coding security problem I’ve seen. Injecting credentials via proxy at runtime, scoping each connector to an allowlist of URLs, and running steps on a gVisor-based sandbox rather than bare Docker are decisions that compound into something meaningfully more trustworthy than the current default. The Ugreen NAS failure is actually the clearest proof that the model is real: it failed because the security constraint is real, not because of a bug.
The six-figure entry price for paid tiers is a hard stop for solo operators and small teams. But the free tier is honest about what it is. Three live workflows with bring-your-own-model and a working home lab tunnel is a real setup, not a crippled demo.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
