How to give AI coding agents safe production access

To give an AI coding agent safe production access, give it its own named and revocable credential, start it read-only, keep provider secrets out of its prompts and tool arguments, require a person to approve anything destructive, log every call, and keep one control that cuts all of it off. Each of those is a separate layer. An agent that passes one should still be stopped by the next.

This guide explains each layer, shows how it maps to Escanor's controls, and ends with a rollout plan you can follow this week.

What you are protecting against#

An agent with production access can fail in three ways that a human with the same access rarely does.

1. It acts on bad input. Tool results, logs, issue text and web pages all end up in the model's context. Escanor's security guide says this plainly: model input and tool results can contain content from connected systems. A crafted log line or ticket can steer the agent.
2. It is confidently wrong. The agent can pick the wrong resource, environment or account and describe the result as a success.
3. It has more reach than the task needs. OWASP's guidance on Excessive Agency names three causes: excessive functionality, excessive permissions and excessive autonomy, and recommends limiting tools "to only the minimum necessary" and requiring human approval for high-impact actions (OWASP LLM06:2025).

You cannot fully prevent the first two, so the controls below focus on limiting what a wrong action can reach and making sure someone sees it.

Six controls, and where each lives in Escanor#

1. Give each agent its own credential

A shared key means you cannot tell which agent made a call or revoke one without breaking the others. In Escanor, the MCP page creates a key for each client and shows it once. The MCP docs recommend one key per agent or per machine, named after it. Every key is listed with its last use.

Store keys in a secret store or environment configuration, never in prompts or version control. Rotation replaces a key immediately, so update the client in the same step (API and keys).

2. Start read-only

Most of what an agent needs during an incident is reading: deploy history, logs, connection status, open alerts. Writes can wait until you have watched it read correctly for a while.

Escanor separates discovery from invocation. Through OIDC, mcp:read allows listing tools and their descriptions; mcp:invoke is needed to run them. The MCP gateway also supports read-only tokens, which reject a write with read_only_token, and limited allowed-write policies that stop once their write budget is used. The gateway does not treat an operation it does not recognise as a read (Permissions and approvals).

Two other layers still apply on top of the token. Each provider connection has its own OAuth scopes, and a provider project that is restricted stays restricted even with a valid MCP key. Connect integrations with the narrowest permissions that do the job.

3. Keep provider secrets out of the agent

If an agent holds a cloud access key in its environment or prompt, anything that can read its context can read the key. A gateway that holds credentials server-side avoids that.

Escanor runs each MCP call with your workspace's stored credential for that provider, bound only for the length of the call. Calls to the same provider run one at a time. The docs are explicit that provider credentials do not belong in tool arguments or prompts (Escanor MCP).

The MCP specification takes the same line from the protocol side. A server must only accept tokens issued for it, and "token passthrough", where a server forwards a client's token to a downstream API, is forbidden (MCP security best practices).

4. Require approval for anything destructive

The MCP specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations" (MCP tools). Where that human sits depends on the product.

In Escanor there are several approval points, and they are separate:

• Destructive MCP operations need confirm=true in their arguments. That flag is part of the request. It does not prove a person reviewed the change, and it does not replace workspace or provider authorisation.
• Automations hold proposed actions under Needs you. An owner or manager approves, denies or stops the run. Settings expose autonomy level, per-action overrides and limits on automatic approvals (Automations).
• The desktop app registers each operation as read, write or destructive. Destructive actions require approval even when a capability group is enabled, and if no approver is available the operation is denied. A phone cannot grant itself new permissions; pairing and escalation are approved on the computer.

Because confirm=true is set by the agent, add a human check in the agent client too. In Claude Code, permission rules are evaluated in the order deny, then ask, then allow, and MCP tools are named mcp__<server>__<tool> (Claude Code permissions). If you registered Escanor's server as escanor, this lets the agent discover freely and asks you before every invocation:

{
  "permissions": {
    "allow": [
      "mcp__escanor__escanor_list_providers",
      "mcp__escanor__escanor_connection_status",
      "mcp__escanor__escanor_list_tools"
    ],
    "ask": ["mcp__escanor__escanor_invoke"]
  }
}

Claude Code's own docs say to use bypassPermissions only in isolated environments such as containers or VMs. Escanor's docs say the same about bypass modes on connected machines: choose them deliberately, for an isolated environment, and run the agent under an unprivileged service account.

5. Keep an audit trail you will read

An audit log is useful when you can answer "what did the agent do between 14:00 and 14:20?" from it. Escanor's MCP activity view lists each call in plain language. Automations keep a run record of steps and decisions, and the desktop app has an audit view of denied operations.

The docs also say what audit cannot do. It does not guarantee every external action was captured, and it does not mean the effects can be undone. For anything that matters, check the provider's own logs as well.

6. Keep one control that stops everything

When an agent misbehaves, you want to stop it first and investigate second.

• Revoke the key on the MCP page. The agent is cut off immediately; the provider's resources are untouched.
• Stop everything now in Automations pauses automated work. Work already submitted to a provider may not be reversed, so inspect live runs before resuming.
• Disconnect at the provider when access must end completely. Disconnecting in Escanor and revoking at the provider are separate actions (Security and privacy).

After a stop, do not retry a failed write with broader credentials. The recovery table lists the next step for each outcome.

A rollout plan#

1. Week one, read-only. Create one named key for one agent. Connect a staging project with read scopes. Ask the agent to list the last three deployments and compare its answer with the provider dashboard.
2. Set client rules. Allow discovery tools, ask on invocation, deny anything you never want called.
3. Add one write path on staging, such as redeploying a known-good build, with approval required. Check that the approver sees the exact target.
4. Rehearse the stop. Revoke the key mid-task and confirm the agent fails cleanly. Press Stop everything now during a test automation run and inspect what was already submitted.
5. Review the audit trail for the week and confirm you can reconstruct every call.
6. Widen one scope at a time, and only for a task the agent has already done correctly on staging.

Before you widen access#

• Does every agent have its own named key?
• Can you list which provider scopes each connection holds?
• Is every destructive action behind a person, not only behind confirm=true?
• Have you revoked a key and stopped a run at least once, on purpose?
• Can you reconstruct yesterday's agent actions from the log?

If any answer is no, fix that before granting more access. For the protocol side of this setup, read Using an MCP server to operate infrastructure. The Escanor MCP page covers connecting an agent, and AI incident response shows these controls during an incident. MCP keys carry the permissions of your workspace's plan; integration and run limits for each plan are on the pricing page.