Secure MCP for Enterprise Data: Where MCP Ends and CDC Begins

Where does the MCP protocol boundary sit?

The Model Context Protocol, or MCP, provides a common interface between an AI application and external capabilities. In MCP's client-server architecture, a host uses clients to communicate with servers. Servers expose resources, prompts, and tools. That common shape can reduce the amount of custom integration code needed when different AI applications need access to the same capability.

The 2026-07-28 specification makes the core protocol stateless. That simplifies horizontal scaling, but it does not remove application-level authorization, approval, context freshness, downstream transaction, or recovery state.

MCP does not decide whether data is accurate, recent, complete, or appropriate for a given user. It does not copy a database, preserve transaction order across systems, reconcile a target, define a business data model, or replace an identity provider. The protocol includes authorization requirements and security guidance, but a conforming message exchange is not proof of a secure implementation.

This boundary matters because the MCP interface sits close to a model that can propose actions. A tool may read sensitive data, create a payment, alter a case, or call another service. Security therefore depends on the systems around the protocol: identity, policy enforcement, data serving, action approval, network controls, evidence, and incident response.

MCP, A2A, APIs, CDC, and event streaming: which layer owns what?

These technologies can appear in one architecture without being interchangeable. Each owns a different contract.

A representative path illustrates the division. CDC captures selected committed source changes and delivers them to a governed processing layer. That layer updates a context service. An MCP server exposes a narrowly scoped read tool against the service. The agent may then propose an action through a separate tool whose policy and approval requirements are stricter. MCP standardizes the interaction at the edge; it does not replace the data path underneath it.

When should an agent pull live state versus consume pre-assembled context?

Use a controlled live pull when the request is infrequent, narrow, and must reflect the current system of record. The serving service should restrict query shapes, objects, fields, row scope, concurrency, and cost. Giving a model broad database credentials or arbitrary SQL access makes the security boundary larger than the business need.

Use pre-assembled context when many agents or requests need the same multi-source view, when production systems need protection, or when policy and semantic processing must happen before consumption. The context should state its source, age, version, and expiry. A cache without a freshness contract simply moves the uncertainty.

A hybrid pattern is often stronger. A change event identifies the affected entity and wakes the workflow. The agent retrieves only the authoritative fields required for the decision. Entity ID, source version, event ID, and as-of time connect the trigger to the read.

How should agent identity and delegated authorization work?

A secure design distinguishes at least four identities: the end user, the agent or workload, the MCP client, and each downstream service. A fifth identity may be the human approver. Collapsing them into one shared service account makes it difficult to answer who requested access, which authority was delegated, and who accepted the outcome.

When an agent acts on behalf of a user, it needs a bounded delegation, not the user's reusable token. The delegation should specify audience, scope, purpose, time, and resource. The MCP 2026-07-28 HTTP authorization specification uses protected-resource metadata and OAuth-based flows. It requires clients to identify the intended resource, requires servers to validate that tokens are intended for them, and forbids passing the received token through to an upstream service.

That last rule prevents a dangerous shortcut. An MCP server calling a downstream API should use a separate credential appropriate to that API, not forward the token presented by the client. Otherwise, a token issued for one resource can escape its trust boundary and create a confused-deputy path.

Interactive user access and unattended workload access also differ. The first may include browser consent and step-up authorization. The second needs workload identity, short-lived credentials, explicit policy, and revocation without a user being present. Task boundaries should prevent one workflow from reusing another workflow's authority.

How do least privilege, allowlists, and approval gates fit together?

OAuth scope is only one layer of least privilege. A production policy should also restrict the server, tool, operation, data object, row or tenant, field, environment, destination, network route, and time window. Read and write permissions should be separate. The default should be deny, with explicit allowlists for servers, tools, and egress destinations.

Classify tool calls by consequence. A read-only lookup may run automatically. A reversible internal update may operate within rate, amount, and entity thresholds. External communication, financial activity, privilege changes, data export, or irreversible action should require stronger authorization and often human approval.

Tool descriptions and annotations help discovery, but they are not a trusted control by themselves. A malicious or compromised server can describe a dangerous tool as harmless. The host, gateway, and execution service must enforce policy outside the model and validate actual parameters.

• Keep secrets out of prompts, tool descriptions, URLs, and model-visible error messages.
• Use short-lived credentials and bind them to the intended audience.
• Require preview or dry-run output before selected side effects.
• Set transaction, rate, spend, and time limits.
• Provide a kill switch and a path to degrade to read-only.

How do freshness, provenance, and decision lineage travel with context?

MCP can carry context, but it cannot make provenance trustworthy if the underlying data path did not record it. A context envelope should identify the source system and entity, source commit time, capture time, schema version, transformation version, policy classification, and expiry. The agent can then distinguish a current authoritative value from a derived view that is ten minutes old.

The invocation record should add the requestor, delegated user, workload identity, server and tool version, input classification, policy decision, approval, and result reference. This creates three related but distinct chains: data lineage explains where the data came from; a tool trace explains what was called; decision lineage explains how context and authority led to an outcome.

Evidence collection also creates risk. Prompts, tool arguments, and outputs may contain personal data, credentials, or commercial information. Log references and hashes where possible, redact sensitive fields, define retention by purpose, and restrict who can search the evidence store.

How should teams defend against prompt injection and uncontrolled tool calls?

Any document, webpage, database field, email, or tool output can contain text that looks like an instruction. Treat it as untrusted data. The model may summarize or reason over it, but it should not be able to promote that content into a higher-priority policy.

Enforce schema validation, authorization, business rules, and output checks outside the model. For consequential tools, use preview, confirmation, bounded execution, post-condition verification, and rollback. A valid tool call is not the same as a valid business action.

Several threats deserve explicit tests:

• Indirect prompt injection: retrieved content tries to redirect the agent or reveal data.
• Tool poisoning: a server or tool description misrepresents behavior.
• Confused deputy: a service uses its authority for a request the caller was not entitled to make.
• Credential leakage: tokens appear in context, logs, or error output.
• Exfiltration: a tool sends data to an unapproved destination.
• Runaway execution: repeated calls consume money, capacity, or external quotas.

Use network egress rules, sandboxes, rate and budget limits, timeouts, loop limits, and anomaly detection to contain blast radius. Incident response should be able to revoke the identity, disable the tool, preserve evidence, and reconcile actions already taken.

What does a secure enterprise reference flow look like?

Read path

1. A user or workload receives an authenticated identity.
2. The host selects an MCP server and requests a narrowly scoped resource or tool.
3. The server validates the token, audience, issuer, expiry, and required scope.
4. A policy service checks data classification, tenant, purpose, region, and field permissions.
5. A governed context service returns data with freshness and provenance.
6. The response is logged by reference with the policy decision and identity chain.

Action path

1. The agent proposes an action rather than executing it through the read tool.
2. A policy engine classifies consequence, checks limits, and determines whether approval is required.
3. The user or approver sees a human-readable preview of the target, parameters, and expected effect.
4. An execution service uses its own downstream credential and performs the action.
5. The service verifies the post-condition and records the outcome.
6. A failure moves to rollback, compensation, or a human queue.

Fail closed when identity or policy cannot be evaluated. If the data path is delayed, degrade to read-only or a human queue. Logging alone is not enough: evidence must link an authenticated subject, the policy version, the actual parameters, and the observed outcome.

What threat model should an enterprise MCP deployment use?

Threat modeling should begin with assets and trust boundaries rather than a list of protocol features. Valuable assets include data, credentials, tool authority, model context, approval state, and audit evidence. Trust boundaries appear between the host and client, client and server, server and downstream service, agent and policy engine, and human approver and execution service. For each boundary, ask who can impersonate a caller, alter a request, replay an action, change a tool description, redirect a token, or cause sensitive output to leave the approved path.

Model at least four attacker positions. A malicious user may try to exceed delegated authority. A compromised MCP server may misdescribe a tool or return hostile content. A compromised client or host may steal credentials or call a valid tool outside the intended workflow. Untrusted data may contain instructions designed to manipulate the model. Controls should address each position independently; trusting one component should not grant it authority over every downstream system.

Abuse cases should be executable tests. Try a token issued for the wrong resource, a changed issuer, an expired delegation, a tool renamed after approval, an output containing an exfiltration instruction, an oversized argument, a repeated write, and a destination outside the allowlist. Record which layer blocks the request and what evidence remains.

How should identity, application sessions, and task state be implemented?

Identity should be established before tool discovery or access to protected resources. Keep human identity, workload identity, client identity, server identity, and downstream service identity separate in policy and logs. Delegation should narrow authority by audience, purpose, resources, scopes, time, and action class. A sub-agent should receive only the authority required for its task; it should not automatically inherit a reusable copy of the parent workflow's credential.

Do not treat conversation state as authorization state. A remembered approval from an earlier message may be stale, apply to a different entity, or have expired. Store authorization and approval in a controlled system with an identifier the workflow can reference. Bind it to the task, requested action, parameters, policy version, and expiry. If any of those change, require a new decision.

When an application session or workflow ends, revoke or expire usable authority, clear sensitive cached context, and close application-managed downstream handles. Long-running tasks need explicit ownership, cancellation, status, and recovery semantics. If execution resumes after a failure, verify the current identity and policy instead of assuming the old application session remains valid.

What makes audit evidence operationally useful?

An audit event should answer who requested what, under whose delegated authority, against which resource, using which tool and policy version, with which parameters, approval, and outcome. Use correlation identifiers across the MCP call, policy decision, downstream action, and resulting state change. Record timestamps from each layer so investigators can distinguish a delayed response from a late action.

Protect the audit path from the workload it observes. Restrict who can read or alter evidence, redact secrets and unnecessary personal data, monitor gaps in event delivery, and define retention by purpose. High-risk actions may require stronger integrity controls and independent storage. Test whether an investigator can reconstruct a denied request, a partially completed action, a rollback, and a credential revocation without relying on model-generated summaries.

Where does Deltaplex fit—and where does it not?

Fit

Deltaplex is relevant to the governed data path beneath an agent interface: moving selected operational changes toward context services or other consumers. Any deployment should validate the exact source, destination, data boundary, and recovery behavior required by the use case.

Non-fit

A data integration layer does not replace the MCP host or server, identity provider, OAuth authorization server, agent runtime, policy decision point, approval workflow, or action gateway. Unless a specific MCP integration has been verified for the intended deployment, the architecture should show Deltaplex and MCP as separate layers.

Next step

Review one agent workflow end to end. Identify every identity, token audience, data source, context transformation, tool, egress destination, approval gate, and evidence record. Test a stolen token, malicious retrieved instruction, unavailable policy service, duplicate action, and stale context before allowing production writes.