Preflight Checklist to Build and Run AI Agents

Pilots do not rely on memory or confidence before takeoff. They run a checklist, every flight, even after ten thousand hours.

Agents deserve the same discipline. An agent is software that decides what to do next, calls tools with real credentials, and spends real money while doing it. Most failures I see are not model failures. They are missing-preflight failures: a key that never expired, a tool nobody meant to expose, a feature that shipped without a test it could fail.

This is the checklist I run before I build an agent and before I let one run unattended. Each item is a rule, a reason, and a check you can answer with yes or no.

This is an opinionated baseline for production agents with access to credentials, sensitive data, or external actions. It is not a universal architecture for every prototype. Where a check is a strict policy of mine and not the only valid design, I say so.

If you cannot answer "yes" with evidence, the answer is "no". Do not take off.

The 12 checks at a glance

Before you build

1. Evals before features: the golden set exists first and gates CI.
2. Deny by default: tools are an explicit allow-list, enforced at a tool gateway.
3. Vendor portability: apps talk to an AI gateway, and a second provider is proven where resilience matters.
4. Pin the contract: models, prompts, tools and skills are versioned together.

Before you ship

5. Capability leases over long-lived keys: short-lived, scoped, brokered credentials.
6. Zero trust for external MCPs and skills: nothing loads without a documented security review, and executable components run inside an isolation boundary.
7. Instructions are not enforcement: prompts and skills guide, the runtime enforces.
8. Retrieved content is untrusted: injection is tested, not assumed away.
9. AI speeds up mistakes too: automated gates, including agent-aware code scans, catch them.

Before you leave it running

10. Cost router over model loyalty: the cheapest model that meets measured quality, hard budgets always.
11. Observability and audit: every run can be reconstructed from its record.
12. Kill switch: a rollback you have actually rehearsed.

How to use this list

Three passes, in order:

1. Before you build: decisions that are cheap now and expensive later (evals, tools, vendors).
2. Before you ship: controls the runtime must enforce (identity, sandbox, approvals).
3. Before you leave it running: the things that tell you when it goes wrong (cost, audit, kill switch).

Print it. Put it in the PR template. The point is that nobody has to remember it.

Pass 1: Before you build

1. Eval harnesses ship before features

Feature-without-eval is technical debt with a deadline. Write the golden set first. The feature is whatever passes it.

• A golden set exists, with real failure cases and not only happy paths.
• The eval runs in CI and blocks the merge when it regresses.
• Every production incident adds a case to the set.

The team that ships evals last ships rollbacks first. I covered the mechanics in Prompt Evals.

2. Deny by default on tool calls

An agent that can call any function will eventually call the wrong one. An allow-list is the only safe surface.

• Every tool the agent can reach is on an explicit allow-list.
• Each tool has a written justification: what it does, why this agent needs it.
• Anything not listed returns a hard refusal, not a warning.
• The allow-list lives in a tool gateway (Composio, Arcade, or your own), not scattered across agent code. One place to grant, scope, and audit.

A tool gateway gives you central auth, scoped tool lists, and audit logs behind one MCP URL. I compared the options in The AI-Native Cloud Agent Stack. Tool inventories shrink as you mature, they do not grow. Every new tool is new attack surface, so make each addition earn its place.

// Deny by default: the registry is the policy
const allowed = new Set(["search_docs", "read_ticket", "draft_reply"]);

export function dispatch(call: ToolCall) {
  if (!allowed.has(call.name)) {
    audit("tool.denied", call);
    throw new ToolDenied(call.name); // fail closed
  }
  return tools[call.name](call.args);
}

This example illustrates tool-level denial only. Production dispatch must also validate arguments and authorize the caller, action, resource, and approval.

3. Vendor portability

Pricing, terms, and model availability shift under you. Anyone standardized on a single frontier vendor is one announcement away from a forced migration. Multi-provider support is an architectural and resilience choice, not a prerequisite for every agent. I treat it as the default for anything in production that the business depends on.

• Application code talks to an AI gateway (LiteLLM, for example) or inference router, never to a vendor SDK directly.
• Where resilience matters, a second provider is configured and exercised by the eval suite, not just listed.
• You can switch the default model with a config change, no redeploy of logic.

The gateway also gives you virtual keys per agent, spend limits, and one place to log every model call. Your routing layer should outlive any single vendor's term sheet. The trade-offs between gateways and routers are in LLM Routing.

4. Pin the contract

Models are not fully deterministic, even with the same settings and seed, so you cannot rely on re-running a model to reproduce what happened. If you cannot reconstruct what happened, your audit trail is incomplete. Pin versions and record inputs, outputs, tool results, and policy decisions.

• Model versions are pinned by full identifier, never by a floating alias.
• Prompts, tool schemas, and skills are versioned together.
• Temperature and seeds are set wherever the API supports them.
• A run records exactly which versions it used, plus its inputs, outputs, tool results, and policy decisions.

Re-running the same workflow may still produce different results, so treat the record as the source of truth. "It worked yesterday" is the saddest sentence in agent operations. Reproducibility is a feature, not a chore. The same logic applies to skills loaded on demand: log which version loaded.

Pass 2: Before you ship

5. Capability leases over long-lived keys

A permanent API key is the most expensive thing an agent can hold. If it leaks through a prompt injection, the attacker keeps it until someone notices and rotates it.

• No standing credentials in prompts, skills, env files the agent can read, or memory.
• Every tool call receives a short-lived, scoped, revocable lease.
• Leases name the action and resource (tickets:read on one tenant), not a whole account.
• You can revoke a single agent's access in seconds.
• Credentials are brokered: the tool gateway injects them at execution time, so the agent never sees the live secret.

Non-human identity vendors are converging on the same shape for a reason. If the credential outlives the task, you have the wrong credential.

6. Zero trust for external MCPs and skills

An external MCP server or skill is third-party code and instructions that your agent will obey or execute. Zero trust means none of it is trusted by default: it must pass a documented security review before it loads, and it is contained after it loads. In this post, "security attestation" means exactly that: a recorded review and approval of a specific version. It is evidence that someone looked, not a guarantee of safety. STDIO MCP servers run code on the host by design, and a skill can carry hidden instructions or scripts, so both count.

• No external MCP server or skill is loaded without a security attestation. Scan it (bastyn-scan covers both MCPs and skills), review the findings, and record who approved it and which exact version.
• Attestation is tied to a pinned version or content hash. Any change (new release, edited skill) voids it and goes through review again.
• The agent cannot install or enable an MCP server or skill on its own. Only the attested registry is loadable.
• Skills are scanned for hidden instructions, bundled scripts, and requests for broader tools than the task needs. The scan runs in CI and again at install time.
• Each STDIO MCP server and each code-executing tool runs inside an isolation boundary suited to your threat model, never directly on the host, with restricted filesystem access. Firecracker microVMs (E2B is one way to get them) are the high-assurance option I use. OS-level sandboxing with filesystem and network isolation is another.
• Remote MCP servers can't be sandboxed by you, so they get scoped leases, an egress allow-list, and go through the tool gateway.
• The isolation boundary has no ambient credentials and an explicit network egress policy.
• No exceptions for first-party code, popular packages, or vendors you trust this week. Attestation applies to all of them.

Remember that a STDIO tool server is a process with your permissions, not a plugin. See MCP Servers Demystified for how the protocol is wired.

7. Instructions are not enforcement

A prompt saying "ask before deleting" is guidance. A delete tool that refuses without an approval token is a control.

Skills are the same. A skill that says "never touch production" is a well-written instruction the model will usually follow. It is not a permission. Skills decide how the agent does a job, and the runtime decides what it is allowed to do. Keep the dangerous capability out of reach, not just out of the playbook.

• Authorization is enforced in the runtime, outside the model's reach.
• Skills carry procedure only. Anything a skill forbids is also denied by the allow-list and the lease.
• High-impact, irreversible, or out-of-policy actions (large payments, production deploys, deletes, external messages outside a template) require human approval.
• Low-risk actions inside explicit, bounded limits are pre-authorized, so approvals stay meaningful and people are not trained to click through prompts.
• Approvals bind to the exact payload, so a changed recipient or amount invalidates them.

I built this boundary out in Deterministic First, and the skill side in Progressive Disclosure.

8. Treat all retrieved content as untrusted input

Web pages, tickets, emails, and documents can contain instructions. The model cannot reliably tell data from commands.

• Untrusted content is never able to widen the tool allow-list or the lease scope.
• Tools that read untrusted content and tools that act externally are separated, or gated with approval when combined.
• You have a test that plants an injection in a document and checks nothing happens.

9. AI speeds up mistakes as well as work

Before AI, the cost of a careless commit was bounded by typing speed. The friction was a feature. Now a frontier model produces 200 lines of plausible-but-wrong code in 30 seconds. Every guardrail-skipping habit you already had gets faster.

• Automated gates absorb the risk: tests, type checks, lint, secret scanning, dependency review.
• A security code scan aimed at agent-written code runs on every change (for example, bastyn-scan). Agents repeat the same insecure patterns at volume, so scan for those patterns specifically.
• Defense does not depend on each engineer remembering to be careful.
• Agent-authored changes go through the same gates as human ones, with no bypass flag.

Pass 3: Before you leave it running

10. A cost router beats model loyalty

Use the least expensive model or workflow that meets your measured quality and latency requirements. For many workloads a cascading router, which tries a small model first and escalates on uncertainty, is a good strategy to evaluate. It is not an invariant: some tasks warrant a capable model directly.

• Calls are classified, and routing and escalation are validated against the eval suite.
• Escalation triggers are explicit (low confidence, failed validation, tool error).
• You measure cost per successful task, not cost per token.
• There is a hard budget per run, per agent, and per day, enforced at the gateway.

Defaulting every call to the biggest model is the cost center. Enforce the budgets at the AI gateway so a looping agent hits a wall instead of your invoice. More on the economics in LLM Optimization Costs.

11. Observability and audit trail

You cannot fix or defend what you cannot reconstruct. Replaying recorded events (reading the trace) is different from re-executing the workflow, which may give a different result.

• Every tool call logs who (agent and lease), what (name and arguments), and outcome.
• Traces link the prompt, model version, retrieved context, and tool results for one run.
• Logs are tamper-resistant and kept as long as your compliance needs require.
• Secrets and personal data are redacted before they hit logs.

12. A kill switch and a rollback you have actually tested

• One action stops an agent: revoke leases, drain the queue, halt schedules.
• Loop and step limits cap a runaway agent.
• You have rehearsed rollback of the prompt, model, and tools to the last known good set.
• Someone is on call for the agent, and they know it.

A kill switch you have never pulled is a hypothesis.

The preflight card

If you want the one-screen version:

#	Check	Evidence
1	Evals exist and gate CI	CI run with golden set
2	Tools are deny-by-default	Allow-list in the tool gateway
3	Two vendors work behind the AI gateway	Eval pass on the second provider
4	Versions pinned	Run record shows exact IDs
5	Leases, not keys	No standing secrets; revoke drill
6	External MCPs and skills attested	Scan report and approval per pinned version; isolation config
7	Side effects gated	Approval bound to payload
8	Injection tested	Failing-then-passing test
9	Gates absorb AI risk	Agent code scan green, no bypass path
10	Cost routed and capped	Budget and cost-per-task metric
11	Everything reconstructable	Trace for a sample run
12	Kill switch rehearsed	Date of last drill

One more check: scope

Fewer agents, tighter scope. Every extra agent is something to eval, lease, audit and page someone for. Two well-scoped agents with real evals beat five loosely defined ones.

The takeaway

None of this is exotic. It is the boring discipline that separates a demo from a system:

• Prove it with evals before you build.
• Limit it with deny-by-default tools and short-lived leases.
• Contain it with isolation boundaries and runtime-enforced approvals.
• Bound it with routing, budgets, and a kill switch.
• Reconstruct it with pinned versions and a full audit trail.

Run the list every time. The flight that skips preflight is the one that teaches you why it exists.