# Test the boundary before the demo

A successful answer tells you less than a carefully chosen case the system must refuse, qualify, or hand back.

By Sam M. Sweilem — https://sweilem.ai/sam-sweilem/
Published: 2026-09-09
Reviewed: 2026-09-09

Suppose an assistant answers a question about an equipment-return deadline and cites the right policy paragraph. That gives us a useful first case, but we also need to check what happens when the paragraph is missing or the policy does not cover this customer. A retrieved attachment that tries to override the policy gives us a different failure to investigate.

I want the intended boundary written down before the demonstration. Otherwise the team can quietly reinterpret an unexpected answer as acceptable because it sounds plausible. This guide uses a synthetic policy assistant to show how to turn a context brief into a small, reviewable set of evaluation cases.

## Describe the behavior a reviewer should check

“The answer should be reliable” gives a reviewer very little to inspect. “When the policy does not specify a deadline, the answer says the deadline is unknown and identifies the policy owner” describes observable behavior. The expected result need not prescribe every word. It does need to constrain the consequential decision.

Check that the cited section exists and applies to the question, then compare the answer with what that section actually says. The assistant may have added a rule that has no support in the source, even though its wording reads well. A language review alone would not catch that problem.

The workbench checks whether you have entered multiple cases, so it cannot tell you whether those cases are useful. A reviewer still needs to decide whether each one specifies behavior that can be tested. Adding two vague statements would satisfy the count without giving the team a usable test.

## Start with five deliberate changes

Begin by removing the governing section and checking whether the assistant explains that it lacks the evidence to answer. With an outdated version, the expected response should follow the refresh rule in your plan. A conflicting draft tests whether the assistant respects the source-authority rule before proceeding.

A separate case should place an instruction in a retrieved document that asks the agent to ignore its task. Check that the system continues to treat the document as evidence under the existing instructions. Then test a request for information the caller is not permitted to access. The retrieval system must enforce that restriction before returning protected information; generating a refusal afterward would be too late.

Keep the fixtures synthetic. Give each case an identifier, input, applicable source version, expected behavior, observed behavior, and reviewer decision. Preserve failures alongside passes. If you change the expected behavior after a failure, record the reason and who accepted the change.

## A prompt cannot grant or enforce access

An instruction such as “only use authorized tools” is useful communication, but it is not authorization. The server receiving a request needs to validate the caller and the requested action. The application must distinguish a proposed action from an action already approved for execution.

The [MCP authorization security considerations](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/basic/authorization/security-considerations.mdx) make a concrete distinction: tokens must be intended for the receiving MCP server, and a token received from the client must not simply be passed to an upstream service. That protocol requirement is one example of a boundary implemented in software rather than prose.

The workbench’s access and approval fields document your intended boundary. They do not inspect credentials, call your servers, or certify enforcement. A documented field is a starting point for implementation review.

## Keep the test tied to the thing you will release

A recorded pass should identify the relevant prompt or brief version, source fixture, model configuration, tool behavior, and application revision. If one of those changes, decide which cases need to run again. That is more useful than copying a green badge from a previous demonstration.

My recommendation is to start with a small set whose failures your team can interpret, then expand it when a new failure mode teaches you something. This is an operating proposal, not comparative evidence about any vendor or a universal pass threshold.

You can practice reviewing your own work through [FDE Benchmark](https://fdebenchmark.org/) and use the [AI SDLC implementation notes](https://aisdlc.ai/insights) to connect a change with its acceptance evidence. The same issues belong in an enterprise implementation discussion with [LockedIn Labs](https://lockedinlabs.ai/ai-consulting/).

## Sources

- [Model Context Protocol — Authorization security considerations](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/basic/authorization/security-considerations.mdx) — Specification edition: July 28, 2026. Reviewed September 9, 2026.

Published by LockedIn Labs. https://lockedinlabs.ai/