Security Features

This server implements multiple layers of security to protect your trading operations and credentials.

1. TLS/SSL Encryption

Both TRADE and QUOTE FIX sessions are encrypted via TLS over TCP.

TLS is enabled by default
Encrypts all FIX messages including Logon credentials on both sessions
Prevents credential interception and message tampering
Only disable for local testing with broker’s explicit approval

2. Credential Redaction

Sensitive fields (username, password, and related credentials) are automatically replaced with *REDACTED* in all logs and journal entries.

Your credentials are never exposed in logs, journal entries, or error messages.

3. Input Sanitization

All values are sanitized before being sent to the broker:

Control characters and protocol delimiters are stripped from string inputs
This prevents malformed data from corrupting messages or injecting additional fields
Numeric values are validated for finiteness and bounds
Symbol names are validated against a strict alphanumeric pattern

4. Trade Serialization

All trading operations are serialized to prevent race conditions:

Only one trading operation executes at a time
Each operation goes through risk checks before execution
This prevents concurrent tool calls from exceeding position limits or bypassing daily loss limits

Every trading tool (place_order, modify_order, close_position, cancel_order) acquires the lock before executing.

5. Audit Trail

Every action is logged to an append-only journal:

Server start/stop events
FIX connection/disconnection
Every tool invocation with parameters
Every order submission, fill, rejection
Risk check failures
Kill switch activations
State reconciliation events

The append-only format prevents retroactive tampering.

6. AI Agent Safety (MCP Instructions & Tool Annotations)

The server uses MCP protocol features to guide AI agent behavior:

Server Instructions

The instructions field is sent to the AI agent during MCP initialization handshake. MCP clients typically inject this into the model’s system prompt. Contents:

Mandatory calculation rules (volume in UNITS, step-by-step verification, user confirmation)
Safety protocol for irreversible trading operations
Guidance to use paper mode and smaller sizes when uncertain

Tool Annotations

Each tool carries metadata hints per the MCP spec:

Trading tools (place_order, modify_order, close_position, cancel_order): destructiveHint: true, idempotentHint: false — signals irreversible, non-repeatable operations
Read-only tools (get_positions, get_quote, get_symbols, get_knowledge): readOnlyHint: true, idempotentHint: true — safe to auto-approve

MCP clients may use annotations to require explicit user approval before executing destructive tools.

Tool Description Warnings

Trading tool descriptions include explicit “CALCULATION SAFETY” blocks reminding the agent to:

Compute volume step-by-step: desired_lots × LOT_SIZE = units
Verify LOT_SIZE from the symbol catalog
Cross-check for misplaced zeros
Get user confirmation before submitting

Limitation: These are guidance mechanisms, not enforcement. The server validates inputs (schemas, risk checks), but cannot verify whether the agent’s intent matches the user’s intent.

7. Multi-Tenant Security (Cloud Mode)

When running as a multi-tenant server, additional security layers apply:

SSRF Protection

The server validates every FIX host before opening a connection:

Host allowlist: Only explicitly configured broker servers are allowed
Port range: Only standard FIX ports are accepted
Private IP blocking: Loopback, private network, and link-local addresses are all rejected

Requests that fail validation are rejected with 403 Forbidden.

Brute Force Lockout

Per credential set:

5 consecutive authentication failures → 15-minute lockout
Lockout is per credential set, not per IP

Credential Security

Raw FIX credentials are never stored after session creation:

A one-way hash of your credentials is used for session routing and logging
Raw credentials are discarded after authentication
Credentials are re-verified on every request

Coalescing Security

When multiple concurrent requests arrive for the same credentials:

Only one FIX logon is initiated (coalesced)
All coalesced requests re-verify credentials against the session before returning
Prevents session hijacking via timing of concurrent initialization requests

Session Isolation

Each user gets completely isolated runtime resources:

Separate FIX connection, trading state, journal, kill switch, rate limiter, and trade lock
One user’s trades cannot affect another user’s state or risk limits
Journal entries are written to per-user files

Idle Session Cleanup

Sessions inactive for 30 minutes are automatically:

FIX Logout sent to broker
Session resources freed
Removed from active sessions

This prevents resource exhaustion from abandoned sessions.

8. OAuth 2.1 Authentication (Cloud Mode)

OAuth 2.1 is the primary authentication method for the cloud deployment. You enter FIX credentials via a browser form, and the server handles encryption, token management, and session lifecycle automatically.

Token Security

Opaque tokens (not JWT) — enables server-side revocation
Tokens stored as hashes — raw tokens never persisted
Access token TTL: 1 hour
Refresh token TTL: 7 days
Authorization codes: 60-second TTL, single-use

Credential Encryption

FIX credentials are encrypted before storage
Per-user encryption keys ensure isolation
Credentials decrypted on each request, never stored in plaintext
Credentials are stored in secure persistent storage with automatic expiry

Authorization Flow

Browser-based clients see a branded credentials form with a success page after authorization
Machine clients (programmatic OAuth) receive a 302 redirect with the authorization code

PKCE (Proof Key for Code Exchange)

PKCE S256 is mandatory for all authorization flows
Prevents authorization code interception attacks

Token Revocation

Explicit token revocation endpoint available
Refresh token rotation: each refresh issues a new pair, old refresh token is invalidated
On credential change: existing tokens are revoked and re-authorization is required

CSRF Protection

Authorization form includes a CSRF token (random, single-use)
State parameter validated on redirect callback
Form uses POST method with no inline JavaScript