Transit ops stands up an MCP-style tool server for fare systems without mutual authentication. What should be fixed first?
Select an answer to reveal the explanation.
Short Explanation
An unauthenticated fare tool server is a vending machine with no lock on the coin box. Make the agent and the MCP server prove who they are to each other before any call. Skipping mutual auth invites freeloaders onto the transit stack.
Full Explanation
A transit ops MCP-style tool server for fare systems without mutual authentication lets untrusted callers invoke fare tools if they can reach the endpoint. The first fix is requiring mutual authentication between agents and the fare tool server so both sides prove identity before tool execution. In civic fare environments, that protects fare adjustments, rider accounts, and payment-adjacent operations from rogue chatbots, misconfigured agents, or lateral movers on the municipal network.
Allowing any municipal chatbot to call fare tools over plaintext HTTP fails by concept: it widens the caller set and removes confidentiality/integrity for credentials and fare payloads in transit. Hard-coding fare API keys into every agent’s public system prompt is secret sprawl into model context and logs, not mutual authentication of the MCP channel. Disabling TLS so MCP clients can debug packets on the bus network trades observability for cleartext exposure of tool traffic and credentials on operational networks.
Exam caveat: mutual authentication establishes who is talking; it must still be paired with authorization (which fare tools each authenticated agent may call) and transport protection—mTLS without least privilege still allows an authorized-but-over-scoped agent to misuse fare APIs. Operational check: enable mutual TLS or equivalent client authentication on the fare MCP server, reject unauthenticated clients in a staging test, confirm only approved transit agent identities can list or invoke fare tools, and verify plaintext HTTP callers are denied.