Wingman AI – Security & Compliance

This article describes the security and compliance architecture of Wingman AI — Leon's conversational AI assistant. It covers how Wingman accesses Leon data, how user permissions are enforced, how the MCP (Model Context Protocol) integration works, and what controls exist to protect operator data. It is intended for customers, security officers, and compliance teams evaluating the use of Wingman within their organisation.

What is Wingman AI

Wingman is an AI chat assistant embedded in Leon that allows users to query and interact with Leon data using natural language. A user can ask Wingman questions such as "show me flights for next week", "what is the maintenance status of aircraft XY-ABC", or "update the checklist item for my upcoming flight". Wingman responds by fetching data from Leon in real time and presenting it in a conversational format.

Wingman is powered by OpenAI models (GPT series). Leon Software's OpenAI account is configured under an agreement that explicitly prohibits OpenAI from using submitted data to train or improve its models.

How Wingman Accesses Leon Data — the MCP Integration

Wingman uses the Model Context Protocol (MCP) as its mechanism for interacting with Leon. MCP is an open standard for connecting AI assistants to external data sources via a set of defined "tools". Each tool represents a specific capability — for example, fetching flight data, reading maintenance records, or updating a checklist item.

The architecture works as follows:

1. The user sends a message to Wingman via the Leon interface.

2. The OpenAI model receives the message along with a list of available MCP tools and decides which tool(s) to call to fulfil the request.

3. Leon's backend acts as the MCP client and forwards the tool call to the Leon MCP Server — a dedicated Leon service that exposes Leon data as MCP tools.

4. The MCP server processes the request and returns the result to the AI model.

5. The AI model formulates its response based on the data returned by the tool and presents it to the user.

Permission Enforcement — How User Permissions Are Respected

This is a fundamental security property of the Wingman integration: Wingman can only access data that the authenticated user is permitted to access in Leon. This is not a policy declaration — it is enforced technically through the MCP authentication mechanism.

Access Token per User Session

Every time a Wingman conversation requires a tool call, Leon generates a fresh short-lived access token derived from the user's own Leon session (refresh token). This token is then used as the Authorization: Bearer header for all requests sent to the MCP server:

• The token encodes the identity of the authenticated user.

• The token encodes the operator context (which airline/operator the user belongs to).

• The MCP server validates this token on every request, the same way the Leon GraphQL API validates tokens.

Because the MCP server authenticates using the same token mechanism as Leon itself, it inherits the full permission model — aircraft restrictions, role-based access control, operator boundaries, and all other Leon access rules. If a user does not have permission to view a particular aircraft or dataset in Leon, Wingman cannot access that data either.

Operator Isolation

Each Wingman conversation thread is bound to a specific Leon login. The system enforces at the repository level that a user can only access their own threads — it is not possible to read or continue another user's conversation. Additionally, the MCP server URL is scoped per operator subdomain, ensuring calls are always routed to the correct operator environment.

Tool Approval Mechanism

Before Wingman can execute any MCP tool call that performs an action (particularly write operations such as updating a checklist item), Leon applies a two-tier tool approval check.

Tier 1 — System Default Approved Tools

Certain tools are designated as "approved by default" across the system. These are read-only, low-risk data retrieval tools that do not require explicit user confirmation on every use. This list is maintained centrally by the Leon team and stored in a shared configuration table (mcp_approved_tools_by_default).

Tier 2 — Per-Thread User Approval

Any tool that is not in the system default list requires explicit user approval before it is executed. When Wingman determines it needs to call such a tool, it pauses execution and presents the pending tool call to the user — showing the tool name and the arguments it intends to use. The user must explicitly approve or decline before Wingman proceeds.

Once a user approves a tool within a conversation thread, that approval is remembered for the duration of the thread. In subsequent turns within the same conversation, the same tool will be executed automatically without prompting again. This approval memory is stored in the wingman_chat_thread_approved_tools table and is scoped to the individual thread.

Depth Limit on Tool Chains

Wingman supports multi-step reasoning — after receiving the result of one tool call, the AI model may decide to call additional tools. To prevent runaway execution, Leon enforces a maximum depth of 10 consecutive tool-calling steps per conversation turn. If this limit is reached, the execution is terminated with an error rather than continuing indefinitely.

Data Sent to OpenAI

The following types of data are transmitted to the OpenAI API when Wingman is used:

Conversation Storage and Data Retention

All Wingman conversation data is stored within Leon's own database infrastructure, scoped to the individual user (login) and operator. The following records are persisted:

• Conversation threads — one thread per conversation session, tied to a specific Leon login.

• Messages — every user message and AI response, including tool call metadata.

• Pending MCP approvals — temporary records for tool calls awaiting user approval, removed after the approval decision is processed.

• Approved tools memory — the list of tools a user has approved within a specific thread, to avoid repeated approval prompts.

• Usage statistics — token consumption per user per conversation, used for billing and monitoring.

Token Usage Tracking

Leon tracks AI token consumption for each Wingman conversation at the per-user level. Usage is recorded in the ai_usage_statistics table, including the number of tokens used, the resource type (Wingman Chat), and the status of each request. This data supports billing, monitoring, and capacity management.

Security Controls Summary

Compliance Considerations

• GDPR / data protection: Wingman transmits actual Leon records to the AI model as needed to answer user queries. These records may include personal data (crew names, passenger information, etc.) depending on the user's question and the tools invoked. This processing is subject to Leon's data processing agreement with OpenAI, which includes the no-training clause. Operators should ensure their use of Wingman is reflected in their own data processing documentation.

• Data residency: Tool call results are processed by OpenAI's infrastructure. Customers with strict data residency requirements should review OpenAI's data processing agreements and regional infrastructure independently.

• Audit trail: All Wingman conversations (messages and tool calls) are stored in Leon's database, operator-scoped, and can be reviewed for audit purposes.

• Opt-out: Wingman can be disabled per operator by the Leon team if required for compliance or operational reasons.

• Minimum privilege: Because Wingman inherits the user's own Leon permissions, the principle of least privilege is naturally enforced — restrict a user's permissions in Leon and Wingman automatically operates within those same restrictions.

Summary

For further questions regarding data processing, security architecture, or compliance documentation, please contact the Leon Software support team.