Add Ollama Local LLM Working Mode

[Copilot]

Implements the MafOllama working mode as specified in docs/plans/ollama-working-mode-plan.md, enabling agents to use locally hosted Ollama models via OllamaSharp.

Changes

New ZavaMAFOllama project

• MAFOllamaAgentProvider with AddMAFOllamaAgents() and AddMAFOllamaWorkflows() extensions
• Uses keyed service ("ollama") to allow multiple IChatClient implementations
• Default endpoint: http://localhost:11434, model: ministral-3 (configurable via Ollama__Endpoint, Ollama__ChatModel)

Controllers

• SingleAgentControllerMAFOllama → /api/singleagent/maf_ollama
• MultiAgentControllerMAFOllama → /api/multiagent/maf_ollama

WorkingMode enum

• Added MafOllama with short name maf_ollama, display name "MAF - Ollama"
• Updated AllModes, Parse(), TryParse()

AgentMetadata

• Added FrameworkIdentifiers.MafOllama, LogPrefixes.MafOllama
• Added GetOllamaAgentName() method

Store frontend services

• Updated SingleAgentService.cs and MultiAgentService.cs endpoint mappings

Usage

// In Program.cs
builder.AddMAFOllamaAgents();
builder.AddMAFOllamaWorkflows();

// Configuration (appsettings.json)
{
  "Ollama": {
    "Endpoint": "http://localhost:11434",
    "ChatModel": "ministral-3"
  }
}

Frontend mode selector auto-populates from WorkingModeProvider.GetAllModes().

Original prompt

implement this [docs\plans\ollama-working-mode-plan.md]

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

To fix the problem, we should ensure that any user-provided value included in log messages is sanitized before being logged. For plain-text logs, the primary concern is control characters like \r and \n which can create additional lines or otherwise break log framing; removing or normalizing them is sufficient and preserves most of the value of the log message.

The best minimally invasive fix here is to create a sanitized version of request.ProductQuery right before logging, by removing carriage returns and newlines (and optionally other line separators) and using that sanitized value in the log call. We keep the logging message and functionality the same, just with safer input. No changes are needed to method signatures or other functionality.

Concretely, in AssistAsync within src/MultiAgentDemo/Controllers/MultiAgentControllerMAFOllama.cs, immediately before the _logger.LogInformation call, create a local variable, e.g., sanitizedProductQuery, which takes request.ProductQuery and calls Replace(Environment.NewLine, string.Empty) and also removes \n and \r explicitly (to cover all typical cases). Then, update the _logger.LogInformation call to pass sanitizedProductQuery instead of request.ProductQuery. No new imports are needed, since Environment is in System, which is implicitly available.

To fix the problem, we should sanitize user-provided strings before logging them, ensuring they cannot inject line breaks or other control characters into log files. For plain-text logs, a common pattern is to replace \r and \n with spaces or remove them entirely before passing the value into the logger.

The best way to fix this without changing existing functionality is to introduce a small, private helper method in MultiAgentControllerMAFOllama that takes a string and returns a sanitized version with line breaks removed (or replaced), and then use that helper when logging request.ProductQuery. We’ll keep the log message and template unchanged and only adjust the value passed for {ProductQuery}. Specifically:

• In src/MultiAgentDemo/Controllers/MultiAgentControllerMAFOllama.cs, inside the MultiAgentControllerMAFOllama class, add a private method, e.g. SanitizeForLogging(string? value), that:
  • Returns the input if it is null.
  • Replaces \r and \n with spaces (or removes them).
• Update the log statement in AssistSequentialAsync at line 90 to call SanitizeForLogging(request.ProductQuery) instead of logging request.ProductQuery directly.
• Optionally, we could also use this helper in the other log line that includes request.ProductQuery (line 56–58) to comprehensively address similar issues, but per the description, CodeQL’s highlighted variant is line 90; we will still instrument line 56 as it’s the same pattern and within the shown snippet.

No new external dependencies are required; we can implement this with basic string.Replace.

General approach: Sanitize user input before logging so that it cannot inject extra log entries. For plain-text-oriented logs, removing newline characters (\r, \n) and possibly other control characters is sufficient and preserves most of the content. We should apply this consistently to all log statements that include request.ProductQuery.

Best fix here: In this file, introduce a small helper that removes newline characters from a string and use it to sanitize request.ProductQuery before passing it to _logger.LogInformation. We will not alter the log template or other behavior, only the value passed for {ProductQuery}. Specifically:

• Add a private helper method in MultiAgentControllerMAFOllama such as:

private static string SanitizeForLogging(string? input)
{
    if (string.IsNullOrEmpty(input))
    {
        return string.Empty;
    }

    return input
        .Replace("\r\n", " ")
        .Replace("\n", " ")
        .Replace("\r", " ");
}

(Using spaces keeps the query readable while preventing multi-line logs.)

• In AssistAsync, change the LogInformation call at lines 56–58 to pass SanitizeForLogging(request.ProductQuery) instead of request.ProductQuery.
• In AssistSequentialAsync, change the LogInformation call at line 90 similarly.
• In AssistConcurrentAsync, change the LogInformation call at line 115 similarly (this is the exact sink CodeQL flagged).

No new imports are needed; we use only string operations already available.

In general, to fix log forging issues, user-provided strings must be normalized/encoded before being written to logs. For plain text logs, this usually means removing or replacing newline (\n, \r) and similar control characters so a single logical log entry cannot be split into multiple lines by crafted input. For HTML- or UI-displayed logs, HTML or other appropriate encoding should be applied.

The best fix here, without changing existing behavior, is to sanitize request.ProductQuery before passing it to _logger.LogInformation. We can do this inline in the logging call by replacing occurrences of Environment.NewLine, \n, and \r with safe alternatives such as a space or empty string. This keeps the content semantics mostly intact while preventing multi-line log injection. We will apply this consistently to all logging statements that include request.ProductQuery in this controller: the generic AssistAsync method and the specific workflows, including the highlighted handoff workflow at line 140 and the concurrent workflow at line 115. These are all in src/MultiAgentDemo/Controllers/MultiAgentControllerMAFOllama.cs, and we can implement the fix without adding new imports by using string.Replace, which is part of System.String.

Concretely:

• In AssistAsync, change the LogInformation call at lines 56–58 to use a sanitized version of request.ProductQuery.
• In AssistConcurrentAsync (the concurrent workflow), change the LogInformation call at line 115 similarly.
• In AssistHandoffAsync (the handoff workflow), change the LogInformation call at line 140 similarly.
  To avoid duplicating replacement logic in many places without adding new methods the snippet doesn’t show, we will apply a small inline sanitization expression (chained Replace calls) directly in each logging call.

In general, to fix log-forging risks, user-controlled strings must be normalized before being written to logs, typically by removing or replacing newline and other control characters so that a single log event cannot visually or structurally masquerade as multiple log entries. For plain-text logs, a common minimal fix is to strip \r and \n from user input before logging; for HTML logs, HTML encoding is recommended instead.

In this specific file, the vulnerable use is in AssistGroupChatAsync, where request.ProductQuery is logged directly. We should ensure that the value passed to the logger has newline characters removed. To keep behavior unchanged aside from safety, we can compute a sanitized local variable just before logging, using Replace to strip \r and \n, and then log that sanitized value. To address any similar future issues consistently, we can also add a small private helper method within this controller to sanitize log values, and use it at the logging call site; this does not change semantics other than removing control characters. The edits are limited to src/MultiAgentDemo/Controllers/MultiAgentControllerMAFOllama.cs around the AssistGroupChatAsync method: introduce a private SanitizeForLogging method near the bottom of the class, and modify the _logger.LogInformation line to call this method on request.ProductQuery.

In general, to avoid log forging, user-provided strings should be sanitized before being written to logs. For plain-text style logs, the minimal and common mitigation is to remove newline and carriage-return characters from user input (and potentially other control characters) so an attacker cannot break the log line or visually inject additional entries.

For this specific issue in MultiAgentControllerMAFOllama.AssistMagenticAsync, we should avoid passing request?.ProductQuery directly to the logger. Instead, we can construct a sanitized version that replaces Environment.NewLine, \n, and \r with spaces (or removes them), and then pass that sanitized value as the ProductQuery property in the log call. This keeps the log message and structure identical from the perspective of the rest of the system while ensuring that any malicious line breaks in the query do not affect the integrity of the logs.

Concretely:

• In AssistMagenticAsync, introduce a local variable, e.g. sanitizedProductQuery, that is assigned from request?.ProductQuery with line breaks removed or normalized.
• Use this sanitized variable in the _logger.LogInformation call instead of request?.ProductQuery.
• No new imports are needed; we can rely on string.Replace and Environment.NewLine from the standard library.

Only lines around 202–205 in src/MultiAgentDemo/Controllers/MultiAgentControllerMAFOllama.cs need modification.

---

To fix the problem, any user-controlled value written to logs should be sanitized to prevent log forging. For plain-text logs, this typically means removing or normalizing newline and other control characters from the value before logging, while still logging sufficient information for diagnostics. We should also avoid modifying the log message template to keep existing functionality and structured logging behavior intact.

The best fix here is to sanitize customerId just before it is passed to _logger.LogInformation. We can create a local variable, e.g., sanitizedCustomerId, that removes newline characters from the original customerId using Replace (and optionally other control characters if desired), and then use that sanitized value in the log call. This keeps the logging statement’s template and structure the same, but ensures that any newline characters supplied by the user cannot break the log format. The change is localized to the AnalyzeAsync method in src/SingleAgentDemo/Controllers/SingleAgentControllerMAFOllama.cs. No new imports are required because string.Replace is available by default.

Concretely:

• In AnalyzeAsync, right before the _logger.LogInformation call, introduce var sanitizedCustomerId = customerId?.Replace(Environment.NewLine, string.Empty).Replace("\n", string.Empty).Replace("\r", string.Empty); (or similar).
• Change the _logger.LogInformation call to use sanitizedCustomerId instead of customerId.
• Ensure we only alter those lines and keep all other behavior unchanged.

To fix this, we should sanitize the user-provided customerId before including it in log entries. The general approach is to normalize/encode user input so that it cannot inject line breaks or other control characters into the log stream. For plain-text logs, removing \r and \n from user input (and optionally trimming) is sufficient to prevent straightforward log forging via newlines.

The best minimal fix here is to introduce a sanitized local variable (e.g., safeCustomerId) inside the AnalyzeAsync method, derived from customerId with line breaks removed, and then use this sanitized value in all log messages in this method (both success and error paths). This avoids changing the method’s external behavior while ensuring log safety. We don’t need new imports or helper methods; we can use Replace("\r", "").Replace("\n", "") directly. Concretely:

• Right after entering the try block (or just after parameters are available), create var safeCustomerId = customerId?.Replace("\r", string.Empty).Replace("\n", string.Empty);.
• Replace customerId with safeCustomerId in the log calls at lines 104–106, 140–141, and 146–147.
• Optionally keep using the original customerId for business logic and responses, since the risk identified is specifically about logging.

To fix the issue, user-provided values used in log messages should be sanitized before being passed to the logger. For plain-text logs, the key risk is newline and carriage-return characters that can split or visually corrupt log entries. A minimal, non-breaking mitigation is to normalize customerId into a version where \r and \n are removed (or replaced) before logging, while still using the original value for application behavior.

The best way to fix this snippet without changing external behavior is:

• Introduce a local variable, e.g., sanitizedCustomerId, which is derived from customerId by removing newline and carriage-return characters using Replace.
• Use sanitizedCustomerId instead of customerId in all logging calls within AnalyzeAsync.
• Keep using the original customerId for all non-logging behavior (e.g., passing to BuildFallbackResponse), so functionality remains unchanged.

Concretely, in AnalyzeAsync in src/SingleAgentDemo/Controllers/SingleAgentControllerMAFOllama.cs:

• Immediately after entering the method (or right before the first log call), define:

  var sanitizedCustomerId = customerId?
      .Replace("\r", string.Empty)
      .Replace("\n", string.Empty);

• Replace the use of customerId in the _logger.LogInformation and _logger.LogError calls with sanitizedCustomerId. No new imports are required because string.Replace is in System, which is already available.

In general, to fix log forging issues, sanitize or encode any user-provided data before writing it to logs. For plain-text style logs, removing newline and carriage-return characters (and optionally other control characters) is typically sufficient. For logs that might be rendered as HTML, HTML-encoding user input before logging is recommended.

In this file, the risky behavior is logging the raw prompt in the AnalyzeMAFOllamaAsync method (and, for consistency and safety, the other similar methods). The best fix with minimal functional impact is to create a sanitized version of prompt that strips newline characters and log that instead, while continuing to use the original prompt for actual analysis logic so behavior doesn’t change. We can do this inline by introducing a new local variable, e.g., var sanitizedPromptForLogging = prompt?.Replace("\r", "").Replace("\n", " "); right before each log call, and then pass sanitizedPromptForLogging to _logger.LogInformation. This requires no new imports and keeps logging semantics nearly identical, except that line breaks and carriage returns from the user will no longer appear in log output.

Specifically:

• In AnalyzeLLMAsync, AnalyzeMAFLocalAsync, AnalyzeMAFFoundryAsync, and AnalyzeMAFOllamaAsync, define a sanitized variable immediately before _logger.LogInformation(...).
• Replace the log argument prompt with that sanitized variable.
• Do not alter prompt itself, or its subsequent use in AnalyzeWithAgentAsync.

All changes will be made in src/AnalyzePhotoService/Controllers/PhotoAnalysisController.cs within the shown methods.

In general, to fix log-forging issues, any user-controlled data included in log entries should be sanitized so that it cannot inject line breaks or other control characters that could be misinterpreted as separate log entries or markup. For plain-text logs, the primary concern is to strip or neutralize \r and \n (and possibly other control characters) before logging. For logs that will be displayed as HTML, HTML encoding is appropriate before writing to log storage.

Here, the best fix that preserves existing functionality is to sanitize customerId right before it is logged in GetCustomerMAFOllamaAsync, by removing any newline characters (and, optionally, other control chars) from the string used as the log parameter. This does not change what ID is used for downstream processing (we leave the original customerId when calling GetCustomerFromDataServiceAsync, to avoid altering behavior), but it ensures the logged representation cannot break log formatting. A simple approach, consistent with the recommendation text, is to call Replace to remove \r and \n. Since we are already using string interpolation only for the static prefix and the message template, we can keep the template unchanged and just change the argument we pass to the logger.

Concretely:

• In GetCustomerMAFOllamaAsync, compute a sanitized variant, e.g., var safeCustomerId = customerId?.Replace("\r", string.Empty).Replace("\n", string.Empty);
• Use safeCustomerId as the logged value, while leaving the call to GetCustomerFromDataServiceAsync(customerId, ...) unchanged.
• This requires no new imports and no external dependencies.

In general, to fix log forging issues, ensure that any user-controlled strings written to logs are normalized so they cannot inject new log lines or otherwise confuse log parsers. For plain-text logs this typically means removing or replacing newline (\r, \n) and other control characters; for HTML logs this means HTML-encoding user input before logging.

In this file, the problematic pattern is directly logging customerId route parameters and request.CustomerId values. The best fix that doesn’t change existing functionality is to introduce a small helper method in CustomerController that takes a string and returns a sanitized version with newline and carriage-return characters removed (and potentially other control characters if desired). Then, use this helper when passing customerId or request.CustomerId into _logger.LogInformation(...). This preserves the log message structure and parameterization while ensuring that any embedded line breaks are removed before writing to logs.

Concretely:

• Add a private static method SanitizeForLogging(string value) near the bottom of CustomerController (but inside the class) that returns value?.Replace("\r", string.Empty).Replace("\n", string.Empty) (or similar).
• Update all _logger.LogInformation calls that log customerId or request.CustomerId to pass SanitizeForLogging(customerId) or SanitizeForLogging(request.CustomerId) as the argument instead of the raw value.
• No new imports are needed; we only use string.Replace, which is in System and already available.

In general, to prevent log forging when logging user-provided strings in plain-text-oriented logs, normalize those strings before logging: remove newline and carriage-return characters (and optionally other control characters), or perform appropriate encoding. This ensures a malicious value cannot inject additional log lines or otherwise alter log structure.

For this specific file, we should sanitize request.SearchQuery before passing it to _logger.LogInformation in all endpoints that log it. The simplest, non–behaviour-breaking fix is to create a local variable that holds a sanitized version of SearchQuery, using Replace to strip Environment.NewLine, \n, and \r, and then log that sanitized value. We will make this change in each method that logs request.SearchQuery:

• SearchInventoryLlmAsync
• SearchInventoryMAFLocalAsync
• SearchInventoryMAFFoundryAsync
• SearchInventoryMAFOllamaAsync
• SearchInventoryDirectCallAsync

No new imports are needed; we can use Environment.NewLine and string Replace directly. The rest of the application logic (calls to SearchInventoryFromDataServiceAsync, return types, etc.) remains unchanged.

To fix this, sanitize the user-provided product string before logging it. For plain-text logs, the main concern is newline (and possibly carriage return) characters that allow an attacker to visually forge additional log entries. We should create a sanitized version of product with these characters removed (or replaced) and use this sanitized value in all log calls that include product. This keeps existing behavior—searching and agent calls—unchanged because the raw product is still used for business logic; only what is logged is normalized.

The best minimally invasive fix in this file is:

• In each public action method that logs product (FindProductLocationLlmAsync, FindProductLocationMAFAsync, and FindProductLocationMAFOllamaAsync), compute a local safeProduct by removing \r and \n from product.
• Use safeProduct instead of product in the corresponding _logger.LogInformation calls.
• Keep the rest of the flow (FindProductLocationAsync, agents, etc.) unchanged so functionality is preserved.

No new helper methods or external dependencies are required; we can use string.Replace directly in these methods.

In general, to prevent log forging with plain-text logs, all user-controlled strings included in log messages should be normalized so they cannot inject unexpected line breaks or other control characters that affect how log entries are displayed. The simplest robust mitigation here is to remove or replace newline sequences (\r, \n, and Environment.NewLine) from request.ProductQuery before passing it to the logger, while leaving the rest of the logging behavior intact.

The best fix with minimal functional impact is to introduce a small, local helper method inside MatchmakingController that takes a string and returns a “log-safe” version with any newline characters stripped. We then use this helper for all _logger.LogInformation calls that include request.ProductQuery. This way, we don’t change business logic, only how the potentially dangerous value is represented in logs. Concretely:

• Add a private method such as SanitizeForLog(string input) to MatchmakingController that replaces "\r\n", "\n", and "\r" with empty strings (or spaces).
• Update the four logging calls in FindAlternativesLlmAsync, FindAlternativesMAFAsync, FindAlternativesMAFOllamaAsync, and FindAlternativesDirectCallAsync to pass SanitizeForLog(request.ProductQuery) instead of request.ProductQuery.
  No new imports are needed; we use string.Replace, which is already available.

In general, to fix log forging issues, any user-controlled data that is written to logs should be normalized so that it cannot inject additional log entries or otherwise break the log format. For plain-text logs, the most important step is to remove or replace newline and carriage-return characters (and sometimes other control characters) from user input before logging. When logs are later displayed in HTML, HTML encoding should also be applied.

For this specific controller, the issue arises from logging request.UserId (and similarly request.ProductQuery) directly. The least intrusive fix that does not change existing functionality is to sanitize these string values just before logging, by stripping \r and \n characters. We can implement a small private helper method inside MatchmakingController like SanitizeForLogging(string value) that returns the value with newlines and carriage returns removed (or replaced with spaces). We then call this helper for request.ProductQuery and request.UserId in all four logging calls in this file. This keeps behavior the same for normal inputs while preventing attackers from injecting additional log lines. No new external dependencies are required; we can use string.Replace from System (already available) and define the helper as a private method of the controller.

Concretely:

• In MatchmakingController, add a private method SanitizeForLogging(string? value) that replaces \r and \n with empty strings (or spaces), and safely handles null.
• Update the _logger.LogInformation calls in:
  • FindAlternativesLlmAsync
  • FindAlternativesMAFAsync
  • FindAlternativesMAFOllamaAsync
  • FindAlternativesDirectCallAsync
    to pass SanitizeForLogging(request.ProductQuery) and SanitizeForLogging(request.UserId) instead of the raw properties.
• Keep the log templates as-is, preserving existing structured logging and semantics.

All changes will be confined to src/MatchmakingService/Controllers/MatchmakingController.cs in the shown snippet region.

In general, to fix log-forging issues, sanitize or encode any user-controlled string before logging it. For plain-text log outputs, remove or normalize newline and other control characters so a single log entry cannot visually or structurally turn into multiple entries. For HTML outputs, HTML-encode the value.

In this file, the simplest and safest fix without changing functionality is to sanitize request.SearchQuery once in each action before passing it to _logger.LogInformation. We can define a small helper method inside ProductSearchController that removes carriage returns and newlines (and optionally other control characters) from a string. Then, replace direct uses of request.SearchQuery in log calls with SanitizeForLogging(request.SearchQuery). The rest of the behavior (the actual search and the return values) remains unchanged; we only adjust what gets logged.

Concretely:

• In ProductSearchController, add a private static helper method, e.g., SanitizeForLogging(string input), that returns input with \r and \n removed (or replaced with spaces).
• Update the four logging calls in this file:
  • Line 31: pass SanitizeForLogging(request.SearchQuery) as the structured parameter.
  • Line 44: same change.
  • Line 56: same change (this is the one flagged).
  • Line 68: same change for the DirectCall route.
    No new external dependencies are needed; we can use basic string.Replace.