Compare
How does Inhold compare with hosted agent memory from AWS, Microsoft and Google?
Inhold adds per-read policy by purpose, an audit row for every allowed or denied read, and human-approved skills; cloud providers offer managed memory at larger scale.
Inhold is being built. No customers yet. Repo goes public 9 Nov 2026.
Comparison
| Product | Where it runs | Policy per read, by purpose | Audit of reads, incl. denials | Tamper evidence | PHI labelling | Approval of learned behaviour | HIPAA / BAA (vendor's words) | Licence | Better than Inhold at |
|---|---|---|---|---|---|---|---|---|---|
| Inhold | In the end customer's account; v0 single machine, AWS kit in build | Yes: actor, purpose, data label; deny by default | Yes, one row per decision | Hash-chained audit rows | Local patterns, plus an optional local name model | Yes, named approver for each skill | No certification; runs in your account | Apache-2.0 | Not applicable |
| AWS Bedrock AgentCore Memory | AWS managed service in the customer's AWS account and region | Per user, tenant, namespace and operation via Cedar policies when Memory sits behind AgentCore Gateway; deny by default. Purpose not stated | CloudTrail data events documented for Gateway; LOG_ONLY mode logs policy results. Read logging for Memory itself not stated | CloudTrail log file validation is available on the trail | Not stated | Not stated; long-term memory is extracted by strategies that use models | "HIPAA eligible" | Proprietary service | Managed scale, many certifications, Cedar policy engine, usage pricing |
| Microsoft Foundry Agent Service memory (preview) | Managed memory store; whether it sits in customer-owned resources is not stated. VNet not supported for memory stores | Per scope (for example per user ID); Foundry RBAC roles. Purpose not stated | Not stated | Not stated | Not stated; docs advise instructing the model not to store personal data | Not stated; an LLM extracts and consolidates memories | Not stated on the memory pages | Proprietary service, preview terms | Automatic extraction and consolidation, conflict resolution, TTL and per-user deletion |
| Google Memory Bank (Agent Engine / Gemini Enterprise Agent Platform) | Google managed; CMEK, VPC Service Controls and data residency at rest listed as supported | IAM Conditions on memory scope; not on ListMemories or PurgeMemories. Purpose not stated | Not stated on Memory Bank pages | Not stated | Not stated | Not stated; uses generative models to generate memories | HIPAA listed as supported | Proprietary service | CMEK, VPC-SC, residency, scope-based IAM, model-generated memories |
Where they are the better choice
- Your whole product already runs on one cloud and the customer accepts that cloud's BAA. The native service is one less thing to install and review.
- You need memory extraction and consolidation done for you. All three use models to turn conversations into memories. Inhold makes no model calls and stores what your agent writes.
- You need certifications today. AgentCore lists HIPAA eligibility plus SOC 2, ISO 27001, FedRAMP and more. Inhold has no audit report yet.
- You need production scale now. These are managed services. Inhold v0 runs on one machine with SQLite.
- You want per-user isolation enforced by the cloud's own policy engine. AgentCore Memory with Gateway and Cedar does this with deny by default, and Google supports IAM Conditions on memory scope.
- Your customer is on Azure or GCP. Inhold's install kit is AWS only and still in build.
Questions
Questions
Can Inhold run alongside AgentCore Memory, Foundry memory or Memory Bank?
Inhold is a separate layer, so in principle an agent could call both. We have not built or tested a connector to any of these services, so treat it as untested today.
Does Inhold replace my cloud's BAA?
Inhold does not replace any BAA, and it has no certification. It runs in the end customer's account, makes no model calls and sends no data to us; your BAA questions stay with the cloud provider.
Why would a reviewer want Inhold's audit if CloudTrail exists?
Inhold writes a row for every context read and write, allowed or denied, with the actor, purpose and data label. On the AgentCore pages we read, CloudTrail data events are documented for Gateway, and read-level logging for Memory itself was not stated.
Sources (all checked 31 Oct 2026)
- AgentCore compliance validation: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/compliance-validation.md
- AgentCore pricing: https://aws.amazon.com/bedrock/agentcore/pricing/
- AgentCore Memory fine-grained access control (what's new, 28 Aug 2026): https://aws.amazon.com/about-aws/whats-new/2026/08/agentcorememory-fine-grained-access-control/
- AgentCore Memory FGAC via Gateway: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory-gateway-fgac.html
- AgentCore CloudTrail data events (Gateway): https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/enabling-cloudtrail-data-event-logging.md
- Foundry memory concepts: https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-memory
- Foundry memory how-to: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/memory-usage
- Memory Bank overview: https://docs.cloud.google.com/agent-builder/agent-engine/memory-bank/overview
- Memory Bank IAM Conditions: https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank/iam-conditions
Facts about other products come from each vendor's own pages. "Not stated" means we did not find it there, not that the product lacks it. Tell us if a row is wrong and we will fix it.