AI agents are becoming the new developer interface for data tools

At a glance

What this is: This is a WorkOS interview with Tiger Data’s CEO about how AI agents are changing the developer interface and the technical shape of data tooling.

Why it matters: It matters because agent-driven workflows change how teams should think about access, tool design, and control boundaries across NHI, autonomous systems, and human-led platforms.

By the numbers:

• Customers are reporting 70% of their code comes from agents.
• 60% daily adoption within three weeks.

👉 Read WorkOS's interview with Tiger Data on AI agents as the new developer interface

Context

AI agents change the developer interface from human navigation to machine-initiated API calls, which means identity and access controls have to be evaluated around action scope rather than screen flow. In practice, that shifts the problem from user experience to machine behaviour, especially where agents can chain tools, retrieve context on demand, and act in parallel.

For IAM and NHI teams, the important question is not whether agents are useful. It is whether the current governance model can describe, constrain, and audit an actor that does not click through a UI, does not remember state the same way a human does, and can create many more requests than a person would in the same task window.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do AI agents create a different access problem from human developers?

A: AI agents create a different access problem because they can parallelise work, retrieve context on demand, and initiate actions without the pauses that human workflows naturally create. That changes the control objective from managing interactive users to governing high-volume machine actions. Identity teams need to account for speed, chaining, and fan-out, not just login events.

Q: What breaks when an agent-facing tool set is too broad?

A: When an agent-facing tool set is too broad, the agent can combine capabilities in ways the governance model did not anticipate, which increases the blast radius of a single identity. Broad affordances also make it harder to explain why the agent needed every path it could call. The result is over-entitlement by design.

Q: How do IAM teams measure whether AI agent access is under control?

A: IAM teams should measure whether they can describe every agent action path, every context source, and every parallel execution pattern in audit terms. If reviewers cannot reconstruct what the agent could do and how much it could do at once, the programme is not yet governing the agent, only observing it. Auditability should include tool calls, retrievals, and downstream writes.

Technical breakdown

MCP tools as agent affordances

Tiger Data frames MCP server design as affordances for agents, meaning the tools expose what an AI system can do without forcing it through a human interface. That matters because agents do not need menus or screens. They need callable capabilities that can be combined in sequence, with enough structure to stay useful and enough restraint to avoid uncontrolled action sprawl. In identity terms, the tool boundary becomes part of the control boundary, which is a different design problem from a traditional app login flow.

Practical implication: define agent-facing tool sets as tightly scoped capabilities, then review each callable action as if it were an NHI permission grant.

Parallel execution changes database and identity load

Agents parallelise, create sandboxes, and experiment, so the access pattern is bursty rather than linear. A system designed for one user session at a time can be overwhelmed by agent-like concurrency, especially if every task triggers multiple API calls, retrieval requests, and environment forks. That changes the operational meaning of least privilege. It is no longer only about limiting what an identity can reach. It is also about limiting how much parallel work that identity can initiate before controls degrade or monitoring falls behind.

Practical implication: test identity and platform controls under agent-level concurrency, not human-user assumptions, before exposing production data or write paths.

Context retrieval is now part of the control surface

Tiger Data notes that agents do not remember in the human sense, they retrieve. That makes search and context loading operationally central, because the agent’s next action depends on what it can fetch at runtime. For security teams, this turns data discovery into an access-control issue as much as a usability issue. If retrieval is the mechanism by which the agent reconstructs intent, then search results, embedded context, and downstream API scopes all become part of the trust boundary.

Practical implication: classify retrieval paths, search indices, and context sources as privileged data-access surfaces, not just application features.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agents are pushing NHI governance from static entitlement thinking toward runtime capability control. Tiger Data’s description of agents that call APIs, chain tools, and work in parallel shows why human-session assumptions are no longer enough. The governance problem is no longer simply who has access, but what an identity can do once it starts composing actions across systems. Practitioners should treat agent toolsets as living permission surfaces, not fixed application menus.

Affordances for agents is a useful named concept because it describes where control must now sit. The article’s MCP framing shows that the tool boundary is the security boundary when the actor is non-human. If the tool set is too broad, the agent is effectively over-entitled before it even begins. If the tool set is too narrow, the system becomes unusable and teams shadow-provision workarounds. The implication is that IAM teams need to govern callable affordances, not only credentials.

Agent concurrency creates a different blast radius than human productivity tooling. Agents do not work one request at a time, and they can spin up sandboxes, retrieve context, and execute in parallel. That means access review processes designed around individual human activity will miss the speed and fan-out of machine-paced action. Practitioners should stop measuring only who can log in and start measuring how much work an identity can trigger at once.

Search and retrieval now sit inside the trust boundary for non-human identities. Tiger Data’s point that agents retrieve rather than remember means context access is not passive support, it is active decision input. That makes data visibility, indexing, and source selection governance issues, not just platform design choices. For identity teams, the practical conclusion is that context sources need the same scrutiny as other privileged NHI pathways.

The adoption numbers show that agent use is already crossing from experimentation into daily operational dependency. When internal tools reach broad daily use and customers report majority code generation by agents, governance lag becomes the real risk. This is not a future-state debate about AI readiness. It is a present-state problem of whether access, audit, and containment models can keep up with machine-paced work.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• AI systems learning and reproducing sensitive information patterns from codebases concerns 43% of security professionals, according to The State of Secrets in AppSec.
• For a broader view of how AI agents change identity assumptions, see Analysis of Claude Code Security for the agentic tooling angle.

What this signals

Affordances for agents: as more software shifts from UI interaction to callable capabilities, the programme question becomes whether every tool exposed to an agent is truly task-scoped. Teams should expect pressure to tighten tool catalogs, separate read and write paths, and audit retrieval sources as privileged inputs, not convenience features.

The operational signal is that agent adoption quickly creates hidden identity load. Once code generation, search, and internal workflow assistants become daily habits, governance has to handle far more machine-paced actions per identity than legacy access models were designed for. That is why access scope, context source governance, and auditability need to move together.

With 43% of security professionals already concerned that AI systems may learn and reproduce sensitive information patterns from codebases, per The State of Secrets in AppSec, data governance and identity governance can no longer be separated cleanly in agent-heavy environments.

For practitioners

• Map agent-facing affordances to explicit permissions Inventory every MCP tool, API call, and context source an agent can invoke, then treat each one as a distinct permission boundary with an owner and purpose.
• Test controls under agent-level concurrency Run load and abuse scenarios where a single identity initiates multiple parallel sandboxes, retrievals, and API actions so you can see where monitoring, throttling, or approval gates break down.
• Separate retrieval access from general application access Classify search indices, transcripts, Salesforce data, and other context sources as privileged inputs and restrict them by task scope rather than broad user convenience.
• Add auditability for chained agent actions Log the full sequence of tool calls, context fetches, and write operations so reviewers can reconstruct intent and fan-out after the session ends.

Key takeaways

• AI agents change the interface to data systems by turning tool exposure into the real security boundary.
• Machine-paced concurrency and runtime retrieval create governance gaps that human-centric IAM models do not describe well.
• Practitioners should inventory agent affordances, constrain parallel action paths, and audit context sources as privileged surfaces.

Key terms

• Agent Affordance: An agent affordance is a capability exposed to an AI system so it can act without a human interface. In practice, it is the callable boundary between the agent and the environment. For identity governance, the affordance is also a permission surface that must be scoped, audited, and constrained.
• Machine-paced Access: Machine-paced access is identity activity that occurs at software speed rather than human pacing. It often involves parallel calls, rapid retries, and chained actions within a single task window. That behaviour changes how least privilege, logging, and approval controls should be designed.
• Context Retrieval Surface: A context retrieval surface is any search, index, transcript, or data source an agent can query to reconstruct task context at runtime. It matters because the retrieved content influences the agent’s next action. Security teams should treat it as a privileged input path, not a passive convenience layer.
• Runtime Capability Control: Runtime capability control is the practice of governing what a non-human actor can do while it is operating, not only at provisioning time. It focuses on the actions, tool calls, and data paths available in the moment. This is increasingly necessary when AI agents compose work dynamically.

Deepen your knowledge

AI agent governance and NHI control boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agent-facing tools and runtime retrieval, it is worth exploring.

This post draws on content published by WorkOS: Tiger Data sees agents as the new developer interface. Read the original.