Okta partners with MintMCP to govern how agents connect to enterprise apps. Most AI agents reach enterprise applications the same way: a static API key or a long-lived token pasted into a config file. That credential rarely rotates, carries broad scope, and gives no clean way to tell which agent used it or to cut off access. As teams move from a handful of experiments to agents acting on behalf of real users, IT and security need a way to scope, audit, and revoke agent access without slowing every project down. The exposure is already showing up: a survey of more than 900 practitioners found that 88% of organizations have seen confirmed or suspected AI agent security incidents, and IBM reports that 97% of organizations hit by an AI-related breach lacked proper AI access controls. Today, Okta and MintMCP are officially partnering on Cross App Access (XAA), Okta's new approach to securing how AI agents connect to applications. MintMCP is one of 25+ launch partners adopting it. For enterprises already running MintMCP to deploy MCP servers and agents, the partnership means MintMCP can tie those agent connections to the same Okta identity and policies that secure the rest of your workforce. What it means for enterprises deploying MCP and agents. With XAA, MintMCP can authorize agent connections against Okta identity and policy instead of static keys, while its gateway keeps governing which MCP servers and tools an agent reaches. The controls you already run for employees now extend to the agents acting on their behalf, and the people those agents work for stop signing into the same apps over and over. For teams putting MCP servers and agents into production, that changes a few things: * Security teams can limit and revoke access: each connection runs on scoped, short-lived tokens instead of standing API keys, and every XAA-governed connection is logged against an identity, so you can see which agent reached what, under whose authority, and cut off access when something looks wrong. * Users sign in once, not once per app: use an AI assistant like Claude with MCP servers today and each downstream app needs its own login, so you OAuth into one, then the next, then the next. Routing through MintMCP, you authenticate once and the agent gets scoped access to those apps on your behalf, no repeated sign-ins, and that holds for any AI system on the gateway, not just Claude but Cursor, ChatGPT, Copilot, and the rest. * Agent access follows your Okta policies: the gateway authorizes connections against the identity-based rules you already maintain, so you extend existing governance to agents rather than building a separate one for AI. * Security review starts with identity and audit already covered: when identity and audit run through Okta and MintMCP, security review can focus on app-specific scopes and exceptions instead of rebuilding the governance model. Because Cross App Access is built on OAuth, it works with the identity controls you already run rather than adding a proprietary layer to adopt and maintain. "Cross App Access is the result of a massive, two-year collaborative effort within the OAuth working group to ensure secure, revocable agent delegation. At Okta, we are proud to have helped champion this new open standard, and we're thrilled to see MintMCP among the very first to bring it to production for enterprises deploying MCP across their org." Aaron Parecki, Director of Identity Standards at Okta How MintMCP fits. MintMCP is the gateway and control plane for agent traffic. As requests pass through custom agents, MCP servers, and orchestration layers, its gateway governs which servers an agent can reach and which tools it can call, gives each agent its own identity through agent identities, and logs every call for audit. That is its own policy and governance engine, and it runs independently of Okta. "Agents should not directly impersonate a user, and users should not have to sign in twice just to let an agent help them. With the Cross App Access protocol, MintMCP's gateway can give each agent its own identity while it acts on behalf of a real user. That means security teams can limit and revoke access, and users stay out of the repeat login loop." Jiquan Ngiam, Co-founder and CEO at MintMCP Cross App Access connects that control plane to Okta. Instead of static keys, agent connections are authorized against your Okta identity and policies, so MintMCP's MCP-level governance and the identity controls you already run work together on the same connection. Where Cross App Access fits. XAA is one piece of what Okta calls the blueprint for the secure agentic enterprise, a framework built on three questions: where are my agents, what can they connect to, and what can they do. Cross App Access answers the second. It pairs with work MintMCP has already shipped: agent identities give each agent its own credentials and scoped permissions, and the MintMCP gateway governs which tools an agent can call and records every call. Availability. Cross App Access support is available to MintMCP customers running Mint with Okta. If that's your setup, reach out and MintMCP can walk through how it fits. To go deeper, join its fireside chat with Aaron Parecki of Okta on giving AI agents safe access to enterprise apps.

Two ways AI agents leak enterprise data, and how to close both. AI agents leak enterprise data in two ways, and the defenses most enterprises already run address only the first. The first is well understood: sensitive data flowing out through the AI pipeline. Someone pastes a customer record or a contract into a prompt, it goes to an external model, and the organization is now trusting that vendor's retention and training policies with it. The second is subtler, and it is the one teams consistently underweight. Agents surface data the user was never supposed to see. An agent queries a source on the user's behalf, and when permissions are even slightly off, which is common, it returns whatever it finds: over-shared drives, stale access, a service account with too much reach. The agent has no model of who should see what, so it surfaces everything within reach. Why the usual fixes leave the same blind spot. The common fixes already in use all leave the same gap. Browser extensions only see the browser, so the moment someone switches to a desktop app, a CLI, or an API, they go blind to most of the real workflow. Network DLP sees the traffic, but it sees TLS-encrypted blobs without the structure to know that a given payload is a customer record with a tax ID in it. Zero-data-retention contracts are mostly reserved for the largest deals, and even with one in place, nothing stops an agent from returning data a user was never allowed to see. Enterprise "no-training" tiers address one risk, but the data still sits with the vendor for up to 30 days, and training was never the main exposure. Full gateways on every device cover the workflow in principle, yet they break on mobile and have to sit on every endpoint, which rarely holds in practice. The deeper issue is that the tools most teams already own were built to scan data at rest. A DSPM scan can tell you, with high confidence, that column 14 of your support database holds Social Security numbers, but it runs overnight and files a report, which does nothing to stop an agent from reading that column into a model's context at 2pm the next day. Agents move data in motion, in real time, faster than any periodic scan keeps up with, so policy has to fire the moment the agent makes the tool call, not in next quarter's audit. Closing both gaps takes two layers working together. Closing this takes control over the pipeline and real-time intelligence on the data flowing through it, working together. * Control over the pipeline decides which sources an agent can reach and what comes back. * Real-time data intelligence classifies the data in flight, then enforces policy on the spot. That combination is what lets you block an HR manager from seeing SSNs in an AI-generated summary, or redact a confidential field before it reaches the user instead of after the fact. This is the architecture MintMCP has been building at MintMCP, and it is why MintMCP has partnered with Teleskope. MintMCP governs the pipeline through the MCP Gateway: which servers an agent can reach, which tools it can call, and per-user identity on every request. The gateway terminates the connection between the AI client and the data source, so it sees each tool call the way the protocol describes it, which tool, which arguments, and the full response coming back. That position is what makes inline classification possible, because it is the one place with enough structure to read the payload in both directions and act on it. Teleskope classifies the data moving through that pipeline in real time and enforces policy at the point of the tool call, so sensitive fields get blocked or redacted before they ever reach the user. Teleskope published a clear breakdown of how MCP gateways and DLP/DSPM fit together if you want the full architecture. See it on your own data. The fastest way to understand where your agents are exposed is to watch the two layers run against your own sources. Book a demo and MintMCP will walk through how MintMCP and Teleskope close both leak paths in your environment.