This checklist is for security teams that oversee AI agents rather than build them: the people who need to answer "what could go wrong here" and "how would we know" for agents that engineering teams across the organization are shipping. It's written for a governance and assurance role, not an implementation one, so it focuses on visibility, review, and detection rather than code-level fixes. Work through it when a new agent is proposed, again before it's granted a meaningful expansion of tools or data access, and on a recurring schedule proportional to how much damage the agent could do if something went wrong. The goal is a security team that can state, with evidence rather than assumption, what every agent in the organization can actually do.

Visibility into what exists

Confirm there's a current inventory of every AI agent in production, including internal tools built on top of a model, not only customer-facing ones. Confirm the inventory records each agent's tool access, data access, and model version, since two agents built from the same template can carry very different risk depending on what they're connected to. Confirm there's a process that catches new agents and tool integrations as they're built, rather than relying on teams to self-report. Confirm ownership is recorded for each agent: a specific person or team who can answer detailed questions about it on short notice.

Threat modeling before high-impact access

Confirm trust boundaries are explicitly mapped for each agent: which inputs are trusted, which are untrusted content that could carry an injection attempt, and where the model's output is treated as a proposal rather than a final action. Confirm each agent's worst-case action, the most damaging thing it could be tricked or misused into doing, has been identified and written down, not left implicit. Confirm security review happens before an agent is granted a new high-impact tool or a broader scope of data access, not discovered afterward during a routine audit.

Detection tuned to agent behavior

Confirm monitoring exists for injection attempt patterns in prompts and retrieved content, not only for conventional application security signals. Confirm there's a way to detect anomalous tool call sequences for a given agent, actions or an order of actions that fall outside its established normal pattern. Confirm policy denial rates are tracked over time per agent, since a rising denial rate is often the earliest sign that something upstream has changed or that an attack is in progress. Confirm alerting on these signals routes to a person who can act, not into a dashboard nobody watches.

Audit and evidence quality

Confirm every agent's activity is captured in a log that ties identity, decision, and outcome together with enough detail to reconstruct what happened after the fact. Confirm this log is tamper-evident, append-only or equivalent, so it holds up as evidence rather than as a record an attacker or a careless process could quietly edit. Confirm write access to this log is restricted separately from read access, and that read access itself is limited to people with an actual need. Confirm retention on this log meets whatever period an investigation or a compliance obligation would realistically require.

Incident readiness specific to agents

Confirm a written runbook exists for each of the scenarios that recur with agents specifically: prompt injection, data leakage through model output, and tool misuse or abuse. Confirm whoever needs to disable or restrict an agent during an active incident has pre-authorized access to do so, rather than needing to request it in the moment. Confirm these runbooks have been tested through a tabletop exercise at least once, not only reviewed on paper.

Review cadence tied to risk

Confirm each agent has an assigned risk tier and that the frequency of its security review is tied to that tier, rather than every agent receiving the same review cadence regardless of what it can do. Confirm a re-review is triggered automatically when an agent's tools, data access, or model changes significantly, not only at the next scheduled interval. Confirm findings from one agent's review are checked against similar agents elsewhere in the organization, since a gap in one implementation often exists in others built the same way.

Where TELEON fits

Several items on this checklist map closely to what a gateway deployed between agents and the model providers or tools they call can provide directly: a tamper-evident audit trail of tool calls and decisions, runtime policy enforcement at the tool-call boundary that gives security teams a consistent point to observe and restrict behavior, and trust scoring that supports the anomalous-behavior detection this checklist calls for. Building the initial agent inventory, defining risk tiers, and running tabletop exercises remain governance work that a security team has to do directly.

The checklist in short form

  1. A current, complete inventory of agents, tools, and data access.
  2. Trust boundaries and worst-case actions mapped before high-impact grants.
  3. Detection tuned to injection patterns and anomalous tool sequences.
  4. A tamper-evident audit log with restricted write access.
  5. Agent-specific incident runbooks tested through tabletop exercises.
  6. Review cadence and re-review triggers tied to risk tier.

The hardest part of this checklist is usually the first section, not the last: teams routinely discover agents during this exercise that nobody had formally reviewed. Treat that discovery as the expected outcome of doing this well rather than as a sign the checklist is somehow miscalibrated, and budget time for it before assuming the later sections are where the real work is.