Security Architect AI Risk Checklist for Design Approval

A reference diagram can look complete while leaving the decisive request path undefined; the security architect AI risk checklist below is a design approval gate for one proposed AI service before implementation or procurement commits the organization to it. The output is a signed architecture decision record tied to a fixed data flow, trust boundaries, control owners, failure model and evidence contract. Release authorization belongs to the CTO or change authority later. CISO reporting measures the operating estate after deployment.

TL;DR

• Review one fixed architecture before implementation, with the trust boundary and external dependencies drawn explicitly.
• Bind caller identity and data classification to a named policy decision point on every governed model route.
• Allocate each control to a component, then define failure and bypass behavior before approving the design.
• Sign an architecture decision record that states assumptions, residual gaps and the changes that reopen review.

Check 1: set the security architect AI risk checklist boundary

Name the service, business use and architecture version under review; record the calling applications, expected user or agent populations and model destinations. Include retrieval systems and downstream tools on the diagram when they can change the content or authority of a model request. A vendor logo leaves the component boundary undefined.

This gate approves a design before engineers produce a release candidate. The architect should identify which interfaces exist, what information crosses each interface and which external services the design depends on. NIST SP 800-53 Revision 5 makes that scope explicit in PL-8. The control calls for security and privacy architectures that describe protection requirements, integration with enterprise architecture and assumptions about external systems.

Pass condition: one versioned diagram and architecture decision record describe the proposed state. The record names its owner, review date and every dependency whose behavior affects approval.

Check 2: trace every trust boundary and model route

Draw each request from the authenticated caller to the LLM endpoint; mark where the application adds retrieved context, where TLS terminates and where a policy can inspect the assembled payload. The same drawing should expose alternate egress paths because a direct provider route that bypasses the proposed enforcement point changes the security claim.

Use two line styles on the diagram. A solid line marks governed HTTP AI traffic. A dotted line marks traffic with a different control owner, such as a personal browser session or local inference. At the review table, I want to see the dotted lines. Hiding them behind a cloud icon turns an architecture decision into a sales diagram.

The AI governance guide for security architects maps the wider governance policy to this model-call path. Local execution, STDIO transport and stolen credentials remain outside an HTTP gateway boundary and need their own controls.

Pass condition: every production model route has a named trust boundary and enforcement point, or it is recorded as an excluded path with a separate owner.

Check 3: bind identity to the requested resource

Specify the identity assertion supplied by the application, including issuer and audience; add the claims the policy decision needs, such as role or tenant. Then define the resource precisely enough to authorize it. "Approved model" is too broad when one route permits public support content and another carries regulated records.

NIST SP 800-207 separates the policy engine, policy administrator and policy enforcement point. Section 3 assigns the access decision and its log to the policy engine. The policy administrator executes that decision, while the enforcement point controls the connection. This checklist applies that logical split to an HTTP LLM route. The AI gateway pattern and security architect signature are organizational design choices.

The identity-aware AI gateway pattern covers the post-authentication gap in more detail. A shared provider key identifies the application account. The design still needs a trustworthy way to carry the originating user or agent into the request decision.

Pass condition: the architecture names the identity source and validation rules, then binds the verified principal to a specific route and destination under a versioned policy.

Check 4: allocate each control to one component

Put a control owner beside each architectural function; the application authenticates its user and supplies business context. Retrieval authorization belongs where the system selects source material. The request-path policy point evaluates the assembled HTTP payload before transmission. Provider controls govern the provider surface, while destination systems retain authority over downstream actions.

This allocation should appear in the diagram and the decision record. NIST SP 800-53 PL-8 describes architectures that allocate security and privacy functionality and document external interfaces. SA-8 also calls for logical boundaries plus threat modeling during specification and design. Those outcomes support a reviewable allocation without assigning the work to a particular job title.

Pass condition: every claimed control has one implementing component and a named owner, with any overlap recorded in the decision. A diagram label such as "security layer" leaves the allocation unresolved.

Check 5: specify failure and bypass behavior

Write the outcome for missing identity, unavailable policy and failed evidence storage; define what happens when the approved provider times out or a fallback resolves to another region. The architecture should also show how network policy keeps protected model traffic on the governed route.

Record these as design requirements. Engineering will later prove them against a release candidate. At architecture approval, the security architect decides which failures must stop the request, which may use an approved fallback and which require a user-visible error. A silent direct route around policy should block approval.

The NIST AI Risk Management Framework assigns contingency processes for failures involving high-risk third-party data or AI systems in GOVERN 6.2. That outcome supports a defined failure model. Each organization still has to approve its fallback design.

Pass condition: the decision record states closed behavior for missing security context and names every approved fallback. Bypass prevention has an owner and an acceptance criterion.

Check 6: define the evidence contract

Specify the record that each policy decision must emit; it should identify the caller reference and application, followed by the route and destination. Add policy version, outcome and event time. Include a correlation value that can connect the decision to application and provider telemetry without placing unrestricted prompt content in a general log index.

Decide who controls the write path and retention policy. Evidence used to assess the calling application should survive that application's failure or attempted deletion. The signed audit log guide explains why independent custody and tamper evidence matter at this boundary.

Picture one denied request written on a review card beside the diagram. The card should let an investigator reconstruct who asked, which policy acted and where the request stopped. If those answers require three undocumented joins, the evidence contract needs another design pass.

Pass condition: the architecture defines a stable record schema, custody model and retrieval path. Acceptance criteria require reconstruction of one permit decision and one denial.

Check 7: sign the architecture approval record

The decision page should point to the fixed diagram and threat model, then list assumptions and external dependencies; record excluded paths, residual risks and required follow-up designs. State one outcome: approved, approved with conditions or rejected.

The signature authorizes the architecture for implementation. Production authorization comes later, when a CTO release gate examines an exact build and rollback proof. Platform engineering approves material route or policy changes against deployed infrastructure. CISO reporting covers operating risk, incidents and control performance across the estate.

I would reject any approval whose assumptions live only in meeting notes. Architecture fails at the edges people remembered discussing and never wrote down.

Pass condition: the accountable architecture authority signs and dates the record. A changed trust boundary, identity contract, model destination, control allocation or external dependency reopens review.

DeepInspect

DeepInspect is a stateless proxy between authenticated users or agents and LLMs. It enforces identity-aware policy on HTTP AI traffic and produces a signed, tamper-evident audit record for each decision outside the calling application's write path.

That gives a security architect a concrete policy enforcement point and evidence path for governed model routes. The application remains responsible for identity context. Retrieval systems retain document authorization, and destination tools enforce their own permissions. Local execution, STDIO transport, stolen credentials and direct traffic that bypasses the governed HTTP route sit outside DeepInspect's boundary. Book a technical deep dive at deepinspect.ai.