AI agent interfaces are still unresolved across files, APIs and databases

At a glance

What this is: This article argues that AI agent interfaces are still experimental, and that filesystems, APIs, and databases each solve different parts of the problem rather than a single, clean abstraction.

Why it matters: It matters to IAM, NHI, and agentic AI teams because the interface an agent uses determines what it can see, what it can do, and how much governable identity and access control is actually possible.

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.

👉 Read Arize's analysis of AI agent interfaces in 2026

Context

AI agent interfaces matter because an agent can only act within the structure the environment gives it, whether that structure is files, APIs, or a database-backed abstraction. The article’s primary question is not whether one interface is universally superior, but why current systems keep falling back to the interface the model already understands best: filesystem-like primitives.

That matters for AI governance, because interface choice shapes both the technical control plane and the identity boundary around the agent. If an agent can read, write, query, or invoke tools without a clearly governed identity model, organisations end up with capability before control, which is a common pattern in early agent deployments.

For IAM and NHI teams, the important point is that an agent interface is not just a developer convenience. It is a policy surface, a privilege boundary, and a place where runtime access, session scope, and auditability either become visible or disappear into orchestration layers. That starting position is increasingly typical for emerging agent architectures.

Key questions

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. Security teams should know which human deployed the agent, which identity the agent uses, what tools it can invoke, and when to revoke access. If the agent can chain tool calls or spawn sub-agents, governance must cover those paths as well, not just the initial login.

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. That means privilege is not just granted at launch, it persists across a live session that must be observable, resumable, and attributable.

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. Teams can no longer tell which agent touched which data, what it changed, or when access should have expired. That turns debugging into forensic reconstruction and leaves compliance teams without a reliable evidence trail.

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.

Technical breakdown

Filesystem interfaces for agents: why they work first

Filesystem access often wins early because large language models have already seen files, directories, and shell patterns during pretraining. That reduces the token cost of teaching an agent how to interact with data. A filesystem also exposes state in a way the model can inspect with familiar operations such as cat, grep, and jq. The trade-off is that a filesystem is not inherently a governance model. Without explicit controls, it can become a convenient wrapper around poorly scoped access, weak audit trails, and unclear ownership of the data the agent touches.

Practical implication: treat filesystem-like access as an interface pattern, not a control strategy, and bind it to explicit session scope and audit logging.

APIs and MCP: abstraction does not equal governance

An API gives precision, but it also forces the agent to learn schemas, endpoints, and usage patterns. Model Context Protocol, or MCP, can reduce friction only if it meaningfully abstracts the underlying service. If an MCP server simply wraps a REST API, the complexity remains and the agent still spends context learning how to behave. The more durable design is not wrapper proliferation but a clearer separation between what the agent needs to ask and what the backend must enforce. That separation is where identity, authorization, and policy enforcement need to live.

Practical implication: do not assume an MCP wrapper makes agent access safe; verify that authorization, scope, and logging are enforced below the interface layer.

Virtual filesystems and runtime materialisation: storage and access are different problems

A virtual filesystem is a useful compromise when the agent should experience local-like data access without the organisation maintaining permanent local copies. Data can be materialised at runtime from a remote source, presented as files, and discarded after the session. This separates the interface layer from the storage layer, which is the right architectural move. But it does not solve the harder question of who the agent is, what it is allowed to do, and how that access is revoked or constrained during execution. Those remain identity and privilege problems, not storage problems.

Practical implication: pair runtime materialisation with short-lived credentials and a clear agent identity so temporary data exposure does not become persistent privilege.

Threat narrative

Attacker objective: The objective is to exploit the agent interface itself as a path to excessive data access, unintended action execution, or hidden privilege expansion.

1. Entry occurs when an agent is given access through files, APIs, or an MCP wrapper without a mature access boundary or identity model.
2. Escalation happens when the interface layer expands the agent’s effective privilege, letting it query, write, or chain actions beyond the original task scope.
3. Impact emerges when the agent can access sensitive data, perform unintended actions, or create audit gaps that make investigation and containment difficult.

NHI Mgmt Group analysis

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.

Filesystems look convenient because they compress the cognitive load of tool use, but they also compress accountability. The article shows why teams drift toward whatever the model already knows, yet that convenience can hide weak privilege boundaries and poor auditability. This is the same pattern seen in NHI sprawl, where utility arrives before governance. The right conclusion is to govern the access path, not to romanticise the interface.

Agent-to-agent communication may reduce interface friction, but it also multiplies trust relationships. A specialised agent that answers another agent’s questions still needs identity, authorization, and policy boundaries. Without those, teams merely replace one complex API with a distributed trust mesh. That is where OWASP Agentic AI Top 10 and NIST AI Risk Management Framework thinking becomes relevant for programme design.

Virtual filesystems are a useful pattern for separating storage from access, but they do not remove the need for short-lived privilege. Runtime materialisation can make data handling cleaner, yet the agent still needs controlled credentials, scoped permissions, and revocation. This is where the boundary between AI orchestration and NHI governance becomes operational. Practitioners should align the interface model with credential lifecycle controls, not bolt controls on afterwards.

Agent interface sprawl will create a new governance debt unless enterprises standardise on observable, revocable access patterns. As more teams experiment with files, APIs, sandboxes, and agent-to-agent flows, the estate becomes harder to inventory and control. That is a familiar identity security failure mode in a new form. The prudent response is to centralise policy, logging, and ownership before interface diversity becomes normalised.

What this signals

Agent interface design is now a governance signal. When teams normalise filesystem-like access for agents, they are often choosing convenience over durable identity controls, which is why agent programmes should be reviewed alongside privilege, auditability, and session scope rather than as a pure engineering experiment.

Interface drift: the steady expansion from one governed access pattern to many loosely managed ones will become a primary source of AI operational risk. Enterprises should expect more hidden trust chains unless they standardise how agent identities are issued, observed, and revoked.

The practical next step is to align AI orchestration with identity architecture, not to let orchestration define access policy. Teams that do this early will find it much easier to evaluate agent behaviour against NIST AI Risk Management Framework expectations and to preserve evidence when something goes wrong.

For practitioners

• 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.
• Instrument agent activity at the interface boundary Log file reads, API calls, tool invocations, and downstream actions so investigators can reconstruct what the agent actually touched and changed.

Key takeaways

• AI agent interfaces are still immature, and filesystem convenience often masks unresolved privilege and audit problems.
• The evidence points to a wider governance gap, with many organisations unable to track or control what their agents actually access.
• Practical control starts with runtime identity, scoped access, and revocation at the interface boundary, not with more wrapper layers.

Key terms

• Agent Interface: The layer an AI agent uses to read data, call tools, or change systems. It can be files, APIs, or a protocol such as MCP. In security terms, the interface is also an access boundary that determines what the agent can discover, do, and persist.
• Virtual Filesystem: A filesystem view created from remote or structured data rather than permanent local files. It lets an agent work with familiar file operations while the real storage stays elsewhere. This can simplify agent design, but it still requires strong identity and authorization controls.
• Runtime Materialisation: The process of presenting data to an agent only for the duration of a session, often by converting remote data into temporary files or structured objects. It reduces persistent storage burden, but it does not remove the need to govern access, audit actions, or revoke privileges.
• Agent-to-agent trust: The rules that determine whether one AI agent can authenticate, delegate, or share context with another. This is an identity problem as much as an integration problem, because uncontrolled trust propagation can create hidden access paths and make accountability harder to prove.

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.

👉 Arize's full post covers the filesystem, API, and database trade-offs behind its agent interface experiments.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, identity lifecycle, and secrets management. It helps identity and security practitioners translate runtime access into enforceable control.