SDK-based deployment embeds identity and network controls directly into the MCP client and server code, which fits greenfield systems. Agent-based deployment places tunnelers or gateways beside existing OT or edge systems, so legacy applications do not need code changes. Both approaches aim for outbound-only, policy-authorized communication without exposing inbound network paths.
How SDK-based deployment changes the MCP control plane
SDK-based deployment is the code-integrated option. The client and server carry the trust logic inside the application path, so identity checks, request policy, and outbound-only communication are built into the MCP implementation rather than bolted on around it. That makes it a cleaner fit for greenfield systems where teams can design the client, server, and access flow together.
Because the control logic lives in code, SDK-based patterns tend to be more precise about what each request may do. That matters in a zero trust design, where the system should verify the principal, constrain the request, and avoid exposing a general inbound network surface. A useful reference point is NIST SP 800-207 Zero Trust Architecture, which formalises never-trust, always-verify thinking for this kind of design.
In MCP terms, the SDK approach also aligns well with a standards-first authorization model. The MCP authorization specification describes the server as a resource server with audience-bound tokens and no token passthrough, which is the same basic discipline SDK-based deployments try to enforce inside the application boundary.
How agent-based deployment changes the edge around legacy OT systems
Agent-based deployment is the retrofit option. Instead of changing the MCP client or server code, teams place a tunnel, gateway, or sidecar next to existing OT, edge, or industrial applications and let that component mediate policy-authorized traffic. The practical advantage is compatibility: legacy systems can participate in a zero trust flow without a rewrite.
This approach is usually the better fit when manufacturing environments already contain fixed-function controllers, older edge software, or vendor-managed applications that cannot be modified easily. The agent becomes the control point for outbound-only access, request authorization, and path restriction, so the underlying system can stay unchanged while still avoiding direct inbound exposure. That is why zero trust guidance for industrial environments remains relevant, especially when a deployment must respect segmentation and operational constraints. See NIST SP 800-82 Rev 3, OT Security Guide.
For the network model itself, the architecture still needs to behave like zero trust rather than a simple proxy. The tunnel or gateway should enforce the policy boundary, not merely forward traffic, which is why NIST SP 800-207 remains the right architectural comparison even when the implementation is external to the application.
What should drive the choice in manufacturing?
The main trade-off is where the trust logic lives. SDK-based deployment gives tighter integration, finer-grained policy, and better long-term consistency, but it requires application ownership and code changes. Agent-based deployment gives faster adoption and lower retrofit friction, but it introduces an extra enforcement component that must be managed, monitored, and kept in sync with plant and edge realities.
Manufacturing teams should also separate architectural preference from operational feasibility. If the system is greenfield, SDK-based design usually delivers the cleaner zero trust posture. If the system is brownfield, vendor-locked, or safety-sensitive, agent-based deployment is often the only realistic path to policy-enforced outbound-only access without creating new inbound dependencies.
In both cases, the real test is whether the deployment removes standing network trust and narrows each action to an authorized, observable transaction. The question is not which pattern is more modern, but which one can be enforced reliably in that specific manufacturing environment.
Risk and Threat Considerations
The main security risk is assuming that a gateway alone makes an environment zero trust. If the agent merely relays traffic, or if the SDK exposes broad internal privileges, the organisation keeps the same trust problem with a different shape. In manufacturing, that can leave OT and edge assets reachable through weakly governed control points.
Failure mechanism: A poorly designed agent becomes a high-value choke point, while a weak SDK implementation can turn every embedded client into a reusable trust bypass. Both failure modes undermine the outbound-only model and can widen blast radius if credentials, tokens, or policy decisions are shared too broadly.
Impact: Attackers or abusive integrations can use the deployment path to reach systems that should have remained isolated, especially where legacy equipment, shared service paths, or inconsistent policy enforcement create hidden exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP deployments authenticate services and policy-bearing components. |
| AC-6 — Least Privilege | Zero trust MCP should limit what each client, gateway, or agent can do. | |
| SC-7 — Boundary Protection | SDK and agent patterns both manage trust boundaries around MCP traffic. | |
| Recommendation — Use IA-9 to authenticate MCP services and intermediaries before allowing tool access. Apply AC-6 to constrain each MCP path to the minimum authorized actions. Use SC-7 to control and segment MCP traffic at the deployment boundary. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets Are Authenticated Before They Can Connect | Zero trust MCP requires authenticated components before connection or action. |
| PR.PS-01 — Configuration Management | Deployment choice depends on controlled, consistent enforcement in production. | |
| Recommendation — Authenticate MCP components before permitting network or tool interaction. Manage MCP deployment settings so policy behavior stays consistent across environments. | ||
Practitioner Guidance
What to prioritise: Choose SDK-based deployment when you control the application lifecycle and can enforce policy in code; choose agent-based deployment when legacy OT or edge systems cannot be modified safely. The deciding factor is not elegance, it is whether the control can be enforced without disrupting operations.
What to verify: Confirm that the chosen pattern actually enforces outbound-only communication, per-request authorization, and no standing inbound path. If the design still depends on long-lived shared credentials or unmanaged exception rules, it is not a real zero trust deployment.
Common mistake: Treating the gateway as the security solution. In practice, the gateway or tunnel must be paired with identity, policy, and observability, otherwise it becomes just another network relay with a security label.
Practitioner takeaway: Use SDK-based deployment when you can embed control into the product, and agent-based deployment when you must wrap what already exists, but judge both by the same standard: does the design reduce implicit trust and make every MCP action policy-bound and observable?
Related resources from NHI Mgmt Group
- What is the difference between zero trust for users and zero trust for NHIs?
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between a public MCP server approach and an outbound only zero trust tunnel for agent access?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
