GuardLLM system map

Five source families feed four trust boundaries and two outbound lanes. Per-flow context and per-session state remain separate because they answer different questions and change on different lifecycles.

Start here: see one blocked leak change the next decisionPrimary narrative · cross-stage escalation across all four boundaries

Skip architecture links

EmailWebDocumentsRAG MCP

Boundary 1IngressOpen ingress demo →Application + modelOpen primary narrative →

Outbound contentBoundary 2EgressOpen DLP and canary demo →Users and data sinks

Tool proposalBoundary 3AuthorizationOpen policy demo →Boundary 4IntegrityOpen request binding demo →Tools and action sinks

The lanes can overlap: a tool call can require authorization and integrity checks while its outbound arguments require separate egress inspection.

Per-flow contextOpen security context demo →Provided by the host on each flowsource trust · principal trust · sensitivity · content type · policy

Per-session stateRetained by GuardLLM across callsremembered canary provenance DLP history contamination escalation rate counters

Explore one mechanism

Security contextWhat the host declares per flow IngressActual processing order MCP tool surfaceProse asks; only a directive authorizes RAG provenanceLexical no-copy boundary Tool feedbackHost closes the loop DLP and canaryKnown, statistical, and remembered signals PolicyScoped decision lanes Rate limitingAnomaly versus denial Request bindingArgument integrity