Securing AI Agent Access to Internal APIs and SaaS Systems

Figma logged a 75% jump in MCP write usage in a single quarter. Atlassian saw MCP call volume rise sharply while web and mobile traffic barely moved, showing agents, not humans, now doing the work. Salesforce reported the same pattern, a marked climb in agentic use of its apps through MCP and API calls. These numbers came out of enterprise earnings calls in August 2026, not a vendor forecast, making them a report of what already happened.

What's actually running through those pipes has changed too. AI agents now read databases, modify CRM records, trigger cloud workflows, and carry out multistep tasks with no human approving each step. That's a second, parallel channel into enterprise systems running at agent speed, and most security stacks were never built to see or govern it. The gap shows in a single number: only 34% of organizations apply the same security controls to AI agents that they apply to human employees. Datadog reports that MCP tool calls have surged dramatically since Q4 2025, quadrupling quarter over quarter in Q1 2026, and quadrupling again in Q2 2026, now more than 22x versus Q4 2025.

Shadow AI and the governance gap agents create

Agents aren't landing in clean, well-governed environments, but ones that already can't account for AI tools people use without asking anyone. Nearly every organization reports unsanctioned AI use somewhere inside it, with only 37% having a formal governance policy on the books to catch it. That's close to a total gap between adoption and oversight. It's close to a total one.

Picture the ordinary version of this. A developer spins up a local MCP server connecting an AI coding assistant to a staging database or production API; the productivity gain is immediate and visible, and it creates a security hole that is neither.

Security teams don't know which MCP servers are running across the organization. They don't know what credentials those servers hold, what systems those credentials reach, or what data moves through them. Credentials often sit as plain, hardcoded tokens in a local config file, and the agent acts with whatever access was granted at setup, never revisited or trimmed.

Call it shadow IT with a new engine under the hood. It's shadow IT reconfigured: the unauthorized software can read production databases, modify enterprise SaaS records, and execute cloud console commands, deciding nondeterministically at runtime what to do with its access. Only 30% of organizations have reached governance maturity level three or higher for strategy, governance, and agentic AI controls, so most are scaling agents on outdated governance foundations.

Traditional API gateways failing when agents are the client

The first instinct, understandably, is to reach for what's already there. Route MCP traffic through the existing API gateway, which has handled system-to-system calls for a decade, but it falls short fast.

API gateways were built for a deterministic world, where System A calls System B along a pre-mapped route using a pre-fixed credential. Everything about the design assumes the call pattern is known before the call happens. Agents break every part of that assumption. Agents choose which tool to invoke dynamically based on user input, chain calls across systems in real time with each step shaped by the last, run asynchronously and adjust mid-task, and can take real, consequential action (exporting data, writing records, deleting things) as the downstream effect of a seemingly harmless prompt.

A different question is being asked at the gate. A traditional API gateway asks whether a client is authorized to hit an endpoint. An MCP gateway must ask whether this specific agent is authorized for this specific tool call, with these parameters, on this user's behalf, right now. Static authorization can't answer a question with that many moving, real-time variables.

The threat model shifts along with it. Nobody's worried about SQL injection or a DDoS flood here. The live risks (tool poisoning, context leakage, indirect prompt injection) exploit the agent's judgment rather than a server's uptime. And the audit trail has to change shape. An HTTP log of request and response metadata leaves security teams without the agent's full trajectory, its intent, the tools it picked, and which attempts got blocked. None of that is a gap you patch. It's a different gateway, built for a different kind of client.

Treating AI agents as first-class identities, not service accounts

Human authentication was built around a slower, more predictable actor. Passwords, MFA, session timeouts, all assume a person who logs in, works, and logs out. Agents don't log out. They work across systems, invoke tools without a human in the loop, and operate at machine speed around the clock, making the human-centric model structurally wrong for the job.

The fix that's emerging isn't a patch on that model. It's a different category of identity entirely, one where each agent gets registered, owned, and disabled on its own terms, not inherited from a pipeline or borrowed from a developer's personal token. By September 2026, every major identity provider had shipped a version: Microsoft Entra's Agent ID, Google Cloud IAM's Agent Identity, Ping Identity's Identity for AI, and Okta's Agent SSO and Okta for AI Agents, the latter generally available since April 30, 2026.

Okta's architecture, laid out at Oktane in September 2026, is the most fully documented version of the pattern, standing in for where the whole category is headed. Agent SSO, generally available since August 24, 2026 and folded into core Okta SSO at no extra cost, registers each agent in Universal Directory as a first-class citizen sitting right next to the human employees. Behind it, Agent Gateway acts as the enforcement point while the identity platform decides, so an agent's scope is checked continuously rather than settled once at setup. Agent Gateway isolates downstream credentials within Okta and brokers a fresh, short-lived credential for each call, so that a compromised agent process does not yield a reusable secret.

None of this requires ripping out what's already in place. Microsoft Entra ID or Ping can remain the system of record for human identity while agent identity security is layered on top, making this an addition rather than a forced migration. The design principle to carry forward is a dual-identity check in which every agent request carries both its own identity and the human user's, and allowed tools are the overlap of both permission sets, never the agent's grant alone. That single idea is what the next layer of controls has to operationalize.

Short-lived tokens and the ID-JAG standard reducing credential risk

Identity solves who an agent is. It doesn't solve what happens to the credential once the agent starts using it. Hardcoding a static service token into a local agent config is an open vulnerability at enterprise scale; neither a user's laptop nor an LLM's context window should ever hold a raw production credential.

The fix is to stop handing the secret over. A well-built gateway intercepts the tool call as it's happening and injects the authorized credential at runtime, so the agent gets to act with the authority it's been given without ever holding the underlying secret in its hands. It can't leak what it was never given.

The standard forming around this exchange is called ID-JAG. It is an IETF Internet-Draft under an active OAuth working group, at revision 04 as of May 21, 2026, and not yet a ratified RFC. The mechanics are simpler than the acronym suggests. An agent exchanges the ID token from its identity provider, via the RFC 8693 token exchange standard, for a short-lived assertion scoped to one downstream resource. It then redeems that assertion at that resource's own authorization server, under RFC 7523. The identity provider is a broker in the middle of that handshake, nothing more, and the resource server keeps full independent control over its own tokens the entire time.

The ground under this keeps shifting, which is its own kind of warning. Between March, June, and July 2026 alone, the MCP specification gained major changes, including stateless sessions, Enterprise-Managed Authorization, a swap of Dynamic Client Registration for Client ID Metadata Documents, and server-to-client change notifications. An organization building governance on top of MCP needs infrastructure that can track that pace.

Okta's Cross App Access protocol, first announced June 23, 2025, gives a sense of how far real integration has already gotten. By its June 23, 2026 ecosystem expansion, more than 25 early adopters had signed on. The requesting side includes Anthropic's Claude, Cursor, VS Code, Docker, and Zoom. The resource side includes Asana, Atlassian, Canva, Datadog, Figma, Glean, Granola, Linear, Serval, Slack, Supabase, and Zoom. Okta made it available to workforce customers starting in August 2026, with Auth0 early access landing at the end of July. That's not a pilot program anymore.

What role-based access control for agents requires in practice

An agent with a clean, registered identity can still be handed way too much power. Identity answers who's knocking. It says nothing about which rooms they're allowed into once through the door (that's the job of role-based access control: shrinking the blast radius of whatever goes wrong).

In practice, that means a handful of things have to be true at once. Policy must be enforced at the individual tool-call level, since system-level approval says nothing about whether a specific call with specific parameters should run. Agents should never hold standing access to anything downstream, brokered through OAuth instead so the access exists only for the moment it's needed. And all of it needs to plug into the security infrastructure that already exists rather than standing up a second, parallel policy system nobody fully trusts.

Zero trust applies literally here: every request is authenticated on its own, nothing is assumed fine by default, controls stay granular, and verification runs continuously rather than stopping at registration. Lasso Security's triple-gate pattern illustrates layered enforcement: one gate at the AI layer filters prompts and detects PII, one at the MCP layer checks tool authorization and validates parameters, one at the API layer handles rate limiting and authentication, each able to block a request independently. Revocation has to be just as fast on the way out. Cutting off an agent must be a single action, not a three-day ticket, since incident response at enterprise speed can't wait for paperwork.

None of it works, though, without the unglamorous step that usually gets skipped first: discovery. Before enforcing a role, organizations need an actual inventory of every agent running, where it's deployed, its source codebase, and its human owner. Okta's own framework for this puts the stages in a strict order for a reason: Discovery, then Scope, then Runtime Monitoring, then Active Containment. Skipping Discovery means everything built on top enforces rules against a population you can't see. MintMCP's on-premise infrastructure guide sets out the enterprise agent gateway requirements for RBAC.

The five technical pillars of an enterprise MCP gateway

An MCP gateway is the purpose-built equivalent of an API gateway for the agentic ecosystem, understanding tool calls, resource requests, and invocation context.

Five things have to be true for that gateway to actually hold. First, zero-secret exposure: credentials get injected at the moment of use and never sit in the agent's hands or in the LLM's context window. Second, tool-level authorization, checking not just whether an agent can reach a system but whether this exact call, with these exact parameters, on this user's behalf, right now, is allowed. Third, threat detection built into the request path itself (catching prompt injection, blocking PII, stopping tool poisoning) rather than bolted on as an afterthought. Fourth, a full audit trail capturing the agent's real-time trajectory (which tool ran, what it touched, in what order, on whose behalf) instead of a thin, meaningless HTTP metadata log. Fifth, cost and usage observability down to a single agent or team, with budget guardrails preventing runaway loops from becoming runaway bills, and model routing that weighs cost, latency, and data residency.

The difference this makes is structural. Without a gateway, every AI application connects straight to scattered MCP servers, each with its own auth scheme and log format, with no single point where policy gets decided. With one, every bit of agent-to-tool traffic passes through a single governed layer that can actually be audited end to end. Deployment specifics matter enormously: on-premise and air-gapped requirements demand solutions that genuinely work within VPCs and hybrid architectures while maintaining governance, and not every gateway supports this equally, so regulatory needs, data sovereignty, and existing infrastructure should drive that choice.

Building all of this, though, runs straight into a staffing wall. The architecture for governing agents is arriving on schedule, but the people needed to run it are not. AI security concerns have grown sharply, yet 57% of organizations face a significant capacity gap in security and risk management, per the Linux Foundation's State of Tech Talent Report.