Customer Access and Data Controls
Access to customer information and systems must follow the approved assignment and delivery arrangement. The architecture distinguishes customer identity, customer-specific configuration, permitted capabilities, and human authority.
Access and responsibility matrix
| Actor or layer | Responsibility | Boundary |
|---|---|---|
| Customer | Authorize requestors, approvers, sources, systems, and changes | Customer business authority and customer-controlled credentials |
| THINK Strategist | Scope work, manage execution, coordinate approvals | Agreed assignment and approved access |
| Managed Team | Execute specialized tasks | Authorized inputs and capabilities only |
| Harness | Assemble governed context and resolve approved capabilities | Reusable job definitions must not embed customer proprietary context |
| MCP/customer adapter | Mediate permitted operations | Authentication, tenant and user checks as implemented |
| Customer system | Enforce its own access and change controls | Customer-approved environment and policies |
Capability and context flow
Assignment → Authorized customer context → Team capability request → Policy and provider resolution → Approved resource → Reviewed output
The THINK Harness context specification describes shared context assembly across teams and customer-controlled sources. Customer-specific proprietary context should remain governed by the appropriate control plane rather than being hard-coded into reusable Digital Employee definitions.
Commercial adapter controls: what the code documents
The THINK-Commercial/MCP/customer-adapters/README.md documents a customer-facing adapter design for Capture-to-Proposal handoffs. Its tests cover the following cases:
| Case | Documented behavior |
|---|---|
| Malformed request | Return a typed not-authorized decision instead of executing |
| Missing identity | Reject before tenant resolution |
| Unknown tenant | Fail closed |
| Unapproved authenticated user | Reject before forwarding the operation |
| Mismatched nested identity | Reject inconsistent customer/deployment identifiers |
These are documented and tested adapter behaviors, not proof that a production MCP endpoint is deployed or that every integration uses the same adapter.
Delivery arrangements
| CL-managed delivery | Customer-environment delivery |
|---|---|
| CL operates approved infrastructure and tools | Work occurs in specifically authorized customer systems |
| Customer authorizes access to information or systems needed for the assignment | Customer controls applicable credentials, policies, and environment permissions |
| Results are delivered through agreed channels | Results are delivered or applied only to agreed destinations |
Connectivity is not blanket permission. Writing code, merging a repository change, and deploying to production may each require different approval.
Related documentation
Security and Governance · MCP and Capability Integrations · Managed Work Delivery Architecture · Service Activation · Official MCP documentation