This checklist is for engineers and tech leads actually writing the code behind an AI agent: the tool definitions, the authorization checks, the code that takes model output and turns it into a real action. It's meant to be worked through during implementation and again before a pull request that adds or changes agent tooling gets merged, not treated as a one-time exercise at the end of a project. It assumes the agent can call at least one tool with a real side effect (a database write, an email send, a code execution step) rather than only generating text, since that is where implementation choices carry the most consequence. Use it alongside your normal code review process, as an additional lens rather than a replacement for it.
Tool design and scoping
Confirm each tool exposes the narrowest interface that accomplishes its job, rather than a general-purpose function that happens to be convenient to implement. Confirm read and write operations are separate tools with separate permission profiles, so a tool that only needs to look something up can never also modify it. Confirm every tool parameter is validated against an explicit schema and range before use, not passed through directly on the assumption that the model will supply reasonable values. Confirm any tool that constructs a query, command, or file path builds it from validated components rather than concatenating model-supplied strings directly into the target syntax.
Authorization independent of model intent
Confirm every tool call is checked against the calling user's or agent's actual permissions at execution time, independent of what the model claims it intends to do or believes it is authorized for. Confirm this authorization check happens in code that the model cannot influence, not inside a prompt instruction the model is merely asked to follow. Confirm identity is propagated through every internal hop between the agent, any orchestration layer, and the tool itself, so a downstream service never falls back to a shared or elevated service account. Confirm high-impact actions, ones that spend money, delete data, or reach an external party, carry a stricter check than routine reads.
Output handling before it reaches a sink
Confirm model-generated output is validated against the expectations of its actual destination before it's used, whether that destination is a database, a shell, a browser, or another agent. Confirm output destined for a database query, shell command, or file system path is encoded or parameterized for that specific destination, not just checked for plausibility. Confirm output rendered into a user interface is escaped against injection into HTML, markdown, or a rendering context that could execute embedded content. Confirm output passed to a second agent or downstream tool call goes through the same validation as output reaching a human.
Data handling and minimization
Confirm the context assembled for each request includes only the fields a given task actually needs, not a full record pulled in for convenience. Confirm sensitive values that don't need to appear in plaintext, account numbers, credentials, personal identifiers, are redacted or tokenized before they enter the model's context or get written to a log. Confirm logs that capture prompt or response content have a defined retention window and access restricted to people who need it for debugging or review, separate from general application logs.
Resilience and containment
Confirm every security-relevant dependency, a policy service, an authorization check, a rate limiter, fails closed by default if it becomes unavailable, rather than allowing the action through. Confirm rate and resource limits exist per user, per agent, and per tool, so a single loop or a single compromised identity can't exhaust a shared resource or run up unbounded cost. Confirm any code execution capability runs inside an isolated, resource-limited, ephemeral sandbox with no persistent access to the broader environment.
Testing before merge and after change
Confirm the agent has been tested against direct prompt injection attempts embedded in user input and indirect injection planted in retrieved documents, web content, or tool responses. Confirm there is a test that attempts to call a tool or access data outside the calling identity's actual permissions, verifying the authorization check catches it rather than the model's own judgment. Confirm this testing is repeated after a model version change, a prompt change, or the addition of a new tool, not run once and assumed to still hold indefinitely.
Where TELEON fits
Several items on this checklist, authorization checks independent of model intent, fail-closed behavior for security-relevant dependencies, and redaction of sensitive values before they reach a log, map to what TELEON's runtime policy enforcement, audit trail, and privacy vault tokenization provide when the agent's tool calls pass through the gateway. Tool interface design, output encoding logic, and sandboxing for code execution remain implementation work that engineering has to do directly, since a runtime layer enforces and evidences decisions but does not design the tools themselves.
The checklist in short form
- Narrow tool interfaces with separated read and write access.
- Parameter validation against explicit schemas, not raw pass-through.
- Authorization checks independent of the model's stated intent.
- Identity propagated through every internal hop.
- Output validated and encoded for its actual destination.
- Context minimized, sensitive values redacted or tokenized.
- Fail-closed dependencies and per-identity rate and resource limits.
- Sandboxed code execution and injection testing repeated after change.
Apply this checklist with more weight where a tool's worst-case action is genuinely damaging, an agent that can issue refunds or delete records deserves a stricter pass than one that only summarizes internal documents. Re-run the relevant sections whenever a tool's scope expands, a new data source is connected, or the underlying model changes, since each of those shifts the risk profile the original implementation was reviewed against.