AI agents are becoming the new developer interface for data tools

At a glance

What this is: This is an interview-driven analysis of how AI agents are changing the interface for developer and data tools, with Tiger Data describing a shift from GUI-led interaction to API-, MCP-, and natural-language-led workflows.

Why it matters: IAM, IGA, PAM, and NHI teams need to account for agent-driven access paths that behave differently from human users, especially when tools, retrieval, and execution happen at machine speed.

By the numbers:

• customers are reporting 70% of their code comes from agents

Context

The core governance problem is that the developer interface is no longer only human-facing. When AI agents call APIs, chain tools, and retrieve context on demand, the old assumption that identity and access are mediated through a person sitting in a UI starts to break down.

In NHI terms, the relevant subject is not just the model but the access path it uses to act. The article points to a world where agent-facing systems need explicit control over tool affordances, retrieval scope, and execution boundaries because agents do not interact like users.

Tiger Data’s view is that this is already changing how developer productivity, database interaction, and internal tooling are designed. That makes the article more than a product story: it is a signal that identity governance is moving toward non-human, machine-paced workflows.

Key questions

Q: What breaks when AI agents are treated like standard human users?

A: You lose visibility into effective permissions, expected behaviour, and real blast radius. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.

Q: Why do agents need stricter tool boundaries than traditional apps?

A: Agents do not just consume a single workflow. They can chain tools, retrieve context, and take follow-on actions based on the result of earlier calls. That makes the tool set itself part of the privilege model. If the tool boundary is too broad, the agent can reach data or actions that were never necessary for the original task.

Q: How can security teams tell whether agent permissions are too broad?

A: The clearest signal is whether the agent can still complete its job after permissions are reduced in a sandbox. If the task keeps working after you remove broad access, the original entitlement was inflated. A second signal is the presence of unused permissions that persist across reviews and deployments.

Q: What should security teams do when agents can call databases and internal APIs?

A: Treat those calls as privileged machine actions and apply the same discipline you would use for high-risk service accounts: narrow scope, separate environments, logged execution, and explicit approval for sensitive writes. The point is to govern the access path at runtime, not just register the agent in inventory.

Technical breakdown

Why API-first interfaces change the access model for agents

An AI agent does not browse a system the way a human does. It executes tool calls, often in chains, against APIs, MCP servers, and other machine interfaces. That changes the identity problem from session-centric access to action-centric authorization, where each call can carry a different context, scope, and risk profile. The article’s point about agents not clicking but calling is important because it shifts the control surface from UI design to tool exposure. The practical question becomes how much capability an agent receives at the point of invocation, not how a person navigates a console.

Practical implication: govern agent access at the tool and API boundary, not only at the user-login boundary.

Why speed, parallelism, and retrieval matter to identity governance

Agents compress work into short bursts and often operate in parallel. They spin up sandboxes, retrieve context on demand, and expect fast boot, fork, and query behavior from the systems they touch. That matters for governance because traditional review and approval cadences assume access persists long enough to observe it. When access is exercised in short, bursty sequences, the control challenge moves toward issuance-time constraints, isolated execution environments, and telemetry that can reconstruct what happened after the fact. The article’s emphasis on retrieval also matters because context becomes part of the access path, not just the data layer.

Practical implication: align privilege, environment isolation, and observability to bursty agent execution rather than human session duration.

How MCP tools become affordances for non-human identity

MCP servers are being framed as affordances for agents, meaning they define what an agent can do and how easily it can do it. In identity terms, that is a capability design problem. The more affordances an agent has, the more important it becomes to separate useful delegation from unnecessary breadth. This is where over-scoping happens: the agent may be technically able to complete the task, but the same affordance set can also expose unrelated data, workflows, or write paths. The architecture question is not whether the agent can use the tool, but whether the tool set is constrained enough to prevent accidental scope creep.

Practical implication: treat MCP tool design as capability scoping and review it the same way you would privileged application access.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agents are becoming a new non-human identity tier, not just a new user interface. The article shows agents moving from novelty to routine execution, with code generation, API calls, and internal tools increasingly mediated by machine-driven workflows. That changes governance because the actor making the call is no longer a human with stable intent and predictable pacing. The implication is that identity programmes need to classify agent activity as a distinct access class rather than a UI variant.

Access review processes assume privileges persist long enough to be reviewed, and that assumption weakens under agentic execution. The article describes agents that call APIs, retrieve context, and finish work quickly, often with parallel activity and ephemeral environments. That behaviour means the certification model built for durable human entitlements can miss the actual risk window. The implication is that governance has to move toward issuance-time control and runtime evidence, not just periodic review.

MCP tool design is becoming a capability governance problem for non-human identity. Tiger Data’s description of MCP tools as affordances is a useful way to understand the new control surface. Every added affordance expands what the agent can attempt, chain, or retrieve, which makes overexposure a structural risk rather than a configuration nuisance. The implication is that tool boundaries now sit inside the identity model, not outside it.

AI coding agents are collapsing the distance between development speed and access control maturity. When agents can write, test, and commit code at machine pace, the surrounding identity controls are forced to keep up with a workflow that moves faster than human review loops. That does not make the agent autonomous in the full analytical sense, but it does make the access path machine-timed. The implication is that NHI governance must catch up to execution speed, not just to system inventory.

Agent affordance sprawl: the new risk is not merely that agents can act, but that they can be given too many chained capabilities at once. The article’s emphasis on useful but not confusing building blocks is a direct warning about capability breadth. Once agents can call multiple tools, query multiple data sources, and operate across sandboxes, the governance problem becomes one of constraining chained execution. The implication is that practitioners should treat tool exposure as a privilege architecture decision.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

The next governance gap is not whether AI agents can be integrated, but whether their tool affordances are being treated as privilege decisions. Teams that let agent capability sprawl grow unchecked will end up with machine identities that can do more than the programme can explain.

Agent affordance sprawl: the new control problem is excessive chained capability, where an agent can combine retrieval, execution, and write paths inside one workflow. That shifts the management question from user experience to privilege architecture, and it should force a re-check of MCP exposure, service account scoping, and runtime logging.

For practitioners

• Define agent-specific access boundaries Map each AI agent to the exact APIs, databases, and internal tools it can call, then remove any capability that is not required for a named workflow.
• Separate human entitlements from machine entitlements Create distinct governance paths for employee access and agent access so that certification, approval, and revocation logic does not blur the two identity types.
• Instrument agent activity for reconstruction Log tool selection, retrieved context, chained calls, and downstream writes so incident responders can reconstruct what the agent actually did.
• Constrain MCP capability sets Review MCP server affordances as privilege boundaries and remove high-risk actions such as broad query access, write paths, or cross-system chaining unless explicitly justified.

Key takeaways

• AI agents are moving developer and data tooling toward machine-paced access patterns that do not fit human-centric identity governance models.
• The governing risk is not just speed, but capability breadth, because chained tool use and broad retrieval rights can outgrow existing privilege controls.
• Practitioners should treat agent interfaces, MCP tools, and internal APIs as part of the identity perimeter and govern them accordingly.

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.
• Tool chaining: Tool chaining is the practice of using one capability to unlock the next, such as searching for a secret, authenticating with it, and then using that access to reach another system. For AI agents, tool chaining is the mechanism that turns broad permissions into compound risk.
• Capability scoping: Capability scoping is the practice of limiting what a tool or agent can read, modify, execute, or reach. In MCP governance, it is the control that turns a broad approval into a narrow one by separating informational access from command, network, and secret-bearing actions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.