This checklist groups the controls that matter most for an AI agent heading toward production into a few practical categories: identity and authorization, containment, oversight, and monitoring. It isn't a substitute for the deeper threat modeling work covered elsewhere in this cluster, but it's a reasonable gate to run any agent through before it gets meaningful access to real systems and real data. Treat a "no" on any item as a genuine open risk to weigh deliberately, not a checkbox to explain away, because most of the agent incidents worth worrying about trace back to exactly one of these items being skipped under deadline pressure.

Identity and authorization

Every agent needs a real identity behind it and a way to enforce permissions independent of its own reasoning.

  1. Every tool call traces back to a specific, real identity, not one shared credential covering every agent action.
  2. Authorization is enforced outside the model's reasoning path, at the tool call itself, using an independent policy check.
  3. Tools are scoped to the narrowest parameters and actions they actually need for the task.
  4. Read and write operations are separated into distinct tools with distinct authorization rules.
  5. Authorization is re-checked on every request, not cached or assumed valid for the rest of a session.

Containment and blast radius

Assume some bad decision will eventually get through, and make sure it can't do unlimited damage.

  1. Spending, rate, and transaction limits are enforced outside the agent's own judgment, as a hard backstop.
  2. Access is segmented by task, tenant, or context, so one session can't reach data outside its own scope.
  3. High-impact actions favor reversible patterns, holds and drafts, over immediate irreversible ones wherever the business process allows it.
  4. New agent capabilities roll out in stages, with a limited scope and close monitoring, before reaching full production traffic.

Human oversight

Autonomy is useful, but some decisions still deserve a genuine pause before they execute.

  1. Costly, irreversible, or sensitive actions require human approval, not just an automated policy pass.
  2. Approval requests surface the agent's reasoning and relevant context, not just a bare yes-or-no prompt.
  3. Approval timeouts default to denial, not to silently proceeding with the action.
  4. Escalation paths to a human are genuine and can't be quietly bypassed by conversational framing.

Input and context integrity

Anything an agent reads is a potential instruction, whether it looks like one or not.

  1. Prompts, retrieved documents, tool responses, and other agents' messages are all treated as untrusted input.
  2. Memory writes are reviewed and isolated per user or tenant, not shared across contexts by default.
  3. High-impact claims, an approval, an authorization, referenced in context get cross-checked against a system of record before the agent acts on them.
  4. The system has been tested against direct and indirect prompt injection, not just normal usage scenarios.

Multi-agent and delegation boundaries

If more than one agent is involved, trust between them needs the same scrutiny as trust with any external input.

  1. Agent-to-agent messages are treated as untrusted input, not implicitly verified fact.
  2. Authorization context travels with a request when one agent asks another to act on its behalf.
  3. Each agent in a multi-agent system has its own scoped credentials, not a shared identity across all of them.

Monitoring and recovery

Detection and clean recovery matter as much as prevention, because prevention alone will eventually miss something.

  1. Full decision context, trigger, identity, policy result, outcome, is logged for every consequential tool call.
  2. Cost and resource usage per session is monitored as a security signal, not only a finance metric.
  3. Hard ceilings on steps, tool calls, and spend per session catch loops and runaway sequences automatically.
  4. Retry and recovery logic re-applies authorization checks and can't silently bypass a prior denial.
  5. Someone with the authority to pause or restrict an agent actually reviews monitoring data on a set cadence.

Ongoing maintenance

None of the above stays valid forever. Agents, tools, and models keep changing underneath the controls built around them.

  1. This checklist gets re-run whenever a new tool, data source, or connected agent is added, not only at initial launch.
  2. Trust decisions between agents get reconfirmed after either side changes meaningfully, a model upgrade or a new capability.
  3. Attack surface, permissions, and approval thresholds get reviewed on a fixed schedule, not only when something goes wrong.

Where TELEON fits

Several of the items above, independent tool-call authorization, spending and rate limits, audit logging, approval routing, and trust scoring, are exactly what TELEON's gateway is designed to enforce consistently between an agent and the model providers or tools it calls, regardless of the framework used to build the agent. It gives teams a practical way to implement the enforcement and monitoring layers of this checklist without building that infrastructure from scratch for every new agent.

The identity design, threat modeling, containment decisions, and multi-agent architecture behind each item still have to be worked out by the team building the specific agent, since they depend entirely on what that agent is actually meant to do.

Running through this checklist honestly, and being willing to delay a launch over a genuine gap rather than a hypothetical one, is a better predictor of whether an agent deployment holds up in production than any amount of confidence in the underlying model. The agents that cause real incidents are rarely running exotic new attack techniques against their targets. They're running into gaps that a checklist like this one would have caught months earlier, if anyone had run it before shipping.