Maintainer alignment: potential Agent Memory Guard provider and guarded memory-service boundary #7347

I am writing in a personal, nonconfidential capacity. I am not speaking for my employer, Google, OWASP, or any other organization. This is a scope question only; it does not claim endorsement, acceptance, support, integration, or adoption by Google or OWASP.

🔴 Required Information

Is your feature request related to a specific problem?

ADK exposes runner-level security callbacks and a separate BaseMemoryService interface. A runner plugin alone cannot truthfully claim to mediate every long-term-memory read or write. Before any implementation, I am asking maintainers to choose whether and where a narrowly memory-lifecycle-focused Agent Memory Guard (AMG) integration belongs.

Describe the Solution You'd Like

The intended scope uses documented public ADK APIs only:

• AdkMemoryGuardPlugin(BasePlugin) would scan text or serializable payloads at user-message, assembled model-context, model-response, and tool boundaries. Non-text and multimodal values would be preserved and explicitly documented as unscanned.
• GuardedMemoryService(BaseMemoryService) would decorate a caller-provided service: pre-scan supported ingestion operations and scan/filter/block search_memory results before recall. It would guard only operations that pass through the decorator; it would not claim backend-integrity verification, coverage of direct/out-of-band access, or universal memory protection.

The plugin is defense in depth; the optional memory-service decorator is the proposed memory-ingestion/retrieval boundary. The proposal is not a request to modify Model Armor and is not intended as a generic duplicate of existing runner guardrails. A first package would be Python-only, use public APIs, and include credential-free deterministic tests.

Impact on your work

A maintainer decision would prevent an unsupported or misleading integration and establish the correct placement and failure semantics before code is written. There is no requested release deadline.

Willingness to contribute

Conditional: if maintainers select a placement and enforcement contract, I can prepare a small design and test matrix for review before any implementation. This is not a commitment to a release or support obligation.

🟡 Recommended Information

Describe Alternatives You've Considered

Please choose the appropriate direction, if any:

• an externally maintained provider package (for example, adk-agent-memory-guard) followed by an ADK integration-catalog/docs page;
• google/adk-python-community;
• ADK core; or
• no integration / another location.

Proposed API / Implementation

Do maintainers approve or reject the two-component BasePlugin plus optional GuardedMemoryService design above? In particular, is decorating BaseMemoryService the appropriate public extension boundary for guarded ingestion and retrieval, rather than representing a runner plugin as universal memory coverage?

For an unsafe tool result before it can become later model context, which typed behavior should a first implementation use?

• replace: return a documented typed refusal/replacement envelope to the model context;
• error: return a documented typed tool-error/refusal result through the tool-result path; or
• abort: raise/return a documented typed policy failure that stops the affected runner flow.

A silent text placeholder would not be used. The selected behavior would be regression-tested to ensure it cannot trigger a tool re-call loop.

If there is interest, I can prepare a small design and test matrix only after this placement and contract are clarified. If the answer is no, or the scope should be narrowed, that guidance would be equally useful.

Additional Context

• ADK plugins
• ADK MemoryService
• ADK documentation contribution guidance
• Model Armor integration guide
• Related tool-output screening discussion: adk-python#6966
• OWASP Agent Memory Guard v0.3.2