Giving AI agents infrastructure access safely

The problem with sharing your credentials

AI coding agents are useful for infrastructure work: reading how a stack is wired, noticing that a webhook is missing, writing the config change and the code that goes with it. The simplest way to let one help is to let it use whatever you use: your shell, your CLI login, your provider keys.

That's also the risk. An agent running in your terminal can read any file you can, including a CLI's stored token, and run any command you can, including the ones with --yes. A "are you sure?" prompt in a terminal proves nothing to a server, because the agent can answer it. If the same credential that lets the agent look also lets it change production, the only control left is the agent's judgement.

Ahena's approach is to separate the two: an agent gets enough access to understand and propose, and the changes that matter need something the agent doesn't have.

Agent sessions: what an agent can and can't do

Agents reach Ahena through ahena mcp, an MCP server that runs on your machine, in your project directory, over stdio. It doesn't use your CLI login for its requests. From that login, Ahena's server creates an agent session: a separate token starting ahena_agent_, labelled with the MCP client's name and valid for 12 hours. The server knows a request came through MCP from the session itself, not from a header the client could set, and the activity log labels those calls via mcp.

An agent session acts as you for reading, running Doctor, planning and asking for approval, with your role's permissions. Whatever your role, Ahena refuses it for:

• approving or declining changes, or approving a CLI sign-in;
• revealing secret values;
• managing members, billing or the organization, or deleting projects;
• creating CI tokens or further agent sessions.

It also can't change Continuous Doctor's monitoring settings, since an agent could otherwise silence the alerts about its own changes. These rules are enforced by Ahena's servers, not by the MCP server or the CLI, so a modified client doesn't get around them.

Tools, write access and intent

ahena mcp is read-only by default. Every tool has a class: READ tools inspect the project, the Stack Graph, environments (secret names only) and providers, run Doctor and plan changes. With --allow-write, SAFE_WRITE tools may change local files (generated code, a new migration file, a capability declared in ahena.config.ts), and BILLABLE tools may apply plans, configure providers or apply a Doctor fix, always under the approval policy below.

Two design choices narrow what an agent can do even with write access:

• No secrets in either direction. No tool returns a secret, and no tool accepts one. When a provider needs connecting, the connect_provider tool returns the ahena connect command for you to run, so credentials never pass through the agent.
• Intent, not payloads. Agents express what they want by editing ahena.config.ts, which is reviewable and git-safe, then asking Ahena to plan. They can't send arbitrary requests to a provider's API through Ahena.

The approval policy

With --allow-write, what happens to a proposed change depends on its classification and the environment:

Every change that isn't SAFE needs you, in every environment, because a development connection can point at the same DNS zone or provider account as production. "Production" here means the environment's effective kind: an environment that holds a live Stripe key is treated as production whatever it's called.

For dashboard approvals, the tool stores the changes as a plan, asks for approval and returns with nothing changed:

{
  "status": "needs_human",
  "approvalUrl": "https://app.ahena.io/approvals/apr_…",
  "planId": "pln_…",
  "proposed": ["~ Configure CORS on leo-production: https://example.com (production) [CONFIRMATION_REQUIRED]"]
}

The agent gives you the link. The approval page shows what Ahena will apply, built from Ahena's own re-plan against the provider rather than from text the agent sent, and names who asked. Once you approve (within 60 minutes), the agent calls apply_plan again and Ahena applies exactly that plan, refusing if the provider changed in between.

For CONFIRMATION_REQUIRED changes outside production, the client asks you through MCP elicitation, a prompt addressed to the person rather than the model, with the exact list of changes. If any change in a plan needs approval, the whole plan waits. If the client can't ask, nothing changes, and the agent is told to ask you to review and run the command yourself. It's never handed --yes.

Why approvals happen in the browser

The CLI's token lives in a file on your machine. An agent on the same machine can read it and run ahena apply --yes. So Ahena doesn't accept approvals of changes that matter from the CLI's token or an agent session at all. It accepts them only from a signed-in browser session: an httpOnly cookie held by the dashboard, optionally with two-factor sign-in. That's something an agent working in your terminal doesn't have.

Approvals are also narrow. A dashboard approval is valid for 60 minutes, covers exactly one environment, provider, plan fingerprint and set of actions, and is used once. Everything is in the audit log: the request, the decision, its use, and how each operation was approved.

The honest limits

This design raises the bar; it doesn't make an agent harmless. What it doesn't cover:

• Computer use and passwords. An agent that controls your browser, or knows your password, can act as you, including approving in the dashboard. Two-factor sign-in raises the bar for the password case, not the browser-control case.
• Non-production CONFIRMATION_REQUIRED changes. These are approved in the CLI. An agent with shell access to your CLI token can approve them. By definition they're reversible, non-billable and outside production, and an environment holding a live Stripe key doesn't count as outside production. Live credentials of providers that can't report whether they're live are only covered when you give the environment the production kind.
• Your own shell. An agent driving your terminal runs as you, so the CLI can't tell it apart from you. For example, ahena env reveal refuses to print a value to a pipe or file unless explicitly asked with --raw or --json, which keeps values out of captured output by default, but it can't stop a command that asks.

The practical advice follows from those limits: give production the production kind, keep two-factor sign-in on, don't give agents control of the browser you approve from, and read the approval page before you approve. The security overview describes the rest of the model: roles, sessions and the tamper-evident audit log.

Setting it up

ahena login
ahena mcp                 # read-only
ahena mcp --allow-write   # also lets the agent generate code and propose provider changes

Most MCP clients take a stdio command. A project-level .mcp.json, for example:

{ "mcpServers": { "ahena": { "command": "ahena", "args": ["mcp"] } } }

The CLI and the MCP server are in beta. The MCP documentation has the full tool list and configuration for other clients.