From the NetApp edition of October 29, 2026
NetApp documents AI Data Engine known limitations: no single-to-multi-node migration, restricted proxy support, limited policy actions and narrow MCP search
NetApp (product documentation) · Strategic partner: AI data infrastructure and data management · Global
- Publisher
- NetApp Docs
- Original publication
- Documentation page dated 10/29/2026
- Source retrieved
- 2026-10-30
What happened
NetApp's own release notes list AIDE limitations: single-node and multi-node deployments are separate with no migration path; forward proxies cannot be TLS-inspecting, SOCKS, PAC/WPAD, or use NTLM, Kerberos or client-certificate authentication, and proxies are rejected on air-gapped installs; policy-triggered actions are limited to permanent deletion and email notification; tags cannot be deleted or renamed; and the governed AI access (MCP) interface searches only by name prefix, file type and owner, so size/date/folder queries may return incomplete answers.
Why it matters
Directly relevant to government and university networks, which commonly use TLS-inspecting or authenticated proxies and sometimes air-gapped enclaves. The limits also bound claims that AI agents can reliably query governed data through MCP today.
Evidence and measured results
Vendor documentation of unsupported functionality; no performance or outcome data.
Limitations and uncertainty
Vendor-authored; limitations may change between releases. Page states it may not apply to every product version.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-10-30; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Buyers may expect agentic data access and policy automation that the current release does not support.
- Stakeholders
- CISO / network security
- Records manager
- IT infrastructure lead
- AI program lead
- Discovery questions
- Does your network require TLS-inspecting or authenticated proxies?
- Do you need air-gapped deployment?
- Which automated retention actions are required?
- Value hypothesis
- Early qualification against documented limits reduces failed pilots and rework.
- Potential engagement
- Pre-deployment architecture fit review against the limitations list.
- Unsupported claims
- Complete MCP query coverage for agents
- Automated archive or tagging by policy
- Seamless scale-up from single to multi-node
Pre-sales engineering
Role takeaway
- Fit
- Fit only where proxy and network design match supported modes.
- Architecture and integration
- Single- or multi-node deployment chosen at install; forward proxy without TLS inspection; MCP access for AI clients.
- Prerequisites
- Proxy architecture review
- Deployment-size decision
- Tag taxonomy
- Constraints
- No single-to-multi-node migration
- No TLS-inspecting, SOCKS, PAC or NTLM/Kerberos proxies
- No proxy on air-gapped installs
- MCP search filters limited
- Security
- Permanent deletion policies require privileged approval and audit; proxy exceptions need security sign-off.
- Proof of value
- Test MCP queries by date/folder for completeness
- Validate install through the agency proxy
- Dry-run a deletion policy in a sandbox
Delivery
Role takeaway
- Work
- Incorporate documented limits into design, runbooks and user communications.
- Dependencies
- Network security team
- Records management
- NetApp release notes
- Ownership
- IT infrastructure owns the platform; records management owns policy definitions.
- Skills and adoption
- Admins trained on tag permanence and policy limits; users told which queries are reliable.
- Governance checkpoints
- Network design review
- Tag taxonomy approval
- Deletion policy approval
- Acceptance criteria
- Proposed: installation passes through approved network path without security exceptions beyond those signed off
- Proposed: documented list of reliable and unreliable MCP query types
- Proposed: zero unapproved automated deletions in pilot
- Risks
- Accidental permanent deletion
- Proxy incompatibility delaying deployment
- User trust loss from incomplete agent answers
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Choose single- vs multi-node at the start because there is no migration path; proxy design must match supported modes.
Governance
Who approves, reviews and stays accountable for outcomes?
Only deletion or notification can be automated by policy, so retention and archive workflows remain manual; permanent tag definitions require naming governance up front.
Security and privacy
What data, permissions and controls need testing?
Agencies whose security architecture requires TLS inspection or Kerberos/NTLM proxy authentication will need exceptions or alternative network paths; automated permanent deletion needs strong approval controls.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Staff skills in storage, identity and security operations are the main workforce dependency; no accessibility findings in the source.
Procurement
What should contracts, pricing and exit terms secure?
Buy against documented, testable requirements and acceptance tests rather than vendor maxima.
Operating model
Which teams own the service once it runs?
Ongoing operations sit with central or departmental IT storage teams; no change in operating model is reported by the source.
Publication history
- 2026-10-29NetApp · Issue 016 resources
Stable resource ID: netapp-aide-known-limitations-docs-20261029