.NET: [BREAKING] fix: use allow list for configuration keys

[Vincent Biret (baywet)]

Motivation & Context

This change hardens declarative Power Fx configuration handling so agent and workflow definitions no longer receive broad access to host configuration or ambient process environment values by default. The goal is to align the .NET declarative pipeline with the safe-by-default posture used by Python and to prevent secrets from being accidentally surfaced through workflow messages or persisted state transitions.

Description & Review Guide

• What are the major changes?
  • Adds explicit allowlists for configuration/environment values that may be exposed through declarative Env references.
  • Disables process environment fallback unless AllowProcessEnvironmentVariableFallback is explicitly enabled.
  • Marks env-derived workflow values as sensitive and propagates sensitivity through expression evaluation, assignments, transformations, table edits, foreach, parse operations, and checkpoint restore.
  • Blocks sensitive values from user-visible or agent-message egress paths such as SendActivity, Question, AddConversationMessage, CopyConversationMessages, and InvokeAzureAgent input messages.
  • Adds sensitivity-aware helper APIs for callers that need to inspect values without throwing.
  • Caps default Power Fx expression length for factory-created engines and keeps Set(...) disabled because it is not integrated with workflow scoped state/checkpoint sensitivity.
• What is the impact of these changes?
  • Breaking: workflows and agents that previously relied on implicit configuration or environment access must now provide the relevant allowlist.
  • Breaking: workflows that relied on process environment fallback must set AllowProcessEnvironmentVariableFallback = true in addition to allowing the variable name.
  • Breaking: workflows that intentionally emitted env/config-derived values through activities, questions, conversation messages, copied messages, or Azure agent input messages will now throw because those values are sensitive.
  • Breaking: callers of FormatTemplateAsync, EvaluateValueAsync, EvaluateListAsync, or expression-based ConvertValueAsync may now receive DeclarativeActionException for sensitive results; use the corresponding sensitivity-aware APIs when the value must be handled programmatically.
  • Potentially breaking: very large Power Fx expressions may fail under the new default maximum expression length of 10000 unless the host configures a higher limit.
  • Potentially breaking: agent configuration injection now initializes only configuration variables referenced by the declarative definition instead of blindly loading every configuration key into the Power Fx engine.
  • Behavioral/diagnostic: sensitive assigned values are redacted in debug output, and sensitivity metadata is persisted in sidecar workflow state for checkpoint restore.
• What do you want reviewers to focus on?
  • Please focus on whether the compatibility impact is acceptable for a security hardening change, whether the allowlist/fallback options are clear enough for hosts, and whether the chosen egress guards cover user-visible paths without blocking legitimate non-visible uses of secrets.

Related Issue

No linked issue.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

Signed-off-by: Vincent Biret vibiret@microsoft.com

[Copilot]

🔵 Needs a closer look

Sensitivity-aware counterparts are missing for two newly restricted expression APIs, and the Question egress guard lacks direct coverage.

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

dotnet/src/Microsoft.Agents.AI.Workflows.Declarative/Kit/IWorkflowContextExtensions.cs:170

• The new sensitive-result behavior has no equivalent opt-in path for this API. EvaluateListAsync now throws for a sensitive list, but only scalar EvaluateValueWithSensitivityAsync was added; likewise, the new ConvertValueWithSensitivityAsync supports key/scope conversion but not the expression-based ConvertValueAsync overload. Callers therefore cannot perform the documented migration while retaining the existing list conversion or expression conversion semantics. Add sensitivity-aware counterparts for these two expression APIs (with tests and public API baselines).
  dotnet/src/Microsoft.Agents.AI.Workflows.Declarative/ObjectModel/QuestionExecutor.cs:194
• This new egress guard is not covered by QuestionExecutorTest; the added question test only verifies sensitivity on the assigned default value. Add a test whose prompt (or retry/default prompt) references a sensitive Env value and assert that DeclarativeActionException is raised before a MessageActivityEvent or external request is emitted, matching the coverage added for the other message egress guards.

• Files reviewed: 62/62 changed files
• Comments generated: 0 new
• Review effort level: Balanced