approaches to zero-trust access enforcement for AI agents interacting with enterprise APIs
Enterprises need four governance layers, not one tool, to secure AI agents accessing APIs.
Non-human identities now outnumber humans in the average enterprise 50 to 1, and the identity stack most companies run was built for the humans. That mismatch is the whole story. Fixing it takes four separate layers, not one clever tool: registering the identities in the first place, scoping their permissions to the task at hand, governing how protocols like MCP get handed out, and watching behavior at runtime because provisioning alone won't catch what an agent does after it's approved. Skip a layer and you haven't reduced the risk, you've just moved it somewhere you're not looking. Agents don't fail the way people do, either. They fail faster, quieter, and in volumes that make a quarterly access review about as useful as a smoke detector with the battery pulled.
Traditional IAM assumes a human logs in, does something predictable, and logs off. It assumes the access pattern holds still long enough to assign a role and walk away for six months. Agents wreck that assumption inside the first five minutes of real deployment. They chain API calls across systems, invoke tools mid-task based on whatever they just read, and act on goals they inferred rather than goals someone typed in step by step. A static service account issued at setup tells you nothing about what the agent is doing three calls later, and agents make it worse by spawning sub-agents, pulling in outside content mid-run, and occasionally widening their own scope without asking. One misconfigured agent can touch two dozen APIs before a human opens the dashboard. Machines don't wait for review cycles; why would they.
The scale problem has a deadline stapled to it. Gartner, cited by Okta in May 2026, projects the average Fortune 500 company will run more than 150,000 agents by 2028. Governance models sized for a few hundred service accounts don't stretch to cover that. They snap.
What zero-trust actually means when you're not trusting a person
John Kindervag's original zero-trust idea, later written into NIST 800-207, is not complicated: never extend implicit trust based on where a request came from. Applied to agents, that means every single API call gets checked, authorized, and verified, regardless of which system launched the agent or how official its name sounds on the org chart. The agent's registered identity tells you who it's supposed to be. It says nothing about what it's doing right now, in this session, with this data.
There's a small mercy buried in here for anyone who already did the work on human identity. Zero trust for agents is an extension of that program, not a rebuild from scratch. Per Portnox, May 2026, organizations that already applied least privilege and continuous verification to their workforce have most of the architecture sitting there already. They just have to point it at a population that didn't exist five years ago.
Three requirements hold this together, and most practitioners now agree on the order. Identity first: every agent gets a registered, inventoried identity tied to a human owner, no exceptions, "it's just a script running in a cron job" is not a defense. Least privilege second, scoped to the task, not handed out once at setup and left to rot. Runtime enforcement third, because policy has to hold while the agent is running, not just at the moment somebody clicked approve.
The Cloud Security Alliance's Agentic Trust Framework, published February 2026, turns this into a maturity model with tiered privilege levels. "Intern" agents get read-only access. Higher tiers earn broader permissions the way an actual new hire earns them, through a track record, not a title change. It's a decent reference point for sketching your own tiers. What it doesn't tell you, and what no framework document tells you, is how these three requirements actually get wired into a working enterprise system with real APIs and real deadlines.
The identity sprawl nobody's counting is the root of the problem
Here's a number that should ruin your afternoon. About 80% of non-human identities run outside any governance framework at all, according to SANS Institute research from June 2026. Four out of five machine identities have no registered owner, no expiration date, no scope review, ever. That's not a future risk. That's the state of the network you're sitting on right now.
Three kinds of credentials are doing the heavy lifting out there, and each comes with its own particular headache. Static API keys have no expiration, no scope limits, and no link back to a human who's accountable for them; they're the hardest thing in the stack to govern and still, somehow, the most common credential type in production. OAuth 2.0 client credentials grants are a step up: they map onto service principal setups that already exist inside Entra ID and Okta, and scope can be constrained at the moment of issuance. Workload identity tokens issued through cloud OIDC get closest to zero-trust by default: short-lived, tied to the exact execution context of the job, gone the second the job finishes.
Static role assignments, the RBAC model most enterprises still run on, were built for access patterns that don't move. Agents don't have access patterns that hold still. That's the entire point of building one. The better model is task-scoped grants: permissions issued for one specific operation against one specific resource, valid only as long as that operation takes. AWS IAM condition keys, Azure ABAC expressions, and OPA-based policy engines all support some version of this, though the granularity swings wildly depending on which one you pick.
Platform vendors are building toward it, at different speeds and from different angles. Microsoft's Entra Agent ID, generally available since April 2026, extends Conditional Access, Identity Protection, and Privileged Identity Management to cover non-human identities, defining reusable "agent identity blueprints" that spell out owner, sponsor, access envelope, and audit behavior up front. It's aimed squarely at the ad-hoc service-principal sprawl that's been accumulating for a decade. Okta's Identity Assertion Authorization Grant works differently: an orchestrator submits a user token plus a requested scope and gets back a short-lived, single-use token carrying both the human principal and the agent's own workload identity. The API on the receiving end knows exactly who the human is and which agent is acting on their behalf.
Neither one closes the full gap by itself. Both handle issuance well, meaning who gets what, at what scope, for how long. Neither ingests the application-layer telemetry needed to check whether what the agent is doing right now still matches what it was issued at the start. That check needs its own layer entirely.
Scoping agents that hop across a dozen APIs mid-task
The failure mode here is blunt: agents holding more access than the job in front of them requires. Okta's May 2026 data puts a number on it. Ninety percent of enterprise agents are over-permissioned, and 53% have access to sensitive information. Multiply those together and you get a blast-radius problem. When an agent misbehaves or gets compromised, the damage doesn't stay contained to the task it was built for.
Least privilege is a genuinely harder engineering problem for agents than it ever was for people. A human's job stays roughly fixed week to week; an agent's required permissions shift by task, by step within a task, and by whichever tool it decides to chain next. An agent reading a Salesforce record might legitimately need to call a second, unrelated API halfway through a workflow. That second call needs its own scope check, tied to the task at hand, rather than inheriting trust from the first grant just because the agent asked nicely and seemed like it knew what it was doing.
Design the permission envelope around the task, not the agent as a standing entity. Use time-bounded tokens that expire when the task finishes, not tokens sitting on a rolling 90-day rotation because that's what the IAM team has always done for service accounts. Build explicit human-approval checkpoints for anything touching sensitive data tiers or reaching outside the agent's own sandbox; the CSA's "intern" tier is a reasonable template for where to draw that line. Log everything, including which tools got invoked and which APIs got called, in what order, because without that log a scope audit is just guessing with extra paperwork.
Enforcement has to live at the API layer, and there's no clever way around this. An agent's prompt instructions can be talked into almost anything by whoever slips a malicious instruction in front of the model first. A policy engine sitting at the API gate can't be talked into anything; it either matches the rule or it doesn't, and it doesn't care how convincingly the request was phrased.
Worth saying plainly for anyone building this today: the tooling for dynamic, task-scoped grant issuance is still young. Most teams doing this well are stitching it together themselves. OPA policies here, short-lived OAuth tokens there, custom middleware gluing the seams, rather than buying one product off a shelf that does the whole job.
MCP turned into an API surface almost overnight, and governance hasn't caught up
Anthropic released the Model Context Protocol in November 2024 as a standard way for AI models to connect to external tools and data. It caught on almost embarrassingly fast: by December 2025 it was seeing 97 million monthly SDK downloads, backing from every major AI lab, and governance as a Linux Foundation project. That's a genuine win for standardization. It's also, in a roundabout way, exactly the problem.
MCP made it trivial for any agent runtime to connect to any MCP server. What the protocol doesn't do is enforce authentication, authorization, or audit logging; that's left to whoever builds the implementation, and quality swings wildly from one server to the next. Security researchers flagged prompt injection risks, tool-permission combinations that open a path to data exfiltration, and lookalike tools that quietly swap in for trusted ones, all published back in April 2025. Connect agents straight to MCP servers at scale with no layer in between, and you lose any centralized view of which agents are calling which servers, with what credentials, or what data came back. Shared service accounts make it worse: one compromised agent inherits the blast radius of every other agent riding the same account.
A proper MCP gateway closes most of that. It handles centralized authentication and authorization, checking identity via JWT, OAuth 2.0 with PKCE, or OIDC before a request ever reaches the MCP server itself. It propagates identity downstream so requests execute as the actual authenticated user; if that user can't delete a repository, neither can any agent claiming to act for them. It logs every tool invocation and data retrieval at the protocol layer, timestamped and traceable to a specific caller. And it handles traffic management: rate limits, routing, and the ability to yank a misbehaving server offline without touching a line of agent code.
MCP's own OAuth 2.1 support, revised in March 2025 and refined again that June, is solid on paper. The problem is implementation quality across individual MCP servers in the wild, which varies enough that a gateway enforcing the spec uniformly is the only way to trust it consistently. A few approaches worth knowing if you're evaluating this space: Kong's AI Gateway 3.12, released October 2025, ships an MCP Proxy plugin aligned with the June 2025 OAuth spec plus MCP-specific Prometheus metrics, a natural fit if Kong already sits in your API layer. Obot's MCP Gateway offers a centralized catalog of internal and external MCP servers with team-level access control. Docker MCP takes a different angle, using container-native isolation and cryptographic image signing for real supply-chain security, but stops there; no RBAC, no audit logging, no centralized governance. Some teams are taking a control-plane approach, governing MCP distribution across the workforce through a single layer that enforces access policy and logs usage, rather than hand-configuring each server individually.
Gartner's emerging-practices guidance frames this the right way: treat MCP the way you'd treat any API surface, gateway-first. The governance model isn't new here. Only the protocol is.
The control that catches what looked fine on paper
Here's a failure mode no provisioning system catches: an agent set up correctly, scoped correctly, approved correctly, that then does something strange anyway. Maybe it got hit with a prompt injection. Maybe it chained tools in a sequence nobody anticipated, or its task drifted a little further from the original job than anyone noticed at the time. Static policy has nothing useful to say about any of this, because static policy only checks whether the agent is allowed to do a thing, never whether the thing it's doing, in this order, at this volume, actually looks right.
An agent can stay entirely inside its registered permissions and still leak data, simply by stringing together individually harmless calls in an unusual pattern. Prompt injection is worse in a specific way: it happens when adversarial content sitting in a retrieved document or an API response quietly redirects what the agent is trying to do, and the identity layer can't see any of it. Catching that requires inspection at the content and behavior level, a different job entirely, one that identity and access management was never designed to do.
Continuous verification means building a baseline for what normal looks like for this specific agent doing this specific kind of work: typical call frequency, the usual API surface it touches, expected data volume, the sequence it tends to follow. Then watch for deviation in real time, so a departure from baseline triggers something immediately, an alert, a step-down in privilege, a human escalation, instead of sitting quietly in a log until next quarter's audit finds it. It also means inspecting content in transit at the API boundary itself: catching PII, catching secrets, catching prompt-injection signals as they cross the line, not after the fact in a postmortem nobody wanted to write.
Cisco's March 2026 poll puts a number on the hesitation this creates. Eighty-five percent of organizations are actively adopting agents, but only 5% report broad production deployment. That gap is a confidence problem as much as anything: teams stall out in pilot purgatory because they have no way to trust what an agent will do once it's live, and no amount of provisioning rigor fixes that on its own.
Every single action doesn't need a human sign-off before it fires; do that and you've killed the entire productivity case for using agents in the first place. The real design question is which action types, which data tiers, which anomaly signals earn an escalation gate, and which ones run without one. That's a policy call security teams need to make before agents go live at scale, not something you patch in after the incident report.
Shadow AI is the crack that swallows every other control
None of the layers above matter much if employees are routing around all of them, and that's exactly what's happening. Roughly three out of four organizations now consider shadow AI a definite or probable challenge heading into 2026, a sharp jump from the year before, according to Cycode. Shadow AI agents behave differently than shadow SaaS ever did. When an agent calls enterprise APIs under a personal account or an unregistered team credential, it skips past every identity and access control the organization spent a year building. There's no audit trail, because the agent was never inside the system that generates one. And there's a real chance that agent is shipping enterprise data straight to a third-party vendor's infrastructure the organization has zero contractual say over.
Banning it doesn't work. Pretending otherwise just wastes a security team's Tuesday. If people don't have a sanctioned tool that does what they need, they'll go find one that isn't sanctioned, quietly, on a personal API key, by lunchtime.
The fix that actually holds is a governed distribution model, not a stricter memo. Shadow AI shrinks when employees get access to approved, governed tools that do the job they were already trying to do unofficially. That takes a real distribution layer: a catalog of approved agents, MCP servers, and skills that teams can pull from themselves, inside the policy instead of around it. None of that works, though, until someone actually finds what's already running ungoverned inside the network. You can't govern something you haven't counted.
Security controls that make the safe path slower than the shadow path don't get followed. They get worked around, at machine speed, by agents nobody in the building ever registered.
