Trust Boundary
A trust boundary separates contexts with different permissions, control, or assumptions. Crossing it requires deciding what the receiving component may accept and do. A boundary can exist inside one process, not only between machines.
Content cannot grant permission
A policy page may be a useful source of refund facts. It has no authority to authorize exporting customer records. When the model proposes an export, the application must apply the caller's permissions independently of the page's wording.
A verified tool response may still contain a customer-written note. Authenticating the service does not turn every sentence it returns into a trusted instruction. The refund page and the customer note are illustrative examples of this entry, not documented incidents.
Recheck repeated crossings
If tool output returns to the model, a later tool proposal must pass authorization again. The OWASP Authorization Cheat Sheet advises validating permissions on every request regardless of its source, and OWASP’s guidance on excessive agency calls for authorization in downstream systems instead of relying on an LLM to decide whether an action is allowed, with all requests made through extensions validated against security policies. Mark the enforcing component and observe what crossed it. A diagram label alone does not enforce the boundary.
References
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.