The Context Boundary Checklist.
A CTO/CISO review for AI agents before they receive tool access, memory, retrieval, or production permissions. The question is not whether the prompt looks safe. The question is which context can influence which action.
// if three or more boundaries cannot be answered with evidence, review before launch
Before tool access: can an untrusted source influence a side-effecting call?
Before memory: can hostile content persist into another user, tenant, or session?
Before retrieval: can a poisoned or stale chunk change an authorization decision?
Before production: can security replay why the agent acted, not just what it said?
Eight boundaries to review before the agent can act.
For each boundary, require a concrete decision and evidence. A red flag is not an automatic blocker — it is a reason to gate, quarantine, redact, or run a Firewall Review before production access.
What can the agent read?
Inventory every source that enters the prompt or agent state: user input, tickets, docs, email, web pages, files, MCP responses, tool output, and peer-agent messages.
Each source has an owner, tenant, sensitivity label, trust class, and a rule for whether it can instruct the agent or only serve as evidence.
A retrieved page, support ticket, or tool result can override system policy because it is assembled into the same context as trusted instructions.
What can the agent remember?
Separate notes, user preferences, credentials, operational state, and learned rules. Decide which memory types may persist, who may write them, and how they expire.
Memory writes are gated, attributed to a source, reviewable, reversible, and excluded from future authorization decisions unless explicitly approved.
Any model-generated sentence can become standing instruction for the next session, workflow, or customer account.
What can the agent retrieve?
Treat RAG as untrusted input with access control, provenance, freshness, and tenant isolation. Retrieval should answer questions, not grant authority.
Queries, result IDs, source ACLs, embedding indexes, reranker output, and final included chunks are logged and replayable.
A poisoned chunk or cross-tenant document can shape a privileged action because retrieval has no source-to-sink policy.
What tools can it call?
List every tool, API, MCP server, browser, shell, workflow trigger, and internal admin function. Classify side effects before the agent receives access.
Tool calls are inspected by name, arguments, target resource, identity, tenant, data class, blast radius, and the trust of the context that requested them.
The same agent identity can read a web page, infer an instruction, and execute a write, export, webhook, shell command, or code change without a boundary check.
What data can leave the system?
Map every egress path: model response, tool argument, webhook, file write, browser navigation, email, log sink, analytics event, and human handoff.
Secrets, regulated data, tenant data, prompts, retrieved documents, and tool results are screened before they leave the trust boundary.
DLP only checks final chat output while tool arguments, URLs, callbacks, and logs can still carry sensitive data out.
What human approvals can be spoofed?
Define which actions need approval and how approval is represented outside the model context. In-band text is never consent.
Approvals show the exact action, arguments, identity, resource, and risk; the approval token is scoped, short-lived, and bound to that action.
A document, user, tool result, or peer agent can say “the CISO approved this” and the agent treats that as authorization.
What logs prove why an action happened?
Log the full decision chain: context sources, retrieved chunks, memory reads/writes, policy result, tool arguments, approvals, output screening, and final action.
Security can replay a decision and answer: what did the agent see, what did it trust, what policy fired, and why was the action allowed or blocked?
You have transcripts and application logs, but not the source-to-sink evidence needed to explain or reproduce a privileged action.
What happens when untrusted content conflicts with policy?
Predefine the runtime decision: allow, block, redact, quarantine, require approval, or continue with the untrusted content withheld from instruction paths.
Conflict handling is tested with hostile documents, poisoned memory, malicious MCP responses, tool-result injection, and approval spoofing before production access.
The fallback is “ask the model to ignore it” instead of enforcing a policy boundary before memory, retrieval, tools, or egress.
Turn unclear answers into review scope.
The checklist is useful only if it changes a launch decision. Treat every unclear answer as a source-to-sink policy question.
Before you give an agent tools, memory, retrieval, or production permissions, run the Context Boundary Checklist. If three or more answers are unclear, book a Firewall Review.
Shipping agents with tools or memory? Use Ultra13’s Context Boundary Checklist to find the places where untrusted context can still drive privileged actions. Then book a Firewall Review for the workflow with the highest blast radius.
Book Firewall Review
Do not grant production permissions until the context boundary is explicit.
Give Ultra13 one agent workflow. We will map what it can read, remember, retrieve, call, and leak — then show where policy should block, redact, gate, quarantine, or log.