MCP Server Security: A Practical Playbook

OAuth and secret rotation are necessary for MCP server security, but they're not the point where most production failures occur. A stolen token is serious. A tool that accepts an attacker-controlled SQL fragment, follows a rebinding URL, exposes unrestricted shell access, or passes poisoned output into the next agent step can turn a correctly authenticated request into a damaging one.

That distinction matters for Amazon seller workflows. 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

• Why MCP Server Security Is 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

Why MCP Server Security Is 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 June 2025 analysis referenced by Red Hat reported widespread weaknesses in publicly exposed MCP servers, while a July 2025 internet scan reportedly identified 1,862 publicly accessible instances responding to unauthenticated requests, as documented in Red Hat's analysis of the MCP security situation. The important lesson is that operators must govern exposure, authorization, tool scope, and default behavior as one system.

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 specification and OWASP guidance support a least-privilege, deny-by-default model. The server should authorize every inbound request independently, assign access per server and tool, and avoid treating session continuity as proof of identity. A session may carry state, but the server must verify the request before execution.

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 often break deployments. Security reporting cited in the supplied guidance described 43% of tested MCP implementations with command-injection flaws, alongside ecosystem reporting about high- and critical-severity issues involving remote code execution, path traversal, and token leakage. The statistic signals implementation risk. It does not mean every MCP server has the same defect.

Review tools as executable interfaces rather than friendly descriptions. Inspect schemas, parameter constraints, downstream URL handling, output processing, and container permissions with the same care applied to an API gateway. Teams assessing hosted infrastructure can consult agentcentral's MCP server hosting overview to compare a connection endpoint with a managed data layer that provides scoped access and operational controls.

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: Inspect and log tool output before passing it to another component or into model context. Returned text can contain hidden instructions or pivot attempts.

The IETF guidance referenced in the supplied material specifically calls for connection-time URL validation against DNS rebinding and blocking RFC 1918, loopback, and link-local ranges. This is especially relevant to website fetchers, catalog enrichment tools, and any server that processes externally controlled content.

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.

Security teams assessing the surrounding cloud environment can also consult improve cloud pentesting with ThreatExploit AI, particularly when the MCP server runs alongside IAM roles, storage, queues, and other cloud resources. The review should test lateral movement, not just whether an unauthenticated request reaches the MCP endpoint.

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, use OAuth 2.1 with PKCE. PKCE reduces the value of an intercepted authorization code because the client must prove possession of the verifier created during authorization. After authentication, issue tokens with a narrow audience and 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.

Teams designing roles can use this RBAC guide for dev teams to formalize role assignment, but 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.

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 integrity controls. Validate descriptions against a known-good baseline, hash or sign them at deployment, and check the hash on every tools/list response before metadata enters model context. A changed description can alter how an agent interprets a tool even when the underlying 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, retention rules, and an audit trail showing which client accessed which dataset.

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 the source fields used to calculate the proposal. 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, when present, specifies the account-application pair's rate limit. Amazon documents token-bucket behavior, with throttling when requests exceed the available limit, as described in its SP-API usage plans and rate limits documentation. Amazon Notifications operations such as subscription and destination management are constrained to 1 request per second with a burst of 5, according to the Notifications API rate-limit documentation. Repeated polling should therefore be replaced with event-driven handling or cached state 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 reporting retention makes monitoring and data stewardship inseparable. Generated SP-API reports are retained for 90 days unless a report type specifies otherwise, while Amazon Ads unified reporting documents a 120-day maximum pull for the UI's Date preset and a 15-month historical range for certain UI views. Amazon also documents a 90-day campaign and ad-group history window in the ad console, as summarized in the SP-API report type documentation. A pre-materialized seller data layer should define its own retention and backfill policy rather than assuming Amazon will provide unlimited historical recovery.

For general log design, this guide to cloud security audit logging provides useful context on integrity, access control, and operational review. MCP-specific logs should add tool semantics and model-facing context to those cloud fundamentals. The agentcentral data security practices page is another relevant reference when evaluating tenant isolation, credential handling, and auditability in a hosted data layer.

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. Hosted MCP deployments should be audited as living systems, not certified once and forgotten.

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 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.