MCP Security and Access

The embedding application owns all authority. The SDK adapter defines the maximum access available to agents, each mounted surface may narrow it, and the session attachment may narrow it again. Standard MCP pairing or a page-bound WebMCP registration routes a client to one browser session; routing alone does not grant a chart or broker operation.

Review the exact session, targets, and read, write, and trade grants before the client acts.

Trust boundary

Stays in your application	May cross MCP
Datafeed and broker credentials, risk authority, DOM nodes, callbacks, provider registration, storage adapters, and widget lifecycle	Bounded controller context, effective controls, validated call arguments and results, projected events, revisions, and size-limited snapshots

Access classes

Class	Permits	Does not permit
read	Read authorized state, capabilities, revisions, market/account data, and allowed event streams	Chart changes or broker actions
write	Change non-financial chart, drawing, indicator, replay, layout, customization, or ticket-draft state	Placing, modifying, cancelling, or closing financial exposure
trade	Call explicitly allowed broker-facing operations	Any action absent from broker support, host risk policy, or the session grant

Families group related operations. Exact control decisions can narrow a family. Unknown controls and wildcard or prefix guesses do not receive authority.

Configure the host maximum

const adapter = createTradeScriptAdapter({
  marketData: { feed },
  trading: { broker },
  risk: riskController,
  riskRequests,
  agenticAccess: {
    read: true,
    write: {
      families: {
        chartNavigation: true,
        drawings: true,
        indicators: true,
      },
      controls: {
        'chart.copyImageToClipboard': false,
      },
    },
    trade: false,
  },
});

The attachment passed to attachTradeScriptSession selects an equal or smaller subset. Changing a session policy requires a new attachment; the MCP client cannot widen its own policy. For WebMCP, publish the replacement with replaceExisting: true before detaching the prior owner so the stable names are handed off atomically rather than finally revoked.

Paper trading requires independent authority

A chart-write grant never implies trading authority. Every financial action requires all of these to agree:

1. The exact trading controller and operation are mounted and supported.
2. The mounted adapter declares a paper execution environment.
3. The adapter maximum explicitly allows the matching trade family or control.
4. The host risk authority accepts the request.
5. The session attachment still permits the operation.
6. The call carries current revisions and a caller-owned operation ID.

TradeScript's shipped examples and certification cover paper execution only. A paper grant cannot be upgraded by the MCP client, and an unknown or mismatched execution environment fails closed. Live execution is outside this delivery. If your process requires human confirmation, obtain and record it before the call; the MCP server does not add a per-call approval dialog to your product.

Pairing credential handling

• Read local bridge credentials from standard error; standard output is MCP protocol traffic.
• Keep pairing tokens out of prompts, URLs, screenshots, analytics, source control, and support bundles.
• Bind the local bridge to loopback and configure an exact browser-origin allowlist when possible.
• Detach the session and stop the local process when access should end.
• Treat a local reconnect token as valid for the lifetime of that process.

For a customer-hosted deployment, use HTTPS/WSS and require customer identity, tenant isolation, exact origin checks, session expiry, rate limits, revocation, and durable audit storage. Do not expose the local loopback bridge on a public interface.

rateLimitRequest runs before authentication on protected session and MCP requests and on each browser-bridge connection. Back it with shared customer-owned state, or enforce an equivalent policy at the customer edge; never rely on a per-process counter in a multi-replica deployment.

Rotate browser tokens through the authenticated customer session endpoint. The session store must compare and replace token hashes atomically; never persist a raw pairing code or browser token. Rotation retains the bound tenant, principal, session, origin, grants, and expiry and immediately invalidates the old browser token.

Consume pairing-code hashes atomically exactly once. Retain only enough hashed tombstone state to distinguish replay until session expiry; never accept a same-consumer retry as idempotent. Apply MCP authorization using the bound session and sanitized tool name supplied by the gateway, not model-supplied tenant or session claims.

WebMCP lifecycle

Publish WebMCP tools only from the top-level page that owns the attachment. The WebMCP schemas omit sessionId; the attachment injects its own opaque identity so model input cannot select another browser session. Only one active TradeScript exposure may claim the six stable tool names in a document.

Keep the same least-privilege attachment policy you would use for standard MCP, publish only after an explicit page action, and require a secure top-level context. Tools that can mutate state are marked non-read-only, and every result is marked as untrusted content for the browser client. Use atomic replacement for policy rotation. Detach the final attachment on sign-out, surface destruction, or revocation; final detach aborts every page tool registration and requires a page reload before the stable names can be published again. WebMCP requires no pairing credential and must not be given one.

Revision and retry safety

Mutations carry the revision domains declared by the selected control. If the target changes after context was read, the call fails with a revision conflict; the client must reread state and reconsider the action.

Financial calls require an operation ID. Reusing the same ID with the same target, control, arguments, revisions, and origin is an idempotent retry. Reusing it for a changed intent is rejected. Generate a new operation ID when the requested financial action changes.

Audit evidence

Persist the evidence required by your governance policy:

• customer/user identity and paired session identity
• target, control, arguments, access class, and host policy decision
• request and operation IDs
• before and after revisions
• broker environment and risk decision for financial calls
• structured result, relevant events, duration, and errors
• before/after images when the rendered result matters

The MCP response supplies immediate operation evidence. It becomes a durable audit trail only when your application stores it in an audited system.

Data bounds

Requests, results, snapshots, batches, subscriptions, event buffers, strings, and JSON depth are bounded. Filter and page market data, account history, object trees, depth, tape, and events. MCP is a semantic control plane; it is not a lossless high-rate market-data transport.

Product and responsibility boundaries

TradeScript supplies libraries that validate and route typed operations. The customer supplies and operates the model provider, chat backend, MCP deployment, identity, authorization, session database, logs, retention, paper broker, and trading policy. TradeScript receives none of those credentials or records by default and provides no hosted runtime fallback.

These operations remain in the embedding application:

• provider and callback registration
• DOM access and browser event ownership
• injecting datafeed, broker, storage, or risk adapters
• mounting and destroying product surfaces
• running arbitrary source code supplied by an agent

Agents can configure built-in indicators and operate indicator instances the host registered. The MCP server does not accept or execute runtime TypeScript indicator source.

Security review checklist

• The adapter maximum starts with least privilege.
• Each session grant identifies the exact read, write, and trade scope.
• Shipped paper execution cannot be silently upgraded to live authority.
• Risk checks and required approvals happen before broker execution.
• Pairing credentials never enter prompts, URLs, or logs.
• WebMCP binds the attachment-owned session and removes its tools on detach.
• Remote deployments provide identity, tenant isolation, expiry, revocation, TLS, rate limits, and durable audit storage.
• Stale revisions and conflicting operation-ID reuse fail closed.
• The application retains the evidence its governance policy requires.

Next steps

• Controls and Resources — the call mechanics these access classes gate.
• Evaluate Agent Control — a bounded validation run against a live session.
• MCP Control Reference — the access class and risk classification of every control.