6.8 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, locked versions, and associated scopes |
| Role tool permissions | Whether the current employee 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 uses annotations such as readOnlyHint to describe intent. Whether or not a client retains them, the server must check identity, object access and arguments, and Teloa must check the employee's tool grants.
Web access and files
Employee 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.
Employee API exception: a business system can set permissionMode per request. When omitted, new work defaults to danger-full-access and a continuation inherits the previous round. The mode changes only that round's sandbox and approval boundary; it does not expand the employee's tool grants or bypass the integration's execute permission or workbench approval. Callers should explicitly choose the smallest mode that meets the business need; see Employee API execution modes.
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.