MCP Server Security: A Practical Playbook

Securing an MCP server for Amazon seller workflows requires per-request authentication, narrow authorization, strict tool schemas, tenant isolation, output boundaries, guarded writes, and incident controls. OAuth and API keys establish identity; safe implementations also validate token audience and every parameter, restrict downstream access, preview sensitive changes, and record committed write outcomes without copying secrets or customer data into logs.

A hosted MCP server may expose advertising data, orders, inventory, catalog records, finance data, fulfillment information, and guarded write operations to Claude, ChatGPT, OpenClaw, Cursor, or another client. The security boundary therefore includes the client, connection, identity, tool definition, parameters, downstream Amazon APIs, returned data, and every action taken after a response enters model context.

Table of Contents

• What Makes MCP Server Security a Trust-Boundary Problem?
  • The boundary continues after connection
  • Protocol controls don't repair unsafe implementations
• Threat Model for Amazon Seller MCP Servers
  • Map the request path
  • Rank tools by blast radius
• Authentication and Authorization Controls
  • Configure identity in layers
  • Compare authentication methods
  • Handle revocation as an operational control
• Dataset Isolation and Write-Safety Controls
  • Isolate credentials and execution
  • Treat writes as transactions
• Logging, Monitoring, and Incident Response
  • Monitor behavior, not only errors
  • Make the response procedural
• Deployment Verification and Security Checklist
  • Verify the controls

What Makes MCP Server Security a Trust-Boundary Problem?

A valid OAuth token can still authorize a dangerous operation. Authenticating the client, validating the token, and rotating credentials protect entry to the server, but they do not make every tool safe. MCP server security is a trust-boundary problem because each tool call moves from model-controlled context into systems containing customer, commercial, and operational data.

Public exposure shows how quickly that boundary can fail. A 2025 Knostic scan identified 1,862 internet-exposed MCP endpoints and manually verified 119; all 119 returned tool listings without authentication. That does not prove every endpoint allowed tool execution, but it shows why public deployments must gate calls, scope backend credentials, and avoid exposing sensitive capability metadata.

For Amazon seller workflows, an authenticated request might reach advertising data, orders, inventory, catalog records, finance information, fulfillment systems, or guarded write operations. If the token can invoke a generic database tool, execute commands, retrieve every seller account, or send arbitrary network requests, authentication has identified the caller without limiting the result.

The boundary continues after connection

The MCP authorization specification requires authorization on every HTTP request and token validation for the intended resource. The server should assign the smallest practical scope, authorize each request independently, and avoid treating session continuity as proof of identity. A session may carry state; it does not grant permission.

For an Amazon seller data layer, permissions should separate:

• Read access, including campaign metrics, order status, inventory quantities, and catalog fields.
• Sensitive reads, including finance records, customer-related order data, and fulfillment details.
• Guarded writes, including bid adjustments, listing changes, inventory updates, shipment creation, and Multi-Channel Fulfillment operations.
• Administrative operations, including credential changes, account connections, and tool configuration.

A campaign-performance tool should not inherit permission to change bids. A client connected to one seller account should not select another tenant by changing an account identifier. A tool response containing external text remains untrusted, even when the tool itself was authorized.

Practical rule: Authentication answers “who is calling?” Authorization and validation answer “what may this exact request do, to which data, using which tool, under what conditions?”

Protocol controls don't repair unsafe implementations

Implementation-layer failures still break authenticated deployments. Command injection, SSRF, path traversal, token leakage, tool poisoning, and unsafe output chaining arise from code and permissions, not from the MCP handshake alone. Review tools as executable interfaces: inspect schemas, parameter constraints, downstream URL handling, output processing, and runtime permissions with the same care applied to an API gateway. Teams assessing hosted infrastructure can consult agentcentral's MCP server hosting overview for the difference between a connection endpoint and a managed data layer.

A production deployment should treat the request lifecycle as untrusted until each stage proves otherwise. OAuth is one control in that chain. It cannot compensate for command injection, tool hijacking, excessive capabilities, tenant-selection flaws, or unsafe defaults.

Threat Model for Amazon Seller MCP Servers

An Amazon seller MCP server has several asset classes and several actors. The assets include OAuth credentials, scoped API keys, seller datasets, advertising performance, orders, inventory, catalog information, finance records, fulfillment data, audit logs, and write capabilities. Actors may include an authorized seller, an agency user, a compromised client, a malicious prompt, a compromised tool dependency, or an external system whose content is returned by a tool.

Map the request path

The first step is to draw the path from client to downstream service and mark every trust transition:

1. Client connection: Confirm transport security, client identity, and token audience. A public client should use OAuth 2.1 with PKCE rather than relying on a shared secret.
2. Request authorization: Check the caller on every inbound request. Don't let session continuity replace independent verification.
3. Tool selection: Permit only tools assigned to that client, role, tenant, and data domain. A read-only reporting agent shouldn't discover write tools.
4. Parameter handling: Treat every tool-call parameter as untrusted. Validate identifiers, date ranges, sort fields, pagination, URLs, and operation-specific values.
5. Downstream call: Use narrow audience-scoped tokens or token exchange. Apply egress allowlists and block destinations that aren't required by the workflow.
6. Response handling: Validate and classify tool output before passing it to another component or into model context. Returned text can contain hidden instructions; do not copy raw sensitive payloads into logs.

The official MCP security guidance covers DNS rebinding, private and reserved address ranges, redirect validation, and time-of-check/time-of-use risks. These controls matter for website fetchers, catalog enrichment tools, and any server that processes externally controlled URLs.

Rank tools by blast radius

A useful threat model ranks tools by what a compromised call can reach, not by how harmless the tool description sounds.

Generic shell execution and unrestricted SQL are poor defaults because they convert a narrow business integration into a general execution environment. Purpose-built tools, allowlists, strict schemas, isolated containers, and final human confirmation for sensitive actions create a smaller failure domain.

The surrounding cloud review should test lateral movement as well as endpoint authentication. Check the runtime identity, metadata-service access, egress paths, storage permissions, queues, and secret access available to a compromised tool.

Authentication and Authorization Controls

The secure baseline combines strong authentication with granular authorization. A deployment that uses OAuth but grants every client every tool has an identity system, not a least-privilege system.

Configure identity in layers

For public clients, follow the MCP authorization specification with OAuth 2.1 security practices and PKCE. PKCE reduces the value of an intercepted authorization code because the client must prove possession of the verifier created during authorization. After authentication, validate token audience and apply the smallest practical scope.

For downstream calls, use token exchange or a separate audience-scoped token rather than forwarding a broad client token through every service. Protect transport with TLS 1.2+ or mTLS, then enforce network egress allowlists so the server can contact only required Amazon and supporting service endpoints.

A practical authorization model has four dimensions:

• Tenant: Which seller account or agency-managed account is in scope?
• Domain: Ads, inventory, orders, catalog, finance, or fulfillment?
• Tool: Which exact operation is permitted?
• Action: Read, preview, or commit?

A scoped key for advertising reads shouldn't retrieve finance data. A key that can preview a bid change shouldn't automatically commit it. A request claiming a different seller identifier should fail authorization, even if the caller's token is valid.

MCP authorization still needs operation-level checks. A role called “ads manager” is too broad if it grants unrestricted campaign writes without confirmation or audit requirements; map each role to explicit domains, tools, and actions.

Compare authentication methods

The server must validate authorization on every request, not only during session creation. Session identifiers can coordinate protocol state, but they shouldn't establish permission.

Handle revocation as an operational control

Amazon states that only selling partners can revoke OAuth authorizations, and revocation occurs from Seller Central. The Amazon authorization revocation documentation also describes lifecycle actions such as authorize, reauthorize, and reactivate.

That constraint changes incident response. The MCP operator can disable its own tenant mapping, revoke local keys, block tool access, and invalidate cached tokens, but the seller may still need to revoke the Amazon authorization in Seller Central. Runbook ownership must be explicit.

API key handling deserves the same discipline. Keys should identify tenant, environment, role, and tool scope, with rapid disablement and audit trails. A deployment team can use agentcentral's API key management guidance to frame the operational requirements for scoped keys, rotation, and client access without treating a key as a substitute for per-request authorization.

Tool descriptions also need change control. Review description and schema diffs like code, pin trusted server versions where practical, and alert on unexpected tool additions or weakened constraints. A changed description can alter how an agent interprets a tool even when the endpoint and token remain unchanged.

Dataset Isolation and Write-Safety Controls

Authentication limits who enters. Dataset isolation limits what a compromised component can reach after entry. In a multi-seller environment, each tenant's Amazon Ads, Seller Central, inventory, orders, catalog, finance, and fulfillment data should remain separated by authorization policy and storage boundary.

A server should derive tenant context from verified identity, not from a free-form parameter supplied by the model. The request may include a campaign, SKU, order, or shipment identifier, but the service must confirm that the identifier belongs to the authorized seller and permitted domain before querying or writing.

Isolate credentials and execution

Credentials should be encrypted at rest and protected in transit with TLS 1.2+ or mTLS. Store tenant credentials separately from application configuration, restrict decryption to the service that needs them, and avoid placing broad secrets in logs, prompts, tool descriptions, or error messages.

Run tools in isolated containers with minimal filesystem, process, and network permissions. Network egress allowlists prevent a compromised tool from contacting arbitrary destinations. Container isolation reduces the chance that a vulnerable parser, dependency, or command wrapper can pivot into neighboring seller accounts or infrastructure.

Pre-materialized reads can reduce both latency and downstream pressure when the workflow repeatedly analyzes the same seller data. The security requirement remains unchanged: the materialized layer needs tenant boundaries, field-level controls where appropriate, bounded retention, and privacy-aware server telemetry. Customer-facing action history must clearly distinguish committed writes from read-call telemetry; agentcentral's permissioned action history records writes, not every read.

Treat writes as transactions

Write tools should expose a controlled transaction rather than a vague “update” capability.

• Bid adjustments: Show campaign, ad group, targeting context, current value, proposed value, and any caller-supplied reason. The caller owns the basis for the change; require confirmation before commit.
• Listing updates: Validate allowed fields, preserve before values, preview the exact payload, and reject fields outside the tool's purpose.
• Inventory changes: Require SKU and marketplace validation, use idempotency keys, and prevent a replay from applying the same operation twice.
• Shipment or MCF creation: Display destination, items, quantities, and fulfillment parameters before submission. Record the final response and request identity.

Idempotency protects against retries, not bad intent. A preview protects against ambiguity, not a stolen credential. Human confirmation is still appropriate for sensitive actions because the agent may have received a manipulated instruction or misunderstood an external response.

Amazon's API constraints also affect safe design. The Selling Partner API uses per-operation usage plans, and the x-amzn-RateLimit-Limit response header can identify the limit applied to a request when present. Amazon documents token-bucket behavior in its usage-plans reference. Respect returned limits, back off on throttles, and prefer notifications or cached state over unrestricted polling where the workflow permits it.

Logging, Monitoring, and Incident Response

An MCP server needs an audit record that explains not only who connected, but what the agent attempted and what the server did. Log authentication events, authorization decisions, tool names, validated parameters, tenant context, downstream operation identifiers, response classifications, write previews, commits, failures, and confirmation events.

Sensitive payloads shouldn't be copied indiscriminately into logs. Redact tokens, secrets, customer information, and unnecessary response fields while retaining enough structured context to reconstruct the decision. A useful event record links the client identity, tenant, tool, action, authorization result, policy version, request correlation identifier, and outcome.

Monitor behavior, not only errors

A successful response can still indicate an incident. Alert on patterns such as:

• Authorization drift: A client repeatedly requests tools outside its assigned domain.
• Parameter abuse: Inputs contain shell metacharacters, SQL fragments, unexpected URL schemes, or identifiers from another tenant.
• Network anomalies: A fetch tool attempts blocked private, loopback, or link-local destinations.
• Output contamination: Tool responses contain instruction-like content that is passed into another tool without inspection.
• Write deviation: A normally read-only workflow suddenly previews or commits bid changes, bulk inventory changes, or shipment creation.
• Extraction behavior: A client requests unusually broad date ranges, fields, pagination, or repeated exports across seller domains.

Amazon publishes report-specific retention and historical-range limits. A pre-materialized seller data layer should define its own bounded retention and backfill policy rather than assuming Amazon will provide unlimited recovery. MCP-specific security telemetry should preserve tool semantics and authorization outcomes while redacting secrets and customer data. The agentcentral data security practices page is a related reference for tenant isolation, credential handling, and write auditability.

Make the response procedural

When an alert fires, first disable the affected client key and block the suspicious tool or tenant mapping. Then preserve relevant logs, tool-description versions, policy decisions, container events, and downstream request records. If Amazon authorization may be compromised, instruct the selling partner to revoke it from Seller Central, then reauthorize only after credentials, scopes, and tenant mappings have been reviewed.

Recovery should include replay analysis. Determine whether the event was read-only, a preview, or a committed write. For unexpected bid changes, inventory modifications, listing edits, or fulfillment actions, compare logged before and after values, identify the confirmation path, and document any downstream remediation. Re-enabling access without understanding the tool path restores the same weakness.

Deployment Verification and Security Checklist

Security verification should be repeatable, evidence-based, and performed against the deployed endpoint, not only source code. A staging seller account or controlled tenant should exercise every tool through the same client path used in production.

Verify the controls

1. Authentication: Confirm that unauthenticated requests fail, PKCE is enforced for public clients, token audience and expiry are checked, and session identifiers cannot authorize requests.
2. Authorization: Attempt cross-tenant identifiers, unassigned tools, finance reads from an ads-only key, and write commits from a read-only client. Each must fail before downstream execution.
3. Input validation: Test malformed identifiers, unexpected fields, shell metacharacters, SQL syntax, unsafe URLs, oversized ranges, and replayed idempotency keys.
4. Tool integrity: Compare every tools/list response with the approved description baseline. Reject unexpected additions, removed constraints, or changed parameter semantics.
5. Isolation: Confirm that containers lack unnecessary host access, egress is allowlisted, credentials are encrypted, and a compromised tool cannot reach another tenant's dataset.
6. Write safety: Require previews and final confirmation for sensitive actions. Record before values, after values, actor identity, policy version, and idempotency status.
7. Observability: Generate alerts for authorization failures, blocked destinations, abnormal tool sequences, extraction patterns, and unexpected writes.
8. Amazon constraints: Exercise retry and backoff behavior against documented SP-API usage plans and Notifications limits. Avoid polling designs that depend on unrestricted request volume.
9. Revocation: Disable a local key, invalidate cached access, and complete the Seller Central OAuth revocation procedure. Confirm that every path stops accepting the revoked authorization.

The final gate should include a written owner for each control, a timestamped test result, and a recheck trigger for tool changes, dependency updates, policy changes, or new Amazon data domains. The API-key scoping guide provides an internal reference for least-access client setup. Hosted MCP deployments need recurring verification rather than one permanent certification.

agentcentral provides a hosted MCP data layer for Amazon Ads, Seller Central, inventory, orders, catalog, ranking, finance, and fulfillment workflows, with scoped API keys, isolated datasets, encrypted credentials, guarded write previews, idempotency controls, and write audit logs. Sellers, agencies, and developers evaluating safer agent access can visit agentcentral to connect an Amazon account through OAuth and give their MCP client a controlled, auditable data interface.