DEV Community: Heath

The Developer's Guide to Governed AI Memory

Heath — Thu, 21 May 2026 10:43:39 +0000

Originally published at tracecontinuity.com

What governed AI memory actually looks like in code

This is a technical post about how Trace Continuity works as an AI memory API — what the code looks like, what the architecture looks like, and specifically what is different about a governed memory layer versus bare vector stores or tools like Mem0 and Zep.

The core primitives

Trace Continuity's API has three primary operations: remember, recall, and forget.

remember — write a memory

const { TraceContinuity } = require('@trace-continuity/sdk');
const client = new TraceContinuity({ apiKey: process.env.TRACE_CONTINUITY_API_KEY });

await client.remember({
  agent: 'support-bot',
  tenant: 'acme-corp',
  fact: 'User prefers email contact, not phone. Contact: user@example.com',
  retention: '90d',
  access: ['support', 'success'],
  metadata: { source: 'conversation', session_id: 'sess_abc123' }
});

What happens before anything is written:

PII scan runs. The email address is detected and redacted. What gets stored: "User prefers email contact, not phone. Contact: [EMAIL_REDACTED]."
Redaction event is logged. Type: EMAIL. Agent: support-bot. Tenant: acme-corp. Timestamp: now.
TTL is set. 90 days from write time. Enforced at the infrastructure layer.
Access policy is stored with the memory. Only agents with role "support" or "success" can retrieve this.
Write audit record is created. Who wrote, when, from what session.
Memory is stored. Embedded and indexed.

recall — retrieve memories

const memories = await client.recall({
  agent: 'support-bot',
  tenant: 'acme-corp',
  query: 'How does this user prefer to be contacted?',
  limit: 5
});
// memories[0] = {
//   fact: "User prefers email contact, not phone. Contact: [EMAIL_REDACTED].",
//   score: 0.94,
//   created_at: "2026-04-01T10:23:00Z",
//   expires_at: "2026-07-01T10:23:00Z",
//   id: "mem_xyz789"
// }

forget — delete a memory

await client.forget({
  tenant: 'acme-corp',
  memory_id: 'mem_xyz789',
  reason: 'user_erasure_request'  // GDPR Article 17 compliance
});

What happens: deletion is authenticated, memory is deleted from all storage layers, and the deletion is logged immutably with reason, timestamp, requesting agent, and memory ID.

How this differs from Mem0, Zep, and bare vector stores

Capability	pgvector / Pinecone	Mem0	Trace Continuity
TTL enforcement	Manual (cron jobs)	Not a feature	Automatic (infrastructure layer)
PII redaction	None	None	Pre-storage, typed detection
Access control	API key only	API key only	Per-memory, per-agent-role policies
Audit logging	None	None	Every read/write/delete
Tenant isolation	Namespace by convention	Namespace by convention	Hard isolation by architecture
GDPR deletion	Manual query + delete	Manual	forget() with immutable proof

The pattern with both Mem0 and Zep: memory is the core, governance is your problem. In Trace Continuity: governance is the core. Memory is how it works.

The retention policy model

Retention in Trace Continuity works at three levels, in order of precedence:

1. Memory-level TTL — set at write time:

await client.remember({ ..., retention: '30d' });   // expires in 30 days
await client.remember({ ..., retention: '1y' });    // expires in 1 year
await client.remember({ ..., retention: 'session' }); // expires when session ends

2. Agent-level default TTL — configured on the agent definition.

3. Tenant-level maximum TTL — hard ceiling set by the platform admin. A compliance team can set guardrails that cannot be overridden by individual agent implementations.

The audit log structure

Every memory operation generates an audit event:

{
  "event_id": "evt_abc123",
  "event_type": "memory.write",
  "tenant_id": "acme-corp",
  "agent_id": "support-bot",
  "memory_id": "mem_xyz789",
  "timestamp": "2026-04-15T14:23:11Z",
  "redactions": [
    { "type": "EMAIL", "field_position": 52 }
  ]
}

The audit log is immutable, queryable (by tenant, agent, event type, time range), and exportable for compliance reporting.

Getting started

npm install @trace-continuity/sdk

const { TraceContinuity } = require('@trace-continuity/sdk');
const client = new TraceContinuity({
  apiKey: process.env.TRACE_CONTINUITY_API_KEY
});

// Governance is on by default.
await client.remember({
  agent: 'my-first-agent',
  tenant: 'my-org',
  fact: 'User is an early adopter. Signed up in April 2026.',
  retention: '1y'
});

Every operation from this point is governed: PII-scanned, TTL-enforced, access-controlled, and audit-logged.

Get your API key → | Full API documentation →

PII Redaction for AI Agents: Why It Can't Be an Afterthought

Heath — Thu, 21 May 2026 10:43:04 +0000

Originally published at tracecontinuity.com

The PII problem in AI memory is not what you think it is

Most engineering teams building AI agents understand that they shouldn't store raw PII. Ask any developer and they'll say: of course we're not storing social security numbers in the vector store.

But PII leaks through AI memory systems in ways that are less obvious — and the developer's mental model of "just don't store the sensitive parts" is not sufficient.

This post explains how PII actually leaks, why afterthought redaction approaches fail, and what architectural PII redaction for AI agents looks like.

How PII enters AI memory without anyone intending it to

Implicit extraction

AI agents don't just store what you explicitly tell them to store. They extract facts. When a language model processes a conversation and derives memories from it, the extracted facts often contain PII the agent never explicitly received.

Example: a user says "my appointment is next Tuesday at the clinic on Maple Street." The agent may extract and store: user_name: Sarah Chen, medical_appointment: 2026-04-29, location: Maple Street Clinic. The user never stated their name — the model inferred it from earlier context.

Contextual embedding

Vector embeddings encode semantic meaning. A memory stored as "the patient prefers morning appointments" embeds differently when it was derived from a conversation that included the patient's name, diagnosis, and insurance information.

Summarization artifacts

Long-context summarization is a common memory strategy: compress a long conversation into a summary, store the summary. LLM summarization is nondeterministic and can preserve PII that was incidental rather than salient.

Third-party data passthrough

When agents access external tools — CRMs, EMRs, financial databases — the data they retrieve gets incorporated into context. A healthcare agent that queries a patient record may inadvertently store memory containing PHI.

Why afterthought PII redaction fails

The intuitive solution is to add a redaction layer: before writing to the memory store, scan for PII and remove it. This is better than nothing. It is not sufficient.

The scanning problem: Named entity recognition (NER) and regex-based PII detection have false negative rates. They miss non-standard formats, contextual PII, and domain-specific identifiers.

The granularity problem: Redaction that removes identifiers but preserves context can still be identifying. "The patient with the rare genetic condition who lives in the small town near the manufacturing plant" is not anonymized just because the name was stripped.

The timing problem: If redaction happens after the AI model has already processed the data, the window for a leak is open. An agent that crashes between inference and redaction may write unredacted data.

The HIPAA AI agents problem: HIPAA requires that PHI protections apply to all forms of PHI — not just the formats you anticipated.

What architectural PII redaction looks like

The right approach moves PII protection from an application-layer concern to an infrastructure-layer invariant.

Scan before storage, not after

In Trace Continuity's architecture, every memory write is intercepted at the API layer before it reaches storage. The redaction pipeline runs synchronously on the memory content:

// Developer writes a memory
await traceContinuity.remember({
  agent: "intake-bot",
  fact: "Patient prefers morning appointments. DOB: 1978-04-15.",
  retention: "365d",
  access: ["clinical-ops"]
});
// Before any storage occurs:
// 1. PII scanner runs (DOB detected)
// 2. DOB is redacted: "Patient prefers morning appointments. DOB: [REDACTED]."
// 3. Redaction event is logged with: field type, redaction timestamp, agent ID
// 4. Redacted version is stored
// 5. Original is never written to persistent storage

The developer doesn't manage the redaction pipeline. It runs for every write, on every memory, with no opt-out path.

Typed PII detection, not just regex

Trace Continuity's redaction engine detects PII by type: names, emails, phone numbers, SSNs, dates of birth, account numbers, addresses, medical record numbers, and custom patterns configurable per tenant.

Redaction events are first-class audit objects

Every redaction creates an immutable audit record: what type of PII was detected, in which memory, from which agent, at what time, and what action was taken. This audit trail is separate from the memory store itself.

The AI data protection architecture that works

Wrong approach: Build AI agent → add memory → add redaction as a cleanup step → discover gaps in production.

Right approach: Use a memory infrastructure layer where redaction is the pipeline, not a plugin. Governance is not something you add to AI memory. It is the condition under which AI memory operates.

This is especially true for:

HIPAA AI agents — PHI protection must be demonstrable, not asserted
GDPR-compliant AI — Data minimization is a GDPR principle
SOC 2 Type II — Auditors want to see that data protections are enforced systematically

Trace Continuity provides pre-storage redaction, typed detection across 15+ PII categories, tenant-configurable rules, and an immutable redaction audit log. Start for free →

AI Memory for Financial Services: Why PCI-DSS Compliance Starts at the Memory Layer

Heath — Thu, 21 May 2026 10:19:40 +0000

Payment AI agents — fraud detection, underwriting, customer support — process cardholder data every session. Most memory solutions either store it raw (PCI-DSS violation) or discard it (losing transaction context). The compliance gap is architectural. Here is how governed memory solves it.

The problem: financial AI agents handle cardholder data every session

Most teams face an inadequate choice:

Store session data as-is. Raw cardholder data in the memory database, no access logs, no retention limits. PCI-DSS violation with a fuse.
Disable agent memory entirely. Fraud pattern analysis requires cross-session context. Without it, the agent works blind on every interaction.

PCI-DSS compliance needs to start at the memory layer — before data reaches storage.

PCI-DSS requirements most AI memory solutions ignore

PCI-DSS Requirement	What it means for AI memory
Req 3: Protect stored cardholder data	PANs must be rendered unreadable at rest. Raw card numbers are non-compliant.
Req 7: Restrict access	Agents must not have unmediated access to raw cardholder data.
Req 10: Track and monitor access	Every memory read/write involving payment data must be logged.
Req 12: Information security policy	AI agent behavior involving cardholder data must be auditable.

How unmanaged AI memory creates PCI-DSS gaps

Cardholder data persisting beyond transaction scope

An agent handles a support call. The customer provides their card number. The agent embeds this in session context — which gets written to the memory store. The card number is now in a persistent database with no access logs.

PCI-DSS Requirement 3: PANs must not be stored after authorization is complete.

No audit trail for memory access

Requirement 10 requires logging all access to cardholder data. Standard AI memory retrieval provides API-level logs, not application-level logs showing which memories containing payment data were accessed.

Governed memory: a PCI-DSS-native approach

Automatic detection and tokenization of payment data

const response = await fetch("https://tracecontinuity.com/v1/memories", {
  method: "POST",
  headers: { "Authorization": "Bearer mnm_your_api_key" },
  body: JSON.stringify({
    agent: "fraud-review-assist",
    content: "Customer card ending 4532 reported two declined transactions. Pattern matches velocity check failure.",
    retention: "90d"
  })
});
// Stored: "Customer card ending [PAN_TOKEN_a3f7] reported two declined..."
// PAN detected + tokenized. Governance event logged.

Deterministic tokenization for cross-session context

const crypto = require("crypto");
function tokenizeFinancialId(value, type, secretKey) {
  const hmac = crypto.createHmac("sha256", secretKey);
  hmac.update(type + ":" + value);
  return "FIN_" + type + "_" + hmac.digest("hex").substring(0, 8);
}
// Same card last-four → same token across all sessions
// Full fraud pattern history without real PAN in storage

Retention policies tied to compliance requirements

// Fraud review — 90-day retention for dispute window
body: JSON.stringify({ agent: "fraud-review-assist", content: "...", retention: "90d" })

// Underwriting context — 1-year retention
body: JSON.stringify({ agent: "underwriting-assist", content: "...", retention: "365d" })

What this means for your QSA review

When a QSA reviews your AI agent deployment, they ask:

Where is cardholder data stored, and in what form?
What logging exists for access to cardholder data?
What is the data retention and deletion policy?

Trace Continuity answers all of these at the infrastructure level. Cardholder data is tokenized before storage, access logging is automatic, and retention is enforced with logged deletion events.

Originally published at tracecontinuity.com

AI Memory Governance for Defense Applications: Why ITAR and FedRAMP Start at the Memory Layer

Heath — Thu, 21 May 2026 10:19:11 +0000

Defense and government AI agents process ITAR-controlled data, CUI, and classified program information. Most memory solutions store it raw — no sovereignty controls, no compartmentalization, no audit trail. Here is how governed memory solves all three.

The problem: defense AI agents process data they cannot afford to expose

A defense contractor deploys an AI agent to assist with proposal analysis for a classified program. Three months later, a different team uses the same agent. If the agent still has access to the first program memory, they now have information that should be compartmentally separated.

ITAR, FedRAMP Moderate, and CMMC Level 2 all require controls that generic memory solutions weren't designed to provide.

Why generic memory stores fail for defense/government AI

No data sovereignty controls

ITAR governs how defense-relevant technical data can be stored. A shared vector store without program-level compartment isolation may create an export control violation by architecture, regardless of intent.

No compartmentalization for CUI programs

Standard AI memory has no concept of program-level isolation. All memories are accessible by API key — not by clearance level or program assignment.

No audit trail for compliance officers

CMMC Level 2 requires documenting and monitoring access to CUI. Most AI memory systems provide no application-level audit trail.

How governed memory solves this

Program-scoped compartmentalization

const response = await fetch("https://tracecontinuity.com/v1/memories", {
  method: "POST",
  headers: { "Authorization": "Bearer mnm_your_program_key" },
  body: JSON.stringify({
    agent: "proposal-analysis-assist",
    content: "Program ALPHA-2026: Radar subsystem gap identified.",
    retention: "730d",
    scope: "program:ALPHA-2026"
  })
});
// In a different program session — ALPHA-2026 memories are NOT retrieved
// Architecturally enforced, not convention

Deterministic tokenization for ITAR-controlled identifiers

const crypto = require("crypto");
function tokenizeProgramId(value, secretKey) {
  const hmac = crypto.createHmac("sha256", secretKey);
  hmac.update("PROGRAM:" + value.toUpperCase());
  return "PROG_TOKEN_" + hmac.digest("hex").substring(0, 8);
}
// Same program ID → same token, always. No raw ITAR data in storage.

Audit trail for CMMC Level 2 / FedRAMP Moderate

curl -X GET "https://tracecontinuity.com/v1/usage" \
  -H "Authorization: Bearer mnm_your_admin_key"
# Returns governance_events count, memories_pii_redacted, memories_denied

Compliance requirements mapped

Requirement	Governed memory provides
ITAR data handling	Technical identifiers tokenized before storage
CUI access control (CMMC L2)	Program-compartment isolation at infrastructure layer
FedRAMP Moderate logging	Immutable governance_events audit trail
Multi-program compartmentalization	Architecturally enforced, not convention

Originally published at tracecontinuity.com

Why AI Memory Without Governance Is a Ticking Time Bomb

Heath — Thu, 21 May 2026 10:02:12 +0000

AI memory governance is not optional — and right now, almost nobody has it

The AI industry has a memory problem. Not a technical one. A governance one.

Every week, another AI agent framework ships with some form of persistent memory. LangChain, CrewAI, AutoGen, OpenAI's Assistants API — they all have a memory story now. The pitch is always the same: your agents remember context across sessions, so they get smarter over time.

That part is real. The part nobody talks about: what those agents actually remember, how long they keep it, who can access it, and whether any of that is auditable.

The answer, almost universally, is nothing, forever, everyone, and no.

That is a ticking time bomb.

What "AI memory" actually looks like in production

When a developer integrates memory into an AI agent today, here is what typically happens:

The agent receives a conversation or processes a document.
Relevant facts are extracted and embedded into a vector store.
On future interactions, the agent retrieves those embeddings and incorporates them into its context.

Here is what nobody draws on the architecture diagram: what those embeddings contain.

If your agent helps a user with their healthcare claim, the memory system stores facts about their medical history. If your agent assists a wealth management client, it stores their portfolio, risk tolerance, and financial goals. If your agent handles employee performance reviews, it stores who said what about whom.

All of that data — personal, regulated, sensitive — is now sitting in a vector store. With no TTL. No access controls. No audit log. No deletion mechanism.

The three failure modes of uncontrolled AI memory

1. No retention policies — data lives forever

Legacy AI memory tools store memories with no expiration by default. A user who closes their account in year one has their data — potentially including SSNs, diagnoses, or financial identifiers — still sitting in the vector store in year three.

GDPR Article 17 gives EU citizens the right to erasure. CCPA gives California residents the right to delete. HIPAA has specific requirements for PHI retention and destruction. Most AI memory implementations today have no mechanism to honor any of these.

2. No access boundaries — any agent reads any memory

In a multi-agent system, which agents can access which memories? In most implementations: all of them. There is no scoping, no isolation, no permission model.

Your customer support agent can read the memories your internal HR agent stored. This is not a theoretical attack vector — it's the default state.

Governed AI memory enforces hard access boundaries at the infrastructure layer. An agent is scoped to the memories it's permitted to read. That boundary is enforced at query time, not by convention or developer discipline.

3. No audit trail — you can't prove what happened

With standard AI memory infrastructure, there is no log of who read what, when, and in what context. There is no immutable record of memory writes and deletions.

In regulated industries, this is not an inconvenience. It is a disqualifying condition. Healthcare orgs, financial services firms, and legal teams cannot deploy AI agents that operate with no audit trail.

The difference between "AI memory" and "governed AI memory"

This is not a nuance. It is an architectural distinction.

Standard AI memory: Store → retrieve → forget that anything is in there

Governed AI memory: Store → PII scan → redact → TTL-enforce → access-control → audit-log → retrieve with policy check → retain deletion proof

Every memory operation passes through the governance layer. Not as a middleware layer someone can bypass. As an architectural invariant.

This is what Trace Continuity is built for. The governance is not a feature you toggle on. It is the core primitive. You cannot store a memory through Trace Continuity without a retention policy being set. You cannot retrieve a memory without the access control check running. You cannot delete anything without the deletion being logged.

Who this matters for right now

Healthcare and healthtech: Any AI agent that processes patient data — intake bots, clinical decision support, care coordination tools — is touching PHI. An AI memory system with no governance is not HIPAA-compatible, full stop.
Financial services: Wealth management, lending, insurance — all have regulatory requirements around data handling, retention, and audit.
Legal and compliance teams: The data involved is privileged, sensitive, and often subject to specific retention schedules.
Enterprise SaaS with European customers: GDPR's right to erasure applies whenever you process EU personal data.

What the path forward looks like

Compliance doesn't require slowing down AI development. It requires building on the right infrastructure from the start.

The teams that will win in regulated AI adoption are the ones that can demonstrate, not just assert, that their systems handle sensitive data correctly. That means:

Retention policies enforced automatically, not manually
Access boundaries defined at the infrastructure layer, not in application code
Audit logs that are immutable and queryable
PII redaction that happens before storage, not after a breach

The alternative — bolting compliance onto an AI memory system that was never designed for it — is where the time bomb is.

Originally published at tracecontinuity.com