Enterprise AI Agent Best Practices – Persistence, Recovery, DR and Governance of Context and State

A few weeks ago I wrote AI Needs Persistence – Who Manages the Databases Behind Your AI Agents’ Memory? The point of that article was that agents need to remember, memory means persistence, and persistence means databases that someone has to own. The most common follow-up question I’ve had since then is a fair one: “OK, so what do we actually do about it?” This article is my answer. It’s a practical set of best practices for persisting, protecting, recovering and governing the context and state of enterprise AI agents, and how you can implement them on Nutanix.

I’m going to focus on four things: persistence of agent context and state, backup and recovery of it, disaster recovery and business continuity, and governance and role-based access control over that context. None of these are new disciplines. What’s new is that the data is being created by software that acts on its own, at machine speed, on behalf of people, and that changes how you apply them.

Disclosure: I work for Nutanix as a Principal Solutions Architect. This is my personal blog, and the opinions expressed here are my own and not necessarily those of my employer.

What Do We Mean by Agent Context and State?

Before you can protect something you have to know what it is and where it lives. When I sit down with customers and map out a production agent, the state almost always falls into six buckets:

• Short-term (thread) state. The conversation so far, the plan, intermediate results, pending tool calls and any human approvals the agent is waiting on. In LangGraph this is what a checkpointer saves at every step, and it is what lets an agent resume after a pod restart or a human-in-the-loop pause.
• Long-term memory. Facts, preferences, summaries and lessons learned that persist across sessions, often stored as embeddings for similarity search.
• Knowledge corpus. The source documents, chunks and ingestion manifests behind retrieval augmented generation (RAG).
• Tool and workflow state. The side effects the agent has had on other systems: the ticket it raised, the refund it issued, the record it updated. This state lives outside your AI platform, which is exactly why it causes trouble during recovery. Consistency between systems is a factor for recovery.
• Configuration. System prompts, tool and MCP server definitions, model versions, guardrail policies and API keys. If you can’t reproduce these, you can’t reproduce the agent’s behaviour.
• Audit and decision trail. Who asked, which agent acted, what it retrieved, which model version answered, which tool it called and what changed.

Figure 1 shows how these map onto a typical enterprise agent stack. The thing I want you to notice is that every layer below the agent runtime holds state, and every one of those stores needs its own protection, recovery objective and access policy. Integration of the protection of the entire solution end to end is critical!

Best Practices for Persisting Agent State

Most of these come from watching pilots make the jump to production and finding out the hard way what they forgot.

1. Never run production on in-memory state. The LangGraph documentation is blunt about this: the in-memory saver is for debugging and testing, and anything held in RAM is lost when the process restarts. Use a durable checkpointer, such as the PostgreSQL one, from day one so that the pilot and production architectures are the same.
2. Keep the agent runtime stateless and the state services stateful. Agent pods should be disposable. Push thread state, memory and artefacts into managed databases and storage services that have their own HA, backup and DR. This is the same twelve-factor principle we’ve applied to web apps for years.
3. Make side effects idempotent. If an agent resumes from a checkpoint taken just before a tool call, it will make that call again. Give every side-effecting tool call an idempotency key derived from the thread and step, and have the tool or the MCP server reject duplicates. This one matters more than any other during failover.
4. Record provenance and versions with every memory entry. Store the source, timestamp, owner, tenant, data classification, the model version that produced it and the embedding model version alongside each entry. Without this you can’t filter by permission, you can’t find poisoned entries, and you can’t rebuild embeddings consistently. Pin model versions too; the Nutanix Enterprise AI API reference makes the same recommendation, because model behaviour changes between versions.
5. Consolidate on as few engines as you sensibly can. PostgreSQL with pgvector can hold checkpoints, long-term memory and vectors in one ACID-compliant engine, with one backup and recovery story and the ability to join vectors with relational permission data. Purpose-built vector databases have their place at very large scale, but every additional engine is another thing to patch, back up, replicate and secure.
6. Encrypt sensitive state. Encrypt at rest at the infrastructure layer, and consider application-level encryption for checkpoints that hold regulated data. LangGraph, for example, provides an encrypted serialiser for checkpoint contents.
7. Plan for growth and expiry. Checkpoints accumulate with every step of every thread. Set retention for thread state, time-to-live for unverified memories, and capacity monitoring for the stores, before the first production incident tells you to.

How Nutanix Helps with Persistence

• Nutanix Database Service (NDB) for PostgreSQL provisions PostgreSQL Community Edition or EDB Postgres Advanced Server from standard, automated profiles, including one-click HA, and deploys NDB-verified extensions such as pgvector. That gives every new agent team a production-grade checkpoint and memory database without a hand-built snowflake.
• Nutanix Kubernetes Platform (NKP) runs the agent runtime and, where teams prefer, in-cluster databases and vector stores, with persistent storage through CSI and integration with NDB and Nutanix Unified Storage.
• Nutanix Enterprise AI (NAI) provides private inference for LLMs, embedding and reranker models on Kubernetes, which makes it straightforward to pin and record the exact model and embedding versions your memory depends on.
• Nutanix Unified Storage (Files, Objects and Volumes) holds the knowledge corpus, artefacts and logs on the same platform, managed the same way.
• Data-at-rest encryption in AOS is AES-256 software encryption using a FIPS 140-2 Level 1 compliant encryption module, with a built-in key manager or your existing enterprise KMS.

Best Practices for Backup and Recovery of Agent Context

Here’s where I see the biggest gap between how teams think about agent memory and how they think about every other production database. A nightly dump of the memory database is not a recovery strategy for an agent that writes state every few seconds.

1. Separate what is irreplaceable from what is rebuildable. Conversation history, approvals, decisions and curated memories are irreplaceable. Embeddings and caches can be regenerated, but only if you kept the source corpus and the exact embedding model version, and only if you can afford the time and GPU capacity it takes. Re-embedding millions of chunks is part of your RTO, so measure it.
2. Use point-in-time recovery, not just snapshots. Combine regular snapshots with continuous transaction log archiving, as described in the PostgreSQL documentation on continuous archiving and PITR, so you can restore to any second, not just to last night.
3. Keep enough history to roll back poisoned memory. The OWASP Top 10 for Agentic Applications 2026 lists Memory and Context Poisoning (ASI06) as a top risk: corrupted memory persists and steers later sessions, other users and other agents. Detection is rarely instant, so your retention has to cover the time it takes to notice, and you need a way to restore to a known-good point or surgically remove the bad entries.
4. Keep at least one immutable copy. Ransomware operators target backups first. Write backup copies and audit logs to object storage with WORM or object lock, administered from a separate security domain.
5. Protect the whole application, not just volumes. A restore of the data without the matching deployment manifests, secrets references, prompts and tool definitions gives you a database and no agent.
6. Test restores and use the clones. A restore you haven’t tested is a hope. Clones of production memory are also invaluable for forensic investigation of suspected poisoning, and for evaluating a new model or prompt against real context without touching production.

How Nutanix Helps with Backup and Recovery

• NDB Time Machine combines scheduled database snapshots with continuous archiving of transaction logs, so you can restore or clone to a specific snapshot or a point in time. Nutanix describes this in Enterprise-Grade PostgreSQL Operations with NDB and in Managing Database Backups at Scale with NDB and Objects, which covers using Nutanix Objects as a durable archive target. Thin clones make restore testing and forensics cheap.
• Nutanix Data Services for Kubernetes (NDK) protects stateful Kubernetes applications as a unit, capturing both application configuration and data, with policy-based snapshot scheduling and restore through kubectl and the Kubernetes API.
• Nutanix Objects supports WORM policies, object versioning and encryption. Its WORM capability has been assessed by Cohasset Associates against SEC 17a-4(f), FINRA 4511(c) and CFTC 1.31(c)-(d) (assessment report), which makes it a good home for immutable backup copies and audit logs.
• Nutanix Data Lens adds ransomware detection and blocking, audit trails and one-click recovery from the last good snapshot for Nutanix Files and Objects, which is where your corpus and artefacts are likely to live.

Disaster Recovery and Business Continuity for Agents

Once agents are embedded in business processes, losing them is a business continuity event, not an IT inconvenience. If an agent approves claims, handles customer service or runs operations runbooks, the business needs to know how long it can be without it and how much of its memory it can afford to lose.

Tier Agent State by RPO and RTO

Not all agent state is equal, and paying for zero RPO on everything is wasteful. Define recovery objectives per tier of state, as in Figure 2. In-flight workflow state and approvals for transactional agents may justify synchronous replication. Long-term memory may be fine with a few minutes of RPO. The knowledge corpus can often tolerate hours. Audit logs should never be lost and should be immutable. Embeddings and caches can be rebuilt, as long as you’ve accounted for the time it takes.

Recover to a Consistent Point

This is the part people miss. An agent’s state is spread across several stores, and if you restore each one to its own latest recovery point, they won’t agree with each other. Memory may reference a document that isn’t in the restored corpus, or a checkpoint may say a tool call hasn’t happened when the downstream system says it has. Figure 3 shows the approach I recommend:

• Put the stores an agent depends on in the same consistency group or protection policy where you can, so they share recovery points.
• Where you can’t, restore to a common point in time, using log-based PITR on the databases to line them up.
• Use the audit log, which should be continuously replicated, to reconcile anything that happened after the recovery point, and rely on idempotency keys to stop agents repeating side effects.
• Re-embed any gaps, validate, and only then reopen the agent to users.

As I wrote many years ago in Hardware Fails, Software Has Bugs, People Make Mistakes – Usually You Get All at Once!, real incidents rarely arrive one at a time. Design for a failover that happens in the middle of a long-running agent task, during an upgrade, with a model endpoint that’s also unavailable.

Don’t Forget the Dependencies

• Inference capacity at the DR site. GPUs are often the constraint. Decide ahead of time whether you’ll run the same models at reduced capacity, a smaller model, or route to an approved external provider, and test the quality of the answers you get.
• Gateway configuration, API keys, MCP servers and identity. If agents can’t authenticate or reach their tools at the recovery site, recovered memory doesn’t help.
• Keys and secrets. Encrypted backups are useless without the keys. Make sure your KMS is available at, or replicated to, the recovery site.
• Test it. Run non-disruptive test failovers on a schedule and measure the actual RPO and RTO, including re-embedding and reconciliation time.

How Nutanix Helps with DR and Business Continuity

• Nutanix Disaster Recovery offers Sync, NearSync and Async replication for RPOs from zero to 24 hours, and AHV Metro for zero RPO with near-zero RTO. Protection policies apply RPO, retention and replication targets by category, and recovery plans act as run books, with staged power-on so the database tier starts before the agent tier, network mapping and non-disruptive test failover. The Nutanix Cloud Bible DR section explains the constructs in detail.
• NDK extends this to Kubernetes, with application-level protection, asynchronous replication with configurable RPO and RTO, and synchronous replication for file and block storage across sites for zero data loss.
• NDB for PostgreSQL provides automated DR pairing, continuous replication monitoring and one-click failover for the memory and checkpoint databases.
• Nutanix Cloud Clusters (NC2) runs the same Nutanix Cloud Platform on AWS, Azure, Google Cloud and OVHcloud. That gives you a cloud DR site with the same operating model, policies and access controls as on-premises, without refactoring the agent stack.

Governance, Auditability and Role-Based Access Control

Agent memory is a concentration of sensitive data. It holds fragments of customer conversations, internal documents and business decisions, retrieved from systems that each had their own access controls. The risk is that the agent becomes a way around those controls. The guiding principle I use is simple: an agent acting on behalf of a user should never be able to see or do more than that user could, or more than the agent’s own role allows, whichever is less. Figure 4 shows where to enforce that.

1. Give agents real identities and use delegated access. Avoid one all-powerful service account shared by every agent. Use short-lived, scoped tokens that carry both the user and the agent identity. The MCP authorisation specification builds on OAuth 2.1 for exactly this, and the MCP security best practices explain why token passthrough and confused deputy problems must be avoided.
2. Isolate memory per user and per tenant. Use separate schemas, namespaces or databases for tenants, and enforce isolation in the database, not just in application code. PostgreSQL row-level security is a good way to make sure a query can only ever return a user’s own memories.
3. Make retrieval permission-aware. OWASP LLM08:2025 Vector and Embedding Weaknesses describes how weak access partitioning in vector stores leaks data across users and tenants. Carry source ACLs and classifications into vector metadata at ingestion, filter before results reach the model, and resynchronise when permissions change at the source.
4. Validate what gets written to memory. Treat memory as untrusted data, never as instructions or permissions. Decide in code, not in the model, what is allowed to be persisted. Record provenance and quarantine anything suspicious.
5. Apply least privilege to tools. Separate read and write tools, scope each agent to the tools it needs, rate-limit and require human approval for high-impact actions. OWASP calls the failure mode Excessive Agency (LLM06:2025).
6. Audit everything, immutably. Log who asked, which agent acted, the model version, what was retrieved, the tools called and what changed. Store the trail where agents and their administrators can’t alter it. The EU AI Act requires high-risk AI systems to support automatic logging (Article 12), and requires providers and deployers to keep those logs for at least six months unless other law says otherwise (Article 19 and Article 26). I think it’s highly probable that the time to store audit logs will be extended to many years in regulated industries such as Financial Services.
7. Design retention and deletion end to end. A deletion request has to reach the memory database, the vector index, caches, derived summaries and, according to your policy, backups. If you can’t find every copy of a person’s data in agent memory, you can’t delete it.
8. Anchor it in a management framework. The NIST AI Risk Management Framework and its Generative AI Profile (NIST AI 600-1) give you a vocabulary for govern, map, measure and manage, and ISO/IEC 42001 gives you a certifiable AI management system. Map the controls above into whichever your organisation has adopted, so agent memory is in scope for audits rather than an afterthought.

How Nutanix Helps with Governance and RBAC

• Nutanix Agent Gateway in Nutanix Enterprise AI is a single control point between agents, models and MCP servers. It applies access control policies and tool-level filtering to MCP servers, records every MCP request in an audit trail, and enforces token-based rate limits. With NAI 2.8, MCP server management is generally available and you can assign tool capabilities such as read-only or write to specific users or API keys.
• NAI RBAC includes predefined roles and a custom role builder with a catalogue of more than 30 permissions across users, models, endpoints, API keys and observability, plus API keys scoped to specific endpoints and searchable audit logs.
• Prism Central RBAC uses authorisation policies made up of roles, scopes (for example, by category) and local or Active Directory users and groups, so platform, database and AI teams only manage what they own.
• Flow Network Security provides category-based micro-segmentation across VMs and, through Flow CNI, Kubernetes pods and services. Only the agent runtime should be able to reach its memory database, and only the gateway should reach the model endpoints.
• Security baseline. AOS continuously checks STIG-based security baselines and resets drift automatically through SCMA, as explained in the Nutanix Cloud Bible security section. Combined with data-at-rest encryption and the built-in KMS, this covers the infrastructure layer.
• Immutability and visibility. Nutanix Objects with WORM for audit logs, and Data Lens audit trails and anomaly detection for the unstructured data the agents retrieve from.
• Sovereignty. Running inference, memory and audit on infrastructure you control, on-premises or on NC2 in a region you choose, makes data residency an explicit design decision rather than an accident.

Protecting the Vault: Secrets and Credentials Used by Agents

Agents are credential-hungry. Every model endpoint, MCP server, tool, database and SaaS API needs an API key, token or password, and a single compromised agent can expose all of them. Worse, an LLM can be talked into revealing anything it can see, which is why sensitive information disclosure is on the OWASP LLM Top 10. The vault that holds those credentials becomes one of the most critical components in the whole agent platform.

• Use a proper secrets manager. Keep credentials in a vault such as HashiCorp Vault or your cloud provider’s secrets manager, not in code, container images, environment files or Git. In Kubernetes, sync them in with the External Secrets Operator and encrypt Secrets at rest in etcd with a KMS provider. The Kubernetes good practices for Secrets and the OWASP Secrets Management Cheat Sheet are good checklists.
• Never put secrets in prompts, context or memory. The model should never see a credential. Tools and MCP servers should fetch and use credentials on the agent’s behalf, and memory writes, checkpoints and logs should be scanned and redacted so a token pasted into a conversation doesn’t end up persisted and retrievable forever.
• Prefer short-lived, dynamic credentials. Issue per-agent, per-task credentials with a short time to live rather than long-lived shared keys. Vault’s database secrets engine, for example, generates unique database credentials on demand that are revoked automatically when their lease expires.
• Rotate, and prove you can. Automate rotation of every static secret that remains, and test it, because the first rotation of a key that has never been rotated is usually an outage.
• Back up and replicate the vault itself. If the vault is lost, every agent stops, and encrypted backups can’t be read without the keys. Protect the vault’s storage and its unseal or recovery keys, replicate it to the DR site (Vault Enterprise, for example, supports disaster recovery replication), and include it in the recovery plan ahead of the agents that depend on it.
• Have a break-glass procedure. Define how authorised people get emergency access when the IdP or the vault is unavailable: sealed credentials held under dual control, used only in a declared incident, fully logged and rotated straight afterwards.

How Nutanix Helps Protect Secrets

• NKP includes the External Secrets Operator. It was pre-installed on the management cluster from NKP 2.16 and added to the NKP catalog as a core application in 2.17, so agent workloads can pull credentials from HashiCorp Vault, cloud secrets managers and others rather than storing them in manifests.
• NAI and Agent Gateway keep model and MCP access behind API keys that are scoped to specific endpoints and can be revoked centrally.
• Data-at-rest encryption with built-in or external KMS protects the volumes that hold the vault, the databases and the backups. Make sure key management is part of your DR design.
• Flow Network Security can ring-fence the vault so only approved workloads and administrators can reach it, and Prism Central RBAC can scope who is allowed to operate on the VMs it runs on. That matters, because a clone of a vault is a copy of every secret in it.
• Nutanix Disaster Recovery can protect and replicate a VM-based vault alongside the agents, with recovery plan stages that bring the vault up before the workloads that need it.

Identity and Access Management Policies for Agents

Secrets are only half of it. The other half is who, or what, is allowed to do what. Agents are a new and fast-growing class of non-human identity, and the OWASP Non-Human Identities Top 10 is a sobering read about what happens when service accounts and API keys sprawl without ownership. My recommendations:

• Give every agent its own workload identity. One identity per agent (and ideally per deployment), registered in your IdP or workload identity system, with a named human owner. Standards such as SPIFFE provide cryptographic workload identities without static secrets.
• Least privilege by default. Start each agent with no access and grant only the tools, data and scopes its task needs. Separate read and write, and production and non-production.
• Use OAuth scopes and on-behalf-of delegation. When an agent acts for a user, it should present a token that represents both, with narrowed scopes, using token exchange (RFC 8693) or the patterns in the MCP authorisation spec, rather than a privileged service account that can see everything.
• Write policy as code. Express access rules in a policy engine such as Open Policy Agent or Kyverno, keep them in Git, review them like code and test them in the pipeline. That makes access decisions consistent across agents and auditable after the fact.
• Separate duties. The people who build an agent shouldn’t be the only ones who can approve its production permissions, change its audit configuration or restore its memory. The same goes for the agent itself: an agent should never be able to grant itself more access.
• Review access regularly. Run periodic access reviews for agent identities just as you do for people. Disable agents nobody owns, remove scopes that haven’t been used, and expire credentials automatically.
• Integrate with your enterprise IdP and SSO. Human access to the platform, the gateway, Kubernetes and the databases should go through the same IdP, MFA and joiner-mover-leaver processes as everything else. This is core to a zero trust architecture.

How Nutanix Helps with Identity and Access Management

• Prism Central IAM supports local users, Active Directory, and SAML 2.0 identity providers. The Nutanix Security Guide lists ADFS, Microsoft Entra ID, Okta, PingOne, Shibboleth and Keycloak as tested SAML IdPs. Authorisation policies combine custom roles with scopes such as clusters or categories, which suits separation of duties between platform, database, security and AI teams.
• NKP uses Dex to federate authentication to LDAP, SAML, OIDC and GitHub providers, for example single sign-on with Microsoft Entra ID, and maps IdP groups to Kubernetes RBAC role bindings.
• NAI and Agent Gateway provide predefined and custom roles, endpoint-scoped API keys and per-user or per-key tool permissions for MCP servers, with an audit log of every MCP request. That gives you a single place to enforce and evidence what each agent is allowed to call.

Non-Production Environments and Testing Everything

None of the practices above count until they’ve been tested, and you can’t test safely in production. Agents also change more often than traditional applications: new prompts, new tools, new model versions and new data arrive weekly. That makes proper non-production environments and continuous testing essential, not optional.

Provision Non-Production Environments That Mirror Production

• Have dev, test and staging environments with the same architecture as production: the same gateway, runtime, databases, storage, network policies, identity integration and protection policies, just smaller. Differences between environments are where surprises come from.
• Don’t use raw production data. Agent memory and conversation history are full of personal and sensitive information. Use masked or synthetic data in non-production, and treat any environment that does hold real data as production for security purposes.
• Use clones to make realistic test copies fast. Thin clones from snapshots let you stand up a realistic copy of a memory database or corpus in minutes, test against it and throw it away.
• Keep environments isolated. Non-production agents must not be able to call production tools, write to production memory or use production credentials. Separate identities, vault paths, network segments and API keys for each environment.

Test and Validate Every Aspect

• Backup restore tests. Regularly restore the memory, checkpoint and corpus stores into an isolated environment and time it against your RTO.
• DR failover tests. Run full test failovers of the agent stack, including the vault, identity, gateway and inference capacity, not just the databases.
• Consistency checks of restored state. After every restore or failover test, validate integrity end to end: references between memory, corpus and checkpoints resolve, checksums match, row counts and audit sequences line up, and agents resume threads without repeating side effects.
• Agent evaluation and regression tests. Maintain evaluation datasets and run them on every change of prompt, tool, model or embedding version, so you catch quality regressions before users do. Frameworks such as LangSmith evaluations help automate this.
• Security testing and red teaming. Test for prompt injection, memory poisoning, data leakage across tenants and excessive agency. The OWASP GenAI Red Teaming Guide and MITRE ATLAS are good starting points.
• Access control tests. Prove that user A’s agent can’t retrieve user B’s memory, that a read-only agent can’t write, that non-production can’t reach production, and that revoked credentials actually stop working. Automate these tests alongside your policy as code.
• Chaos testing. Deliberately kill agent pods, fail database nodes, cut off the model endpoint and expire tokens mid-task, following the principles of chaos engineering, and confirm agents resume cleanly from their checkpoints.

How Nutanix Helps with Non-Production and Testing

• NDB copy data management creates space-efficient clones of production databases to a snapshot or point in time, with one-click or scheduled clone refresh, automatic expiry of clones, and pre- and post-clone scripts that can run data masking before developers get access, as described in Reimagining Database Cloning with NDB.
• Nutanix Disaster Recovery recovery plans support non-disruptive test failovers into isolated test networks, so you can validate the DR run book, including staged startup and network mapping, without touching production.
• NDK protects application configuration and data together in one snapshot, so a containerised agent stack can be restored as a unit.
• NKP fleet management and GitOps make it straightforward to keep dev, test and staging clusters consistent with production while isolating them from each other.
• Flow Network Security and VPCs isolate non-production from production, and Prism Central RBAC lets development teams self-serve in their own environments without production rights.

Summary Checklist

Here’s the short version you can take into your next architecture review.

Best practice	Why it matters	Nutanix capabilities that help
Durable checkpointer, stateless agent runtime	Agents resume after restarts, upgrades and approvals	NDB for PostgreSQL, NKP
Consolidate memory on few engines (e.g. PostgreSQL + pgvector)	One backup, DR and security model	NDB profiles and verified pgvector extension
Provenance and pinned model and embedding versions	Reproducibility, rebuildable embeddings, poisoning forensics	NAI private inference, Objects versioning
Idempotent side effects	No duplicate actions after resume or failover	Application and tool design; audit trail for reconciliation
Point-in-time recovery for memory	Roll back to before corruption or poisoning	NDB Time Machine, clones
Immutable backups and audit logs	Ransomware resilience, compliance evidence	Objects WORM / object lock, Data Lens
Application-consistent protection	Restore the agent, not just its data	NDK, protection policies by category
RPO and RTO tiers per type of state	Spend on protection where it matters	Sync, NearSync, Async, AHV Metro
Consistent recovery point and run books	Stores agree with each other after recovery	Nutanix DR recovery plans, NDB PITR
DR site with inference, identity and keys	Recovered memory is useless without them	NC2 on AWS, Azure, Google Cloud, OVHcloud; KMS
Regular non-disruptive DR tests	Prove the RPO and RTO you’ve promised	Test failover in recovery plans, NDB and NDK clones
Agent identity and delegated, scoped access	No super-user agents, no confused deputies	Agent Gateway, NAI scoped API keys
Per-user and per-tenant memory isolation	Prevent cross-tenant leakage	PostgreSQL RLS on NDB, Flow microsegmentation
Permission-aware retrieval	The model never sees what the user can’t	Application design on NDB / Files / Objects metadata
Least-privilege tools and human approval	Limit excessive agency	Agent Gateway MCP read/write controls, rate limits
Immutable, complete audit trail	EU AI Act logging, investigations	Agent Gateway audit logs, NAI audit, Objects WORM
Hardened, encrypted, segmented platform	Defence in depth under the agents	SCMA / STIG, data-at-rest encryption, Prism Central RBAC
End-to-end protection design per agent	Every store passes its own backup but the agent still can’t be recovered	Nutanix DR protection policies by category, NDB, NDK
Integrity checks across stores	Detect dangling references, corruption and tampering	Objects WORM and versioning, NDB clones for validation
Secrets in a vault, never in prompts or memory	Agents and LLMs can leak anything they can see	External Secrets Operator on NKP, data-at-rest encryption and KMS
Short-lived, dynamic credentials and rotation	Limit the blast radius of a stolen credential	NKP External Secrets Operator with your vault; NAI scoped, revocable API keys
Back up, replicate and ring-fence the vault, plus break-glass	Losing the vault stops every agent	Nutanix DR, NDK, Flow Network Security, Prism Central RBAC
Workload identity and owner for every agent	No anonymous, unowned non-human identities	NAI roles and API keys, NKP RBAC
OAuth scopes and on-behalf-of delegation	Agent never exceeds the user’s rights	Agent Gateway per-user and per-key MCP tool permissions
Policy as code and separation of duties	Consistent, reviewable, auditable access decisions	Prism Central custom roles and scopes
Enterprise IdP, SSO and access reviews	Same joiner-mover-leaver controls as people	Prism Central IAM (Active Directory, SAML 2.0 IdPs), NKP Dex (LDAP, SAML, OIDC)
Production-like non-prod with masked or synthetic data	Realistic testing without exposing real data	NDB clones, refresh and post-clone masking scripts
Restore, DR failover and consistency tests	Prove RPO, RTO and integrity	Nutanix DR test failover, NDB clones, NDK restores
Agent evaluation, red teaming, access control and chaos tests	Catch regressions and security gaps before users do	Isolated test environments on NKP with Flow segmentation

Final Word

In AI Needs Persistence I argued that agent memory is production data. The practices above are what treating it that way looks like: know what state you have, persist it durably, protect it so you can roll back, recover it consistently across sites, keep its secrets in a vault, govern who and what can see it, and test all of it in environments that mirror production. None of this is exotic. It’s the same discipline we already apply to business critical databases, applied to a new and fast-growing class of data.

The advantage of doing it on one platform is that the agents, their models, their memory and their audit trail share the same protection policies, DR run books, access controls and operating model, on-premises and in the cloud. That’s a lot easier to govern than hundreds of agents each with their own way of remembering.

How are you protecting and governing the memory behind your agents today? Have you tested recovering one yet? I’d love to hear your feedback. Please share it in the comments below, or directly with me on X at @vcdxnz001.

---

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster. Copyright © 2012 – 2026 – IT Solutions 2000 Ltd and Michael Webster. All rights reserved. Not to be reproduced for commercial purposes without written permission.