Maintainer guidance requested for a bounded Python Agent Memory Guard integration

[vgudur-dev]

Hello Microsoft Agent Framework maintainers,

I am writing solely in a personal capacity to request design and submission guidance. This is a nonconfidential, public-scope question; I do not represent an employer, Microsoft, OWASP, or any customer, and I am not claiming any endorsement, acceptance, integration, support, or adoption by Microsoft or OWASP.

Would maintainers consider a deliberately narrow, Python-only integration with OWASP Agent Memory Guard (AMG), and, if so, which placement is appropriate?

1. an official MAF Python package/component;
2. an official documentation/sample integration only; or
3. a separately maintained, versioned compatibility artifact outside the SDK.

The proposed initial boundary is a direct guarded-store AMGHistoryProvider (or maintainer-approved equivalent) built on MAF’s documented history/context-provider lifecycle. It would use AMG MemoryGuard.read() before adding scoped history to model context and MemoryGuard.write() before persisting selected messages, with explicit provenance mapping for user input, agent-authored output, system-controlled messages, and external tool results.

This proposal would be limited to AMG-owned direct storage—initially its in-memory store and, if approved, its documented Redis store—for Python 3.10–3.13. It would not claim to wrap or protect Foundry Memory, Mem0, Cosmos, Neo4j, generic vector/semantic providers, hosted-provider internals, out-of-band store access, or .NET. A blocked/quarantined write would not be persisted by this provider; a blocked, redacted, or integrity-failed read would not be injected into model context. Exact failure and diagnostic behavior would be agreed before implementation.

Before any code or PR, could the relevant maintainers/area owners please decide or advise on the following?

• Placement and ownership: Which of the three artifact models above is acceptable, and who would own compatibility, releases, support/status, documentation, and dependency updates?
• Boundary: Is the direct-store, Python-only scope acceptable as a first step, with the explicit exclusions above and no cross-runtime or all-provider claim?
• FIDES and Agent Hooks: Should this provider be separate from, composed with, or declined in favor of FIDES and Agent Hooks? Please specify the intended ordering/interaction, responsibility split, and whether either feature should own related enforcement, telemetry, configuration, or user guidance. The proposed provider is intended to complement—not replace—those controls, tool approval, validation, or application authorization.
• Review and release: What dependency/license, privacy/data-handling, vulnerability response, security review, test matrix, package lifecycle/staging, release, and documentation/catalog review would be required for the chosen model?
• Permitted route: Because GitHub issue creation appears restricted, which official channel and submission format should be used for a small design sketch and test matrix? I will not attempt to bypass repository controls or submit a surprise PR.

If there is interest, I can prepare only the requested design material: lifecycle pseudocode, explicit scope/failure semantics, and tests for round-trip history, blocked writes, poisoned reads, provenance, scope isolation, and streaming/tool-loop behavior. No implementation is requested or implied by this question.

Thank you for guidance.

Links

• MAF context providers
• MAF contribution guide
• MAF Agent Security / FIDES
• MAF Agent Hooks
• MAF community channels
• MAF issue search / current restricted issue-creation context
• OWASP Agent Memory Guard