6.5 Understand execution authorization boundaries

When developing an extension, check both the tool's own boundaries and Teloa's authorization during dispatch and execution. Declaring a tool “read-only” does not replace access control.

Check each layer

Layer	What to verify
References and business scope	Sources visible to the caller, pinned versions, and associated scopes
Role tool permissions	Whether the current colleague may use this exact full tool name
Current action	Whether the arguments and approval still cover the action about to run
Harness	Execution policies for the workspace, files, subprocesses, and network
External system	Service accounts, read-only credentials, object permissions, and write protection

Current MCP limitations

The reference service provides annotations such as readOnlyHint, but the current DSH MCP registration path does not preserve all of them. Do not automatically relax permission requirements based solely on annotations, or treat the word “read” in a tool name as a safety guarantee.

Web access and files

Colleague web access is subject to the global switch, role permissions, and specific execution policies. Search and webpage reads make external requests. Test boundaries such as redirect chains against the actual implementation rather than making a blanket claim that all domains are blocked.

The default composition uses a dedicated workspace and the workspace-write policy. Third-party tools, session permissions, and external credentials still require separate verification. The Docker deployment does not mount the host's entire filesystem or Docker socket by default; that does not make every plugin action automatically safe.

Minimum acceptance matrix

Test the same task in each condition: rejected without permission, successful with permission, rejected after permission is revoked, source unavailable, invalid arguments, and stopped during execution. Record actual tool responses and business results. Do not rely only on the model saying that an operation succeeded.