By Art Poghosyan, CEO & Co-Founder of Britive
AI agents are spreading through enterprise environments faster than anything identity teams have dealt with before, and most IAM (Identity and Access Management) programs weren’t built for what they’re now being asked to handle. A single agentic workflow can spin up dozens of short-lived sub-agents in minutes, each calling APIs, pulling data from warehouses, and handing off work to other agents through MCP (model context protocol) servers and tool integrations. Traditional IAM and PAM platforms were designed for humans on predictable schedules and service accounts that behave the same way every time. AI agents break both assumptions at once.
What’s left behind is an identity surface most security teams can’t see, let alone govern or shut down on demand. Static API keys, over-permissioned service accounts, and standing IAM roles, agents are quietly inheriting all of it at machine speed. When an agent is compromised, manipulated through prompt injection, or just goes off the rails, the damage is bounded only by whatever permissions that identity holds. Usually far more than the task ever called for.
Why This Breaks The Old Playbook
Every AI agent is technically a non-human identity, and the basics of NHI (non-human identities) governance still apply; ownership, lifecycle, credentials issued only when needed. But agents have a property traditional NHIs never had: they’re unpredictable. A regular service account is deterministic, calling the same endpoints the same way every time. Give an agent the same prompt twice, though, and it might take a completely different path, use different tools, follow a different order, and yield a different outcome, because its behavior is shaped on the fly by whatever input it’s reacting to, including untrusted content from documents or the web.
That unpredictability gets worse with delegation. Agent A calls Agent B, which queries a database through an MCP server: whose authority is actually being exercised? Without a way to verify that chain, audit logs turn into guesswork. And most agent frameworks still default to long-lived API keys and OAuth tokens that rarely rotate and rarely carry any sense of purpose or scope.
Not All Agents Carry The Same Risk
Governance programs need to draw a line between two kinds of agents, because they fail differently.
The first acts on a human’s explicit instruction and runs inside that person’s context, a Copilot-style assistant. The danger comes from rights inflation: the agent inherits the user’s broad permissions on an always-on basis, and when something goes wrong, it’s hard to trace the action back to who authorized it. The fix is binding agent identity to user context, so access reflects “this agent, acting for this person” rather than the agent’s standing permissions alone.
The second runs more like a service, background workflows, MCP-speaking tool-users, automations with no human in the loop. The risk here isn’t attribution, it’s credential hygiene: secrets baked into code or config that become catastrophic the moment the agent or its environment is breached. The fix is to treat the agent as a workload identity in its own right, sitting behind a broker that issues short-lived, just-in-time credentials, so it never holds a permanent secret.
A Five-Phase Path Forward
None of this requires tearing out your existing IAM stack, but it does take a deliberate sequence.
Start with discovery: inventory every agent framework, MCP server, and non-human identity across cloud, SaaS, and endpoint environments. Most organizations are off by an order of magnitude here, and shadow MCP servers and agents only widen the gap.
From there, govern and classify what you’ve found: accountable owners, sensitivity tiers, and a real review process before any new capability gets granted.
Next, enforce just-in-time access with zero standing privileges. Static, vaulted secrets get replaced with credentials minted only for the duration of a single authorized task, whether that’s a cloud call or a tool invocation through MCP.
Then comes runtime detection and containment. Build behavioral baselines per agent and let the identity layer act as the kill switch: when behavior drifts from what was declared, credentials get pulled in seconds rather than waiting on a human to notice.
Finally, optimize and scale. Treat this as an operating model, not a project. Tune policy against real usage, extend it across business units, and bake agent identity requirements into how software actually gets built.
The industry is converging on this shape. The Center for Internet Security has published companion guides applying its Critical Security Controls to both AI agents and MCP, and recent research describes the emerging architecture in similar terms: a centralized broker that shifts the core question from who a human is to why an agent is acting right now.
This isn’t a problem enterprises get to plan for later, it’s already running in production. A deliberate program costs far less than inheriting an ungoverned identity surface and cleaning it up after something goes wrong. Teams that start with discovery and prove the model out on one pilot will be in a much better spot than those waiting for an incident to force their hand.
##
ABOUT THE AUTHOR
Art Poghosyan is an entrepreneur and InfoSec expert with over 20 years in cybersecurity. He excels in building high-performance teams and fostering collaborative, accountable cultures. Prior to founding Britive, a pioneering cloud privileged access management (CPAM) platform, he co-founded Advancive, an Identity and Access Management (IAM) consulting firm acquired by Optiv in 2016. Art is a mentor, speaker, and contributor to industry events and (ISC)2 CISSP-ISSAP exam development, deeply committed to advancing cloud security innovations.
