This checklist is for reviewing an AI system's architecture at design time, before it's built or while its design is still being decided, rather than auditing a system already running in production. It's narrower than a full operations checklist on purpose: it focuses only on the structural decisions, where trust boundaries sit, where enforcement happens, how identity flows, that are expensive to change once a system is live and cheap to get right before a single line of implementation code exists. Use it in a design review meeting or an architecture document review, alongside whoever is proposing the system, not as a solo audit performed after the fact.

Trust boundaries

Confirm the design explicitly states which inputs are trusted and which are untrusted, including retrieved documents, web content, tool responses, and anything else that reaches the model's context from outside the system's own fixed instructions. Confirm the model's output is treated architecturally as a proposal that a separate layer evaluates and can reject, not as a final action that executes directly. Confirm the boundary between components, the model, the orchestration layer, each tool, is drawn on paper and not just implied by how the code happens to be organized. Confirm the design states, for each trust boundary, what crossing it actually requires, a validation step, an authorization check, a specific transformation, rather than leaving the crossing itself undefined.

Enforcement placement

Confirm policy enforcement is designed to sit primarily at the tool-call boundary, the point where the system moves from generating text to taking a real action, rather than relying only on prompt instructions or output filtering upstream of that point. Confirm the design includes supporting layers beyond that primary enforcement point, content validation, output filtering, so the architecture doesn't depend on a single control catching every case. Confirm the design specifies what happens when enforcement denies an action: whether the system retries, informs the user, or escalates, rather than leaving that path undesigned.

Identity and authorization propagation

Confirm the design shows identity surviving through every hop between the user, the agent, any orchestration layer, and each tool it calls, rather than collapsing into a shared service account partway through. Confirm no component in the design runs with broader permissions than the specific task in front of it requires, even if a shared, more privileged account would be more convenient to implement. Confirm authorization decisions are designed to happen against the calling identity's actual permissions, not against what the model states its own intent to be.

Data flow

Confirm the design maps where sensitive data enters the model's context and where it can exit, through direct output, through a tool call, or through a log, since a data flow that isn't mapped is a data flow that can't be protected. Confirm points in that flow where sensitive values should be redacted or tokenized are identified explicitly, rather than addressed generically as "handle securely" without a specific mechanism attached. Confirm retrieval components apply access control before ranking content by relevance, so the design never allows unauthorized content to reach the model's context in the first place. Confirm log destinations are included in this data flow map, since a log capturing full prompts and responses is itself a place sensitive data ends up, whether or not that was the original intent.

Fail-safe design

Confirm every security-relevant dependency in the design, a policy service, an authorization check, a content filter, has explicit, documented fail-closed behavior if that dependency becomes unavailable. Confirm any deliberate exception to fail-closed behavior is called out specifically and justified, rather than left as an unstated default that whoever implements the system might get wrong. Confirm the design includes a plan for testing this fail-safe behavior directly, a simulated outage of the relevant dependency, rather than assuming the documented behavior will hold simply because it was written down. Confirm the design accounts for the enforcement infrastructure's own availability, since fail-closed behavior only holds up if the component enforcing it is itself reliable enough not to become the system's most common point of failure.

Where TELEON fits

Enforcement placement at the tool-call boundary, identity propagation through the request path, and fail-closed behavior for security-relevant dependencies map directly to what a gateway deployed between agents and the model providers or tools they call provides at runtime, along with the audit trail that gives a review team evidence the design's assumptions are holding once the system is live. Drawing the trust boundaries and mapping the data flow in the first place remain design work that has to happen before any runtime layer has something concrete to enforce.

The checklist in short form

  1. Trust boundaries mapped, model output treated as a proposal.
  2. Enforcement placed primarily at the tool-call boundary, with layers.
  3. Identity propagated through every hop, no shared privileged account.
  4. Sensitive data flow mapped, with redaction or tokenization points.
  5. Fail-closed behavior documented and tested for every dependency.

Run this checklist again whenever a system's architecture changes materially, a new tool category is added, a new data source is connected, or an orchestration layer is replaced, since an architecture review performed once at the original design stage doesn't stay accurate as the system's shape evolves. For smaller, lower-risk systems, a lighter pass through these same five categories is usually enough; save the fullest scrutiny for architectures where a structural mistake would be genuinely difficult to walk back later, since retrofitting a trust boundary or an identity model onto a system that's already been built around their absence is far more disruptive than getting the design right the first time.