
Governed memory
Persistent agent memory with scoped namespaces, authenticated access, quota controls, and server-side safeguards for sensitive writes.
Open MemQGovernance and data handling
Multinex maps product controls to procurement questions without pretending every deployment has the same risk profile. Use this page to see what exists today, what is preview, and what needs a signed agreement.
This is a control map, not a certification report or legal opinion.
Product controls
Each surface has a different role. Procurement gets clearer when memory, review, protection, and billing are separated instead of bundled into one vague promise.

Persistent agent memory with scoped namespaces, authenticated access, quota controls, and server-side safeguards for sensitive writes.
Open MemQ
A read-first review surface for CRM fields, lakehouse mappings, owners, and business definitions before agents rely on them.
Open Crosswalk
AIEGES Shield is the protection layer in front of prompts, files, tool calls, and memory writes. It keeps sensitive material out of unmanaged AI paths before context reaches providers or MemQ.
Open AIEGES ShieldAIEGES Shield + MemQ
Shield sits before MemQ on a configured MCP path. Local inspection and hosted memory have separate jobs, with separate controls.

An agent prepares a memory write. Route the supported MCP connection through Shield to inspect it.
Local checks apply the configured policy. Sensitive content can be redacted or the request blocked; receipts stay on the device.
An allowed request continues to MemQ using your configured credentials. Shield does not replace MemQ authentication.
MemQ applies its own access and write safeguards, then stores accepted context within the authorized namespace.
Integration boundary. Shield is a separate protection layer, not built into every MemQ connection. The native policy-bundle and receipt handshake between the products is planned.
Inspect Shield + MemQFramework alignment
The page avoids certification language unless the artifact exists and applies to the customer deployment.
Readiness mapping
This page is not a SOC 2 Type I or Type II report. It maps product controls that can support an enterprise review.
Access control, audit logging, memory isolation, incident review, and vendor boundary questions are handled during procurement.
Agreement and deployment dependent
Do not process ePHI through Multinex unless a written agreement, deployment scope, and required safeguards are in place.
BAA discussions depend on the product surface, hosting model, data flow, and customer-specific controls.
Contract and data-flow review
Data residency, erasure, subprocessor, and transfer terms must be reviewed against the customer's actual deployment.
DPAs and SCCs are handled as contract artifacts, not as a blanket claim made by a marketing page.
Evidence by request
Security questionnaires and architecture evidence should be requested for the exact product and environment being evaluated.
Reference diagrams, policy summaries, and audit-log examples can be scoped to MemQ, Shield, Crosswalk, or Billing Manager.
Compliance packets should be scoped to the product, data type, and environment under review. Ask for the exact package instead of relying on a generic badge.
DPAs, BAAs, security questionnaires, architecture diagrams, and audit evidence depend on contract status and deployment model.