AI Trust Boundary Map

# AI Trust Boundary Map

Sample Deliverable

Executive Summary

This trust boundary map turns a customer-facing AI copilot into a reviewable system. It shows who enters the system, where data moves, where authority expands, where third parties become involved, where evidence is created, and where controls must hold.

The main conclusion is blunt: the AI gateway is the control center, retrieval is the most important data boundary, and tool execution is the highest-risk authority boundary.

Heads up

Public sample notice

This is a shortened, synthetic excerpt prepared as a public sample. A client version would include system-specific evidence, implementation references, architecture screenshots, control test results, owner sign-offs, and full supporting documentation. This sample uses Northstar Support Cloud / Customer Support Copilot as the synthetic reference system. This sample is not legal advice, not a compliance certification, not an audit opinion, not a warranty, and not proof that any unreviewed system is secure.

Decision · conditional

Recommended review decision

Proceed with controlled pilot use, but do not expand enterprise rollout until retrieval authorization tests, the agent permission matrix, and sensitive AI trace handling are complete.

Metrics

Boundary Snapshot

Trust zones

Critical boundaries

High-risk data flows

Partial controls

Release blockers

Note

What this gives a buyer

The buyer can see that the AI system is not a black box. The buyer can review data flows, provider exposure, retrieval controls, tool authority, human approval, and logging evidence without relying on vague responsible AI language.

System in scope

The sample system is a customer-facing support copilot that uses RAG, a third-party model provider, workflow tools, approval screens, and AI trace logging.

Trust boundary map

Northstar Support Cloud / Customer Support Copilot Trust Boundary Map

The map identifies the AI gateway as the primary enforcement point and the tool layer as the boundary where generation becomes operational authority.

Synthetic sample trust boundary data for a customer-facing AI copilot using retrieval, model-provider routing, workflow tools, approval screens, and AI trace logging.

Nodes

Boundaries

Flows

Controls

actor

Authenticated User

medium

application

SaaS Web Application

medium

control-point

AI Gateway

critical

data-store

Retrieval Index

critical

third-party-service

Model Provider

high

tool-surface

Workflow Tools

critical

human-review

Approval Console

high

observability-store

AI Trace Store

high

Prompt submitted

Session auth, tenant scope, request validation

medium

Prompt envelope created

Gateway-only model access, request classification, tenant binding

high

Retrieval query

Authorization-preserving retrieval filters, source ACL tests

critical

Model call

Data minimization, provider boundary, training exclusion statement

high

Tool plan prepared

Permission matrix, action class policy, tool allowlist

critical

Approval request

Human approval with evidence bundle and reviewer identity

high

Boundary

Tenant Boundary

Separates one customer tenant's data, retrieval results, logs, and tool actions from another tenant.

Boundary

Retrieval Authorization Boundary

Ensures source-system authorization survives indexing, chunking, retrieval, reranking, and prompt assembly.

Boundary

Model Provider Boundary

Controls what data leaves the product boundary and how model provider commitments are represented to buyers.

Boundary

Tool Authority Boundary

Separates text generation from state-changing tool authority.

Boundary findings

Findings

Top Boundary Findings

Finding · critical

Retrieval authorization is not yet proven end-to-end

Evidence: rag-authz-test-plan

The system relies on tenant and source filters, but the evidence does not yet prove that authorization survives indexing, chunking, semantic retrieval, reranking, and prompt assembly.

Heads up

Why this matters

A user can receive restricted information through a generated answer even when the source document would not be directly accessible in the product UI.

Finding · critical

Tool authority is not fully separated by action class

Evidence: agent-tool-permission-matrix

The system does not yet fully separate read, suggest, draft, queue, approve, and execute actions across the tool layer. That makes it harder to reason about blast radius.

Finding · high

AI traces need sensitive evidence handling

Evidence: trace-classification-design

Prompts, retrieved snippets, model outputs, tool calls, and approval records may contain customer-sensitive information. They need explicit classification, retention, access control, and incident-response treatment.

Trust zones

Trust zone inventory

Zone	Purpose	Primary owner	Risk
External user zone	Prompt entry and response review	Product	Medium
Product zone	Application session and UI controls	Application Engineering	Medium
AI control plane	Prompt policy, routing, retrieval, tool policy	AI Platform Engineering	Critical
Retrieval zone	Indexed customer and support content	Search Platform	Critical
Provider zone	Third-party model processing	Vendor Management	High
Action zone	Workflow tools and state-changing APIs	AI Platform Engineering	Critical
Oversight zone	Human approval and review context	Product Operations	High
Evidence zone	AI traces and audit reconstruction	Security Engineering	High

Data flows

High-risk data flows

Flow	Boundary crossed	Risk	Required control
Prompt envelope	Product to AI gateway	High	request classification and tenant binding
Retrieval query	Gateway to retrieval index	Critical	authorization-preserving retrieval tests
Model call	Gateway to model provider	High	minimization and provider boundary statement
Tool plan	Gateway to workflow tools	Critical	permission matrix and action-class policy
Trace write	Gateway to trace store	High	sensitive evidence handling

Control interpretation

Control map

Boundary control map

The control map connects the diagram to practical ownership. Each boundary needs an owner, an implementation status, and evidence a buyer or security reviewer can inspect.

Synthetic sample trust boundary data for a customer-facing AI copilot using retrieval, model-provider routing, workflow tools, approval screens, and AI trace logging.

Gateway-only model access

implemented

Authorization-preserving retrieval

partial

Tool action class policy

partial

Approval context bundle

partial

Sensitive AI trace policy

planned

Decision · conditional

Engineering decision

Make the AI gateway the only path to model calls, retrieval, tool execution, and trace creation. Do not allow product teams to bypass the gateway for convenience integrations.

Remediation plan

Checklist

First remediation wave

✓Add end-to-end retrieval authorization regression tests.

✓Convert tool access into read, suggest, draft, queue, approve, and execute action classes.

✓Add approval context bundles for sensitive actions.

✓Classify AI traces as sensitive operational evidence.

✓Produce a buyer-ready model provider boundary statement.

✓Add architecture evidence links for each boundary.

Note

Commercial impact

This artifact reduces enterprise review friction because sales, security, legal, and engineering can point to the same boundary model instead of answering buyer questions from memory.

Appendix: client evidence checklist

Checklist

Evidence to collect for a real client version

✓Current AI architecture diagram.

✓Model provider contract and data-use terms.

✓Prompt envelope schema.

✓Retrieval authorization tests.

✓Tool inventory.

✓Human approval workflow screenshots.

✓AI trace schema and retention policy.

✓Security questionnaire responses.

✓Incident reconstruction examples.

Artifact

Related artifact: Agent Tool Permission Matrix

The trust boundary map identifies where authority changes. The permission matrix defines what each agent is allowed to do at those authority boundaries.

/deliverables/agent-tool-permission-matrix