Notifications
Clear all
Topic starter
21/08/2026 4:49 pm
TL;DR: Agent interfaces remain unsettled because filesystem access, API wrapping, and database-backed memory each trade reasoning efficiency for abstraction cost, according to Arize. The bigger lesson is that interface design and deployment model are separate choices, and current agent stacks still rely on whatever the model already understands best.
NHIMG editorial — based on content published by Arize: AI Agent interfaces In 2026, Filesystem vs API vs Database (What Actually Works)
By the numbers:
- Letta benchmark results showed a filesystem-based agent scored 74% on memory tasks by storing conversation histories in files.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
- Only 44% of organisations have implemented policies to govern AI agents, despite 92% agreeing that such governance is critical to enterprise security.
Questions worth separating out
Q: How should security teams govern AI agents that use service accounts and MCP tools?
A: Start with ownership, then add runtime attribution and containment.
Q: Why do AI agents complicate access governance more than ordinary automation?
A: AI agents complicate access governance because they can branch at runtime, wait on external services, and continue later with the same operational context.
Q: What breaks when agent access is treated as a developer convenience instead of a control surface?
A: Auditability breaks first, followed by ownership, then revocation.
Practitioner guidance
- Map every agent interface to a governed identity Define which agent, service account, or workload identity is allowed to use each file, API, or MCP path, and require ownership for every runtime access path.
- Separate interface abstraction from storage control Use virtual filesystems or runtime materialisation only when the backend storage, encryption, and retention controls are independently enforced and auditable.
- Constrain agent sessions with short-lived privilege Issue credentials for the minimum runtime window, revoke them automatically at session end, and prevent persistence of access beyond the task scope.
What's in the full article
Arize's full article covers the implementation detail this post intentionally leaves for the source:
- Arize's comparison of filesystem, API, and database-backed agent patterns in real product experiments.
- The practical reasoning behind Phoenix Insight's runtime materialisation approach for observability data.
- The internal debate on whether agent-to-agent communication can become a viable interface model at scale.
- Specific examples of how the team thinks about sandboxing, preprocessing, and query strategies.
👉 Read Arize's analysis of AI agent interfaces in 2026 →
AI agent interfaces: what works for agent-to-data access today?
Explore further
21/08/2026 5:08 pm
Interface choice is becoming an identity problem, not just an architecture problem. Once an agent can act through files, APIs, or MCP, the real question is who or what is authenticated at runtime and what scope follows that identity. In practice, the interface is the enforcement point where NHI governance either exists or is bypassed. Practitioners should treat every agent interface as a governed identity surface.
A question worth separating out:
Q: Who should own governance when AI agents cross identity, access, and application teams?
A: Ownership should sit with identity governance and security architecture, with application and platform teams accountable for implementation detail. Cross-functional ownership is necessary because agent identity touches federation, authorization, lifecycle, and audit evidence at the same time. If no single team owns the model, control gaps usually appear between systems rather than inside them.
👉 Read our full editorial: AI agent interfaces are still unresolved across files, APIs and databases
