AI Coding Agent Setup, Security, and Model Routing

Last reviewed: 2026-05-14.

Who this is for

This guide is for engineering teams that want to let a coding agent inspect, edit, test, or prepare pull requests in a real repository without turning the first run into an uncontrolled production experiment.

It assumes the team may use terminal agents such as Claude Code or OpenCode, IDE agents such as Cursor Agent, or a local Codex-style workflow. The product names differ, but the operating problem is the same: the agent needs repository context, a bounded tool surface, model access, logs, and a review gate before externally visible writes.

Key takeaways

Treat repository access and model API access as separate permission layers.
Write project rules before the agent edits code; do not rely on a one-off chat prompt.
Give the first run a read-only or dry-run task so the agent learns the repo before mutating it.
Store real API keys only in ignored local files, CI secrets, or a provider secret store.
Route model calls through explicit roles such as writer, planner, reviewer, and critic.
Keep production writes, paid actions, DNS changes, deploys, deletions, and merges behind human or CI approval.

The setup contract

A coding agent setup is not just “install the tool and paste a prompt.” It is a contract between the repository, the human operator, the local machine, and the model endpoint.

The minimum contract has four parts:

Layer	Safe default	What can go wrong without it
Repository rules	`AGENTS.md`, `CLAUDE.md`, or the tool’s project memory file	The agent edits generated files, skips required checks, or follows stale architecture notes.
Local tool permissions	Read, build, test, dry-run, then narrow edits	The agent runs destructive commands before it understands the repo.
Model credentials	One key per environment or workflow	Cost attribution and incident response become muddy after a bad request.
Release gate	Human review or CI before deploy/merge/DNS/billing writes	A demo patch becomes a production side effect.

Anthropic documents project memory for Claude Code, Cursor documents Agent mode as an IDE workflow, and OpenCode documents a terminal agent workflow. Those references do not make the tools identical, but they support the same operating lesson: write the rules down where the agent can read them, then verify work with commands.

First-run repository checklist

Use this checklist before asking the agent to make the first code edit:

Create or update the repo instruction file that names required reading, forbidden side effects, test commands, secret-handling rules, branch expectations, and handoff format.
Confirm .env, .env.*, tmp/, var/, generated build output, and local runtime state are ignored unless the repo intentionally tracks them.
Run git status --short and decide whether the agent must protect unrelated user work.
Ask for a read-only architecture summary before implementation.
Ask for the exact verification command before the edit, then require the same command after the edit.
Keep cloud provider tokens, registrar access, payment actions, DNS writes, production deploys, and destructive Git commands outside the default permission box.

The first prompt should be boring on purpose:

Read the repository instructions and summarize the current architecture.
Do not edit files yet.
List the exact checks you would run before making a change.

If the answer is confused, improve the repository context before widening permissions. A confused agent with write access is not autonomy; it is an unreviewed diff generator with too much surface area.

Separate local authority from model authority

Teams often talk about “giving the agent access” as if there is one access switch. There are at least two:

Permission layer	Example	Review question
Local tool permission	Read files, edit files, run tests, open a browser, call Git	What can the agent change on this machine or in this repo?
Model API permission	Call GPT, Claude, or another model through an API key	Which model can it call, what can it send, and who pays for it?

A powerful model key does not need broad shell authority by itself. A local coding agent does not need registrar, cloud, or billing credentials just because it can edit source code.

That split also makes incident response cleaner. If a prompt accidentally includes private repository details, rotate or scope the model key. If a command changes the wrong file, inspect the Git diff and local command log. If a deploy token was exposed, revoke the deploy token without confusing it with model access.

Model routing through a gateway

A model gateway such as CometAPI can help when the team wants one integration surface for multiple model roles. The useful part is operational control, not vague “AI magic.”

Use role names in config:

model_roles:
  planner:
    provider: cometapi
    model: gpt-5.5
  writer:
    provider: cometapi
    model: gpt-5.5
  reviewer:
    provider: cometapi
    model: gpt-5.5
  critic:
    provider: cometapi
    model: claude-opus-4-7

Then bind each role to a task:

Role	Good use	Bad use
Planner	Decide scope and test strategy	Hide uncertain requirements.
Writer	Produce a focused patch	Rewrite unrelated code.
Reviewer	Score factual risk, tests, and side effects	Rubber-stamp the writer.
Critic	Independently challenge risky changes	Repeat the same prompt with a different name.

The gateway does not remove the need for repository checks. It makes model use easier to audit: which role ran, which model handled it, and why that cost was justified.

Credential handling checklist

Store real keys in ignored .env, CI secrets, or a provider secret store.
Keep .env.example to placeholder names only.
Use separate keys for local canary, CI, and production when possible.
Keep model role names in config, not scattered through prompts.
Avoid sending secrets, customer data, private URLs, or private repository snippets to a model unless the workflow explicitly permits it.
Rotate keys after accidental exposure.
Do not print secret values in logs, docs, or acceptance notes.

For local work, a checked-in placeholder is fine:

COMETAPI_KEY=replace-with-local-secret
COMETAPI_BASE_URL=https://example.invalid/v1
COMETAPI_MODEL=gpt-5.5

The real .env value stays local and ignored.

Failure modes to plan for

Failure mode	Early signal	Safe response
The agent skips repo rules	It edits before reading required docs	Stop the run, tighten the first prompt, and make required reading machine-checkable.
The agent invents API details	It hard-codes paths, model IDs, prices, or auth schemes without source support	Require source links and placeholders for unverified contract values.
The agent over-edits	Diff touches files outside the request	Revert only the agent’s changes and narrow file ownership.
The agent burns model budget	Small tasks use the most expensive role	Move high-cost models to review or critic gates.
Demo content ships as production	Static pages bypass review ledgers	Block static builds unless source, depth, internal links, and UTM metadata pass deterministic checks.

That last failure mode is the one this site now treats as a first-class lesson: a provider canary is still public content if it is indexed. Public content must pass the content gate or stay noindex/local.

Reader next step

Until a core CometAPI CTA target is approved, use the internal operating path instead of a guessed conversion link:

Review the site’s editorial standards.
Pair this setup guide with the repository context and parallel agents guide.
Use the test repair and PR workflow before letting an agent prepare reviewable changes.

Sources checked

Claude Code documentation, checked 2026-05-14, for terminal coding-agent workflow context.
Claude Code memory documentation, checked 2026-05-14, for project memory and instruction-file behavior.
Cursor Agent documentation, checked 2026-05-14, for IDE agent workflow context.
OpenCode documentation, checked 2026-05-14, for terminal agent configuration and operation context.
CometAPI documentation, checked 2026-05-14, for gateway-style model integration context.
OpenAI API keys documentation, checked 2026-05-14, for API key setup and secret-handling context.