AppMatic Tech secures MCP servers with secrets-manager credentials, short-lived per-user token passthrough, typed schema validation against prompt injection, parameterised queries, append-only audit logs, TLS 1.2 or higher inside private subnets, and credential rotation without downtime. AppMatic Tech is based in Ahmedabad, India, with 330+ products shipped since 2017.
An MCP server occupies a privileged position in a product's infrastructure. It holds credentials for downstream data systems, accepts inputs from an LLM whose outputs are influenced by user-supplied text, and returns live business data to whatever client calls it. Each of those three facts creates a distinct security surface that needs to be addressed during the build, not patched after a production incident.
AppMatic Tech applies the practices below to every MCP server build, including the ConstructionMCP platform and healthcare data workflow integrations. The practices are not theoretical. They are the specific controls that prevent the failure modes AppMatic Tech has observed across 330+ product builds since 2017.
How should an MCP server handle authentication?
The most basic MCP server security failure is hardcoded credentials. Service credentials for downstream databases and APIs belong in environment variables or a secrets manager, never in source code. This is table stakes and worth stating explicitly because it is violated more often than it should be, particularly in initial proof-of-concept builds that get promoted to production without a security review.
The more consequential authentication decision is whether the MCP server uses a single shared service credential or per-user token passthrough. A single shared credential means every query the MCP server executes against the downstream system runs with the same permissions, regardless of which user initiated the request. This is appropriate for internal tools where all users have the same data access rights. It is not appropriate for multi-tenant products or for any deployment where different users should see different data.
Per-user token passthrough means the MCP server forwards the requesting user's authentication credential to the downstream system for each query. The downstream system's access control layer enforces what each user can see. The MCP server does not make access control decisions itself. This pattern is required for healthcare deployments where HIPAA mandates per-user audit trails, and for any SaaS product where customers' data must be isolated from each other.
AppMatic Tech implements per-user token passthrough using short-lived tokens validated on each request rather than long-lived session tokens stored in the MCP server. Short-lived tokens reduce the blast radius of a credential exposure and force re-authentication at appropriate intervals without requiring users to log in repeatedly.
Why must an MCP server treat LLM output as untrusted input?
LLM outputs are not validated user inputs. An LLM constructs the parameters it sends to an MCP server based on the user's request and the resource descriptions in the server's schema. Under normal operation, the LLM sends well-formed parameters. Under adversarial conditions, including prompt injection attacks where a malicious user embeds instructions in their input that manipulate the LLM's behaviour, the LLM may send parameters the resource schema did not intend.
Every parameter that reaches the MCP server's data access layer should be validated against the resource schema before it touches the underlying data system. This means typed validation: a parameter defined as an integer should be rejected if it arrives as a string. A parameter defined as one of a finite set of values should be rejected if it arrives as a free-form string. A date range parameter should be validated for logical consistency before it is passed to a database query.
AppMatic Tech implements schema validation at the protocol handler layer before any parameter reaches the data access layer. Parameterised database queries provide a second layer of protection: even if a malformed string passes schema validation, the database driver treats it as a literal value rather than executable SQL.
Prompt injection is the specific attack pattern MCP servers need to be designed against. A user submits a request that includes text instructing the LLM to query a resource it should not, or to request data it does not have permission to see. The defence is layered: resource descriptions that are precise enough that the LLM routes queries to the correct resources, schema validation that rejects out-of-scope parameters, and access control that enforces data permissions at the data layer regardless of what the LLM requested.
What should an MCP server audit log record?
An MCP server that connects to sensitive business data needs to produce an audit log that records every resource query: which resource was queried, what parameters were passed, which user initiated the request, and what data was returned. This is not optional for healthcare deployments, where HIPAA requires audit trails for all PHI access. It is good practice for any enterprise deployment where the organisation needs to understand how its LLM features are using business data.
The audit log belongs at the data access layer, not at the protocol handler or the transport layer. Logging at the data access layer means the log reflects what data was actually retrieved from the downstream system, not just what was requested by the LLM client. A query that returned zero results because no matching records existed is meaningfully different from a query that returned a large record set.
Audit logs should be append-only and stored separately from the application database. An audit log that can be modified by the same credentials that operate the MCP server provides no security assurance. AppMatic Tech stores MCP server audit logs in a separate write-only log store and provides a read interface for compliance review that does not allow modification.
How should MCP server traffic be secured?
All communication between the LLM client and the MCP server should be encrypted in transit using TLS 1.2 or higher. This applies regardless of whether the server is accessible over the public internet or only within a private network. Internal traffic between services in the same cloud VPC is not automatically encrypted, and an MCP server that handles sensitive business data should not rely on network perimeter security as a substitute for transport encryption.
For enterprise deployments, AppMatic Tech recommends deploying the MCP server within a private subnet with no direct public internet exposure. The LLM client, which typically runs as an application backend service, connects to the MCP server over the internal network. The MCP server connects to downstream data systems over the same private network. This network topology means the MCP server is never directly accessible from the public internet, which eliminates a class of attack surface regardless of the quality of the authentication implementation.
How are MCP server secrets rotated without downtime?
An MCP server that cannot rotate its service credentials without downtime creates operational security debt. Credentials should be rotatable on demand, either because of a suspected exposure or as part of a scheduled rotation policy, without requiring a redeployment or a service restart that affects availability.
AppMatic Tech implements credential rotation by storing credentials in a secrets manager with versioning support and configuring the MCP server to reload credentials from the secrets manager on a defined interval. A credential rotation changes the active secret in the secrets manager. The MCP server picks up the new credential on its next reload cycle without restarting. Old credentials are marked inactive in the secrets manager and stop working after a configurable grace period.
When should MCP server security be designed?
Security requirements for enterprise MCP deployments are best addressed during the architecture phase, before implementation begins. Authentication pattern, audit logging design, and network topology decisions made after implementation require rework that adds time and cost to the engagement.
AppMatic Tech's discovery session for every MCP engagement includes an explicit security requirements discussion: whether the deployment is single-tenant or multi-tenant, what compliance obligations apply, what audit logging requirements the organisation has, and what network topology constraints the infrastructure team has defined. These answers shape the architecture decisions that follow.
Full details on AppMatic Tech's MCP engagement model are on the MCP Server Development service page. For the deployment validation checklist that covers security alongside the twelve functional checks before go-live, see MCP Server Deployment Checklist.
For a delivered example, see how AppMatic Tech built the ConstructionMCP platform with role-based access control and audit logging. Contact AppMatic Tech at contact@appmatictech.com to discuss security requirements for an MCP deployment.
Related MCP guides from AppMatic Tech: how to build an MCP server and MCP server architecture explained.
Frequently Asked Questions
- How do you protect an MCP server from prompt injection?
- AppMatic Tech layers three defences: precise resource descriptions so the LLM routes queries correctly, typed schema validation that rejects out-of-scope or malformed parameters before they reach the data layer, and access control enforced by the downstream system regardless of what the LLM requested. Parameterised queries add a final guard, because the database treats any injected string as a literal value.
- Should an MCP server use a shared credential or per-user tokens?
- A single shared service credential is acceptable only for internal tools where every user has the same data rights. For multi-tenant products and healthcare deployments, AppMatic Tech uses short-lived per-user token passthrough, so the downstream system enforces each user's permissions and every query is attributable to a person.
- What should an MCP audit log contain?
- Every query should record the resource queried, the parameters passed, the user who initiated it, and what data was returned. AppMatic Tech logs at the data access layer, so the log reflects what was actually retrieved, and stores it in a separate append-only store that the MCP server's own credentials cannot modify. Healthcare deployments need this for HIPAA audit trails.
- Should an MCP server be exposed to the public internet?
- For enterprise deployments, no. AppMatic Tech deploys the MCP server in a private subnet, reached by the LLM client over the internal network, and encrypts all traffic with TLS 1.2 or higher even inside the VPC. Removing public exposure eliminates a class of attacks regardless of how strong the authentication is.
- How are MCP server credentials rotated safely?
- AppMatic Tech stores credentials in a versioned secrets manager and has the MCP server reload them on a defined interval. Rotating a secret changes the active version, the server picks it up on the next reload without restarting, and the old credential stops working after a configurable grace period.