01
Two gates
MCP does not authorize the underlying connector
An MCP server can describe resources and actions to an agent, but it cannot make an unapproved LinkedIn access path lawful or available. DewEngine has no released LinkedIn adapter, and the account product remains decision-gated. The MCP design starts only after provider and legal approval, then adds a second control layer for which customer user and agent may read context or propose an action.
- Keep the LinkedIn tool set absent while the provider gate is closed
- Do not use agent autonomy to bypass a human action policy
02
Tool design
Expose task-sized tools instead of a master credential
A safe server might eventually distinguish account status, profile lookup, search review, conversation context, draft creation, and approved command submission. Each tool should declare read or action scope, input constraints, tenant ownership, and result uncertainty. Do not hand an agent a broad application key or raw provider session. Capability discovery must reflect the exact connected product and current release state.
- Separate read scopes from provider-visible action scopes
- Return bounded structured fields rather than whole raw payloads
03
Human control
Make sensitive actions approval-shaped
An agent can research context or prepare a draft, but invitations, messages, posts, and job actions need policy evaluation and human approval appropriate to the workflow. Approval binds sender, recipient, final content, purpose, and expiry. A later model edit or tool retry must not inherit authorization. The MCP response should return a proposal or durable command state, never imply that reasoning alone completed the provider action.
- Require a new decision after material content changes
- Show the account and destination in the approval interface
04
Data exposure
Minimize context sent to the model
Message bodies, candidate data, relationship graphs, and profile text may be personal or confidential. Retrieve only the fields needed for the current tool call, redact secrets and irrelevant content, and avoid retaining prompts or outputs beyond the customer policy. Resource IDs must be tenant- and account-scoped so an agent cannot enumerate another workspace by guessing identifiers.
- Use short-lived, audience-bound credentials for tool sessions
- Audit resource reads as well as attempted writes
05
Execution truth
Return evidence-rich states to the agent
A submitted command can be acknowledged, refused by policy, rejected by the provider, throttled, or indeterminate after a timeout. The tool result must preserve those distinctions and tell the agent whether retry is permitted. Provider acknowledgement is not recipient delivery or reply. Idempotency keys and a durable pre-dispatch record prevent tool retries or model loops from duplicating external actions.
- Make unknown outcomes non-retryable by default
- Include safe command references for later status checks
06
Qualification
Red-team the agent and connector boundaries together
Release proof would cover provider authorization, exact capability manifests, prompt injection in profile or message text, excessive data requests, tenant and account substitution, approval forgery, duplicate tool calls, stale context, revoked sessions, restriction, kill switches, audit, retention, and deletion. An MCP schema or successful sandbox call is not LinkedIn conformance. Both layers must remain disabled until their separate gates pass.
- Treat provider content as untrusted input
- Prove account stop and policy denial override every agent request