How to give an AI coding agent production access (without giving it your kubeconfig)

Published 2026-05-08 by tavin

The naive way to let an AI coding agent ship to production is to hand it the same credential a human operator would use:

~/.kube/config
a long-lived cloud API key
a CI service account token
a .env file the agent can read

Each of those works on day one. Each of them is the wrong shape on day thirty, when the agent has accidentally deleted a namespace, exfiltrated a secret, or fanned out a credential into seventeen log files.

This post is about the better shape: narrow, revocable, audited authority that lets an AI coding agent ship a service without inheriting your entire cluster.

The argument applies to any platform. The examples are from tavin.cloud because that is what we ship.

The threat model is “agent does the wrong thing,” not “agent goes rogue”

The interesting agent-security threats are not “the model spontaneously decides to harm you.” They are the boring failure modes a junior engineer might also hit:

Misreads a prompt and runs the destructive command on production instead of staging.
Pastes a secret into a logged tool call.
Reuses a credential across tools that should not share authority.
Loses track of which environment a session is in.
Triggers a deploy from a stale branch.
Cannot distinguish “I tried to do X” from “I successfully did X” because the platform output was unstructured.

A long-lived kubeconfig with cluster-admin makes every one of those failure modes worse. The fix is not “trust the agent more” — it is “narrow the authority and structure the surface.”

The four credential shapes worth knowing

Most platforms expose some subset of these. They differ in important ways.

The agent goes through an OAuth flow. The user authenticates in the browser, sees a consent screen listing the scopes the agent is requesting, and approves.

Properties:

The agent receives a scoped access token.
The token can be revoked from the user’s account settings.
Every API call lands in audit rows tied to the user and the OAuth client.
The user’s primary password and dashboard cookie never leave the browser.

This is the right default for an agent operating on behalf of a logged-in user — interactive coding sessions, IDE plugins, browser-based agent UIs. tavin.cloud’s MCP server supports OAuth.

2. Personal Access Tokens — headless, named, revocable

A PAT is a long-lived token a user creates explicitly. Each PAT has:

A human-readable name (agent-staging-deploy, ci-prod-readonly).
A scope (read-only, deploy, env-write, …).
An audit trail of every call made with it.
An independent revocation knob — deleting the PAT does not log the user out.

This is the right default for headless workflows: CI pipelines, scheduled jobs, agents running in environments where an interactive OAuth flow is not practical.

The important rule: one PAT per workflow. Do not reuse the same PAT across CI and a coding agent and an internal cron. When something goes wrong, “rotate this PAT” should be a precise action, not a coordinated rollout.

On tavin.cloud you create a PAT with tavin tokens new <name>; the CLI docs cover the full surface.

3. Deploy intents — pre-account, status-only

Sometimes the agent does not yet have any account on the platform — it is acting on behalf of a user who has not signed up. The naive answer is “create the account for the user with stored credentials,” which is exactly the wrong shape.

A better shape is a one-time deploy intent:

The agent creates a deploy intent describing the repo, branch, and build plan.
The agent gets a status-only token tied to that one intent.
The platform sends the user an approval URL.
The user opens the URL, signs in or signs up, reviews the intended deploy, and approves.
The platform creates the project and starts the deployment.
The agent polls status with its status-only token. It cannot mutate anything else.

The agent has just enough authority to drive the workflow. The user retains the binding decision. The credential cannot be repurposed. We covered the shape in agent-safe deployment is the wedge.

4. Long-lived broad credentials — wrong default

This is the kubeconfig case, the cloud-account-API-key case, the dashboard-cookie case. It works. It is also the credential shape that produces the worst incident reports.

Use it when:

The agent is operating on infrastructure you control end-to-end.
The blast radius is genuinely small (a single namespace, a single project, a sandbox cluster).
You have a clear revocation plan and the rotation is cheap.

Avoid it when the agent is operating across environments, services, or accounts you would not hand a new junior engineer on day one.

What “narrow authority” means in practice

A scoped credential is not just “fewer permissions on a token.” It is a set of design choices the platform has to make jointly with you.

Tools, not commands

If the agent can call run_arbitrary_kubectl(yaml), you do not have a scoped surface — you have a kubeconfig with extra steps. Real scoping means the platform exposes structured operations: deploy_project_source, set_env, wait_for_deployment, roll_back_deployment, get_deployment_runtime_logs. The agent operates over typed product operations, not a cluster shell.

This is why a well-designed MCP surface matters: the protocol forces tools to be named and typed.

Approval handoffs for irreversible actions

Some operations should never be agent-initiated without an explicit human in the loop:

Deleting a project.
Rotating a domain.
Connecting a new payment method.
Granting another user admin access.

A good platform treats these as explicit approval handoffs. The agent can prepare the action; a human approves in the browser. The agent never needs the credential that would have let it skip the approval.

Audit that an incident response team can actually use

An audit row that says POST /v1/deployments is not useful at 3 a.m. A useful audit row says:

Which user the action was on behalf of.
Which credential was used (OAuth client, PAT id, deploy intent id).
Which agent client made the call (Claude Code, Cursor, Codex, custom script).
Which project, service, deployment, env var, or domain was affected.
What the actual change was (diff of env vars, before/after deployment status).

If you cannot reconstruct “what did the agent do, on whose behalf, with which credential, between 02:00 and 04:00?” from the audit log, the audit log is incomplete.

Revocation that does not break the user

When something goes wrong, the human-in-the-loop should be able to revoke the agent’s credential without logging themselves out, breaking other agents, or rotating shared secrets. Per-credential revocation is the difference between a five-minute incident and a four-hour one.

A worked example on tavin.cloud

A team using Claude Code for backend work wants the agent to be able to:

Deploy the staging branch.
Set or read environment variables in staging.
Tail logs to debug a failure.
Promote a deploy to production only after a human approves.

A reasonable credential layout:

Credential	Scope	Used by
OAuth (interactive)	Full account, scoped to the team’s projects	Claude Code in the developer’s editor
Per-project PAT (`agent-staging`)	Deploy + env-write on the staging service	Headless scripts the agent runs
Per-project PAT (`agent-prod-readonly`)	Read deployments and logs on prod, no mutate	Agent investigations against prod
Deploy intent	Status-only on a single intent	Agent helping a teammate sign up + deploy a new service

There is no kubeconfig. There is no shared “agent token.” The production deploy still requires an explicit human action; the agent prepares it, the platform asks the human, the human approves. The agent’s other credentials cannot be repurposed to skip that step.

The CLI for managing these is in the tavin.cloud CLI docs; the MCP tool catalog is in the MCP guide.

What this is not

It is not a claim that AI agents are now safe to operate production. They are still software with non-zero failure rates. The argument is narrower: with the right credential shapes, an agent’s failure modes look like a junior engineer’s failure modes — bounded, recoverable, observable — instead of like a leaked cluster-admin token.

The platform’s job is to make the safe path the obvious path. The agent’s job is to ship the change. The user’s job is to retain the binding decisions.

Concrete starting points

If you are building an agent workflow against an existing platform:

Stop reusing your dashboard cookie. Issue a per-workflow credential.
Stop reusing one PAT for everything. Name them, scope them, and revoke them aggressively.
Insist on structured tool output. If your agent has to parse colorized terminal logs to know whether a deploy worked, your platform is the bottleneck.

If you are building a deployment platform:

Ship OAuth, scoped PATs, and one-time deploy intents. All three.
Expose product operations through MCP, not a run_command shell-in-a-tool.
Make audit rows incident-grade. “Who did what, on whose behalf, with which credential” is the minimum bar.

If you want to try the tavin.cloud version of this: the quickstart gets you a live URL, the MCP docs cover OAuth and PAT setup, and the CLI docs cover token management. The deploy-intent flow is described in the AI agent deployments doc.

The shape worth aiming for is simple: an agent that can ship code, and a credential model that makes “what did the agent do?” a one-query answer.