Security and Governance Model
Compound Leverage manages customer assignments through agreed access, data-handling, and human approval arrangements. This article explains documented architectural controls; it does not claim a specific third-party certification or assert that all source-code controls are deployed in production.
Shared responsibility
| Area | Customer | Compound Leverage |
|---|---|---|
| Work authorization | Approves scope and authorized requestors | Confirms and coordinates assigned work |
| Business decisions | Retains designated decision and approval authority | Prepares work and escalates consequential decisions |
| CL-managed environment | Approves customer information and integrations supplied | Operates CL-managed delivery tools and services |
| Customer environment | Controls environment access, credentials, and applicable policies | Works only within agreed permissions and scope |
| Code changes | Approves repositories, change authority, and production deployments | Implements and reviews authorized changes |
| Delivery | Reviews and accepts as agreed | Validates and delivers agreed work products |
Authorization model
The architecture specifies that permitted capability use is the intersection of human authorization, Digital Employee authorization, and workflow policy. A tool being connected does not grant permission to use it for a particular customer or task.
The Commercial customer-adapter code and tests document rejection paths for malformed requests, unknown tenants, missing or unapproved identities, and inconsistent identity fields. These are implementation-level examples of enforcing an access boundary.
Information and system boundaries
| Boundary | Documentation principle |
|---|---|
| Customer-provided information | Use only for the authorized assignment and under applicable arrangements |
| CL-managed infrastructure | Describe deployed services and controls only after configuration verification |
| Customer-owned repositories and applications | Use explicitly approved access paths |
| CL-controlled MCP capabilities | Expose only approved interfaces and authorized inputs |
| Customer-controlled integrations | Preserve customer-approved permissions and access requirements |
| Deliverables | Use agreed review, approval, and delivery channels |
Review and change controls
Human review applies where required by the assignment and its risks. Research evidence, document completeness, test results, and other acceptance criteria should be checked before delivery. Code authoring does not itself authorize merging or production deployment; those actions require their own approved scope and change authority.
Implementation status and assurance
| Evidence | What it supports | What it does not prove |
|---|---|---|
| Architecture specification | Intended component boundaries and design | Production availability |
| Code and automated tests | Implemented logic and tested cases | Complete runtime enforcement |
| Deployment configuration | Defined deployment mechanism | That a deployment is currently healthy |
| Live infrastructure verification | Observed deployed configuration at review time | Unverified certification or guarantees |
The THINK Commercial deployment architecture explicitly identifies infrastructure not yet implemented at the time of that review. Public claims about production availability, data retention, tenant isolation, certifications, or guarantees must be validated against the current environment and agreements.
Related documentation
Customer Access and Data Controls · MCP and Capability Integrations · Work Orchestration · Service Activation · Google Cloud Architecture Framework
Control evidence by environment
The delivery architecture supports CL-managed and customer-controlled execution arrangements. The appropriate control evidence depends on where work is performed.
| Control area | CL-managed delivery: evidence to verify | Customer-environment delivery: evidence to verify |
|---|---|---|
| Identity | Actual service and operator identities | Customer-approved identities and access grants |
| Authorization | Configured task and capability permissions | Customer role policies plus assignment scope |
| Data boundary | Deployed storage and processing configuration | Customer-approved data paths and system controls |
| Tool integration | Enabled providers and secrets handling | Approved adapters, customer permissions, and credentials |
| Review gates | Recorded strategist and other human decisions | Customer approvals and change-management records |
| Code changes | Repository permissions, review, and test evidence | Customer repository and deployment approval records |
| Operational assurance | Current logs, health, and deployment evidence | Jointly agreed monitoring and escalation responsibilities |
These are verification questions, not statements that a particular certification, audit log, retention period, or infrastructure control is already enabled.
Commercial MCP adapter: tested boundary cases
The customer-adapter README in THINK Internal documents tested rejection paths:
| Request condition | Documented response principle |
|---|---|
| Malformed request | Typed NOT_AUTHORIZED result |
| Missing customer, deployment, or authenticated-user identity | Reject before tenant resolution |
| Unapproved user | Reject before underlying operation |
| Inconsistent nested customer/deployment identifiers | Reject rather than allow cross-context execution |
These are implementation-level checks in a specific commercial handoff adapter. They do not prove all other integrations have equivalent enforcement or that the Commercial MCP server is deployed.
Human authority for consequential work
| Activity | Typical decision boundary |
|---|---|
| Research and draft production | Agreed assignment and source authorization |
| Business recommendation | Human evaluation and customer decision |
| External communication or contractual representation | Authorized customer approval |
| Code authoring | Approved repository and change scope |
| Code merge or production deployment | Separate customer or environment-owner authorization |
Security questions to confirm before a production claim
- Which exact service and commit are deployed?
- Which identity and tenant checks execute on the live request path?
- Which customer information is processed or stored, and where?
- Which logs, retention settings, and incident procedures are actually configured?
- Which approvals are recorded, and which are manual rather than enforced by software?
- What changes when execution takes place inside the customer’s environment?
Technical references
Customer Access and Data Controls · MCP and Capability Integrations · Service Activation · Work Orchestration · Google Cloud Architecture Framework