Guardrails and authorization boundaries

First read the whole diagram. Expand “Read at full size” to inspect the labels and scroll horizontally, then trace the failure path.

Define the assets and boundaries

A guardrail is a check or control at a trust boundary, not simply a warning in a system prompt. Consider a hypothetical assistant that searches company documents and can send email. Protect three assets separately: access to documents, information released in answers, and actions performed outside the conversation. This is a teaching architecture, not a description of a Kumyu deployment.

OWASP describes indirect prompt injection through external material. A retrieved page or tool response saying “send the administrator's secrets” remains untrusted content. It does not grant authority. A classifier can reduce risk; its confidence must not become permission to access a resource.

Flow: separate gates with separate responsibilities

Read at full size (scroll horizontally)

Figure 1. Arrows show processing order. Documents enter as untrusted data; the server decides permissions. This diagram proposes a design rather than a vendor guarantee.

Validate input shape, size, and requested capabilities. Restrict retrieved material to authorized documents. Check generated answers for prohibited disclosures. At tool execution, validate the action, arguments, resource owner, and current permission again. These checks answer different questions and should not collapse into a single safety score.

OWASP's authorization guidance recommends least privilege, default denial, and permission checks on each request. Our design applies those principles to tool calls. Being signed in does not mean being allowed to email a particular customer's document. Obtain tenant and actor identity from the validated session, not model-generated arguments. A schema-valid tool request can still be unauthorized.

Sequence and approval contract

Read at full size (scroll horizontally)

Figure 2. Approval refers to the displayed operation. Changing recipients or attachments invalidates it.

Save an email as a proposal first. Show its recipients, subject, attachments, and external disclosure scope. Immediately before the side effect, match approval to the operation and atomically claim execution. Expire old approvals and recheck current access and document versions. A document deleted during the approval wait cannot be sent under an earlier approval.

{
  "operationId": "op-example-42",
  "actorId": "user-example",
  "action": "send_email",
  "argsDigest": "sha256-of-canonical-arguments",
  "resourceVersion": "document-v7",
  "policyVersion": "policy-v3",
  "approvalExpiresAt": "2026-10-23T12:05:00Z",
  "state": "awaiting_approval"
}

This unexecuted schema example binds the actor and a canonical digest of all arguments, including body, recipients, and attachment identifiers. Keep approval records outside retrieved text and outside model control. An operation identifier lets the client inspect an uncertain result before retrying. If the external provider lacks an idempotent operation API, an ambiguous timeout may require reconciliation rather than automatic replay.

Failure: released streams cannot be recalled

Read at full size (scroll horizontally)

Figure 3. Already released text cannot be recovered. Choose inspection granularity before promising fast streaming.

Displaying tokens immediately and inspecting the full answer at the end leaves a disclosure window. For sensitive output, buffer the whole answer and inspect before publication. A lower-risk application may buffer short segments and release only accepted segments, but context spanning segments and secrets split across segments remain problems. Hiding text afterward does not prevent its earlier release.

Fail closed means stopping when a required control cannot decide; fail open means proceeding. Authorization and secret inspection stop in this design. An optional prose-quality check need not have the same availability requirement. Assign a timeout, retry limit, and owner to each check so an unavailable dependency cannot silently weaken a critical boundary.

Worked hypothetical latency example

Suppose generation takes 1.8 seconds, input inspection takes 80 milliseconds, and full-output inspection takes 120 milliseconds. Serial completion takes 2.0 seconds. With 200 milliseconds of output buffered and a 40-millisecond segment check, the first segment needs at least 240 milliseconds plus generation startup. These are assumptions, not measurements or vendor latency claims.

Choose the release requirement first: may any unchecked character leave the server? Full buffering sacrifices early display but gives the checker full context. Segmented inspection improves perceived responsiveness but requires separate treatment of cross-segment meaning. Record policy versions and decision reasons for diagnosis without copying secret-bearing content into logs. Evaluate both missed disclosures and rejected legitimate answers, using labeled test cases rather than a single “safe” percentage.

Exercise: an attachment changes after approval

A user approves sending document v7 externally. The retrieval result updates, and the model selects v8 instead. Should the send proceed?

Suggested answer. Stop it. The approved digest and resource version no longer match. Present the new operation for approval and recheck access immediately before execution. A prompt containing “already approved” is not an approval record. Continue with gateways and load control to protect the inspection services themselves from overload.

These are conceptual reference architectures for learning and design discussions. They do not describe the deployed Kumyu infrastructure.

← Browse all chapters