Making AI Agents Cheaper & Better with IAM Best Practices

Making AI Agents Cheaper & Better with IAM Best Practices
This is not AI art. From an art installation in London by the Czech artist David Černý called "London Booster".

How’s that for a sensationalist headline?!? But I promise I’m going to back it up. 

In my “Arguing about agent identity” talk at Identiverse a week ago, I asked everyone to use the AI urgency to achieve IAM goals; more specifically NHI goals. The board level pushing to “AI ALL THE THINGS!” is powerful. There are budgets being set by it. My claim was that you will find ways to connect that directly to your own priorities if you’re in identity or security. 

Catching up on my reading & watching after the conference, I came across the Nate B Jones posts on Vercel’s agent optimization efforts. It’s proof that IAM best practices can be directly connected to making agents better and even cheaper. We’re going to break it down.

First, let’s review what Vercel did. One case is reactive, the other is proactive. The reactive one is the d0 agent back in December which Vercel talked about. This fed some of the “MCP is dead” talk, but that’s not where I want to focus. The short version of what happened is they took ~17 specialized tools (schema lookup, query validation, join-path finder, syntax validator, etc.) and collapsed them to essentially one: execute arbitrary bash in a sandbox (grep, cat, ls). That led to the agent being 3.5× faster (274.8s to 77.4s), using 37% fewer tokens (~102k to ~61k), and taking 42% fewer steps (~12 to ~7).

Let’s be clear that this isn’t a 100% fit for IAM best practice. The “bash all the things” approach in the d0 agent comes at a potentially serious price from a security point of view. If it’s done exactly as Vercel describes with a sandbox (containerization), then it can be limited properly. But an agent that replaces a bunch of scoped MCP tools with unfettered bash scripting on improperly limited system scopes will not be a win for you. But having learned the lesson about being careful with tools, what did they do next?

The second was a sales/"lead" agent where engineers shadowed a top SDR for six weeks, documented the workflow, and built an agent. The 10-person inbound team became one overseer. Scary human replacement issues aside, you can view this as the proactive version of the tool trimming story. They only gave this agent precisely what the SDR actually used in their real workflow. They had already learned that fewer tools meant more performance and applied that here proactively. This was originally covered by Business Insider, but you can find the non-paywall version syndicated free on AOL.

Nate B. uses this to talk about how efficiency in granting tools to agents leads to efficiency that has real performance effects. He also makes some excellent points about having a maintenance mindset when building. But that’s not where I want you to focus. 

The connection to the IAM should be clear. Vercel’s learning exposes a very useful architectural idea: tool bloat in AI agents degrades performance the exact same way entitlement bloat slows down human workflows. Whether you solve it via radical tool consolidation (like the d0 sandbox) or strict least-privilege profiling (like the SDR agent), reducing the agent's choices drives down cost and latency. 

Look at it longer, and you’ll see the pattern for secure agent architecture: dynamic tool hydration. Instead of giving agents standing access to an entire catalog of 17 tools, we should use IAM principles to inject only the tightly scoped tools needed for the specific task at hand, at the exact moment they are needed. That is the agent tool equivalent of Just-In-Time (JIT) access. If you can insert yourself and these IAM priorities into this conversation at the time when these design decisions are being made, then you can also make sure more agents look and perform like the SDR agent and also make sure lessons like the d0 agent don’t lose the security benefits by skipping the guardrails. 

This is EXACTLY the kind of push you can use to connect “AI all the things” directly to your IAM priorities. People want AI agents. They want them to run well. And they want them to be as cheap as possible (of course). You can offer them a way to find agents that are not on the bad path by having them give you the tools and time you need to root out standing access and over privileged systems. 

The lesson is pretty cool: blast radius correlates strongly with lack of focus. Lack of focus leads agents to behave badly and expensively. You have the power to help bring focus using IAM. And you can even help find agents likely to behave poorly using IAM as a leading indicator. The bad IAM practices smell the same as the bad tool use practices. 

The practical advice from the talk remains the same: inventory now. Inventory deeply enough to sniff out these IAM problems. Connect your priorities to the urgency (and budgets) of these AI agents everyone from the board on down wants right now. Give them what they want by getting what you need. Happy hunting.