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.
Operation-specific workspace paths
In 0.2.12, formal tool grants may carry workspacePaths, listing files and directories separately for read, write and edit rules. The owner explicitly saves them through employee Permissions, and the run freezes them. Without this policy, existing workspace behavior remains; a model cannot infer or expand grants from natural language.
The actual filesystem is checked again: parent escapes, symlinks and protected paths cannot bypass the policy; new paths check their nearest existing real parent. Editing requires the intersection of read and write grants. A file successfully written by the current Run within its granted scope can be delivered under matching receipt and SHA checks, without granting arbitrary model reads of outputs. Write permission must not implicitly read an existing protected file.
With fine-grained file rules, arbitrary-code routes that cannot enforce the same policy remain unavailable. An FS proxy is not operating-system isolation. Extensions must not ignore an unrecognized rule and proceed with broader access.
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.