Retrospective coverage for the October 20, 2026 issue.
An employee may know when an agent has misunderstood a job without needing permission to change its operating limits. Trinity’s permissions documentation, pinned to the commit associated with its October 20, 2026 v1.0.0 release, makes that distinction explicit. As of that issue date, it describes a Workspace-only user role for working with shared agents, separate from the roles that open the management interface. That separation offers a useful product choice: participation without equivalent administrative authority.
The boundary is documented as server-side, not merely a hidden menu. A Workspace-only account calling an operator route receives 403 workspace_only, whether the request comes through the browser, API or an MCP key belonging to that account. Agent sharing also does not itself create a platform account. Together, these rules distinguish access to an agent’s work from access to the machinery that operates it.
There is a second, subtler boundary: whose credentials are making the request. The document says an MCP key carries its creator’s role. An agent’s key created under an admin owner could therefore pass a check that examined only that role. Trinity documents additional principal and scope checks: agent-scoped keys cannot satisfy admin gates, and configuration writes reject agent-scoped and system keys even when the owner is an admin. In this documented design, inherited status is insufficient authority to raise the agent’s own limits.
Consider a hypothetical maintenance dispatcher using a shared agent to discuss an unusual service request. Workspace access could let the dispatcher contribute the exception while leaving changes to autonomy, guardrails and capacity with an authorized owner or administrator. The opportunity is not simply tighter security. It is a way to involve more practitioners in the work without also distributing control over the agent’s operating envelope. That does not establish that their contributions improve the model or reduce workload.
The qualification matters: this is a documented permission design, not an independent enforcement test. Roles apply across agents, and the source explicitly allows unauthenticated public links, so the Workspace boundary is not a claim that every interaction is authenticated. The stronger product proposition is narrower: widen who can collaborate while keeping configuration authority separately assigned and checked.
