M

MintMCP

Enterprise AI gateway and governance platform

Technical Customer Success Manager

Full-Time
No salary listed
Mid
San Francisco, CA, USA+1 moreMore locations: San Mateo, CA, USA
HybridIn-person work in the San Francisco Bay Area, with travel to meet customers.
Sales & Account ManagementAccount Management

About the job

Requirements
  • Own customer relationships end to end in customer success, account management, consulting, or a client-delivery role.
  • Run plans and drive outcomes across a customer's team by aligning stakeholders, tracking commitments, and maintaining momentum.
  • Handle technical conversations with buyers, explain the product and its value, and recognize when to involve technical teammates; writing configuration or debugging integrations is not required.
  • Carry retention and expansion responsibilities, or demonstrate commercial instincts through customer relationships that were retained and grown.
  • Build structure, playbooks, templates, and operating cadences where none exist.
  • Remain calm under pressure and own outcomes when customers are unhappy.
  • Be AI-native or able to become so quickly, with genuine curiosity about AI, agents, and company adoption of them.
  • Work quickly with limited process and be interested in growing into team leadership.
Responsibilities
  • Own the customer relationship from deal close through the full customer lifecycle.
  • Build a mutual delivery plan with each customer, defining success, responsibilities, and timelines.
  • Drive onboarding, launch the product against real use cases, and support adoption as usage grows.
  • Track account health, run check-ins and business reviews, identify risks early, and involve engineering or founders when needed.
  • Own renewals and grow expansion across more teams, agents, and customer workflows.
  • Own resolution of urgent customer issues.
  • Advocate for customers to the founders while balancing customer requests with company priorities.
  • Build a repeatable customer-success function, including delivery-plan templates, health scoring, review cadence, and sales handoffs.
  • Help determine future customer-success hiring and grow into leading the function.
  • Meet customers in person and travel for customer visits.
Desired Qualifications
  • Background as an AI solutions engineer or forward-deployed engineer.
  • Experience selling to or supporting technical and engineering buyers.
  • Experience with enterprise rollouts involving security review, procurement, and multi-threaded relationships.
  • Comfort representing the company at business reviews, dinners, and on-site meetings with technical and security leaders.

About the company

M

MintMCP

View
Website

MintMCP connects AI assistants to a company’s internal data and apps, enabling secure AI at scale. Lutra automates data-heavy tasks by turning natural language into executable code to orchestrate workflows across Google Workspace, Microsoft apps, and CRMs, with reusable Playbooks. MintMCP adds enterprise security and governance—SSO, RBAC, audit trails, observability, guardrails, MCP Gateway, Agent Monitor, and Intelligent Guardrails—SOC 2 Type II, self-host or cloud. The goal is to let organizations deploy AI agents safely and efficiently across the business, maintaining security, governance, and visibility.

Company Size

11-50

Company Stage

N/A

Total Funding

N/A

Headquarters

San Francisco, California

Founded

2023

Get referred to MintMCP

See people who can refer or advise you

Simplify Jobs

Simplify's Take

What believers are saying

  • Okta named MintMCP a June 23, 2026 Cross App Access launch partner.
  • MintMCP launched agent identities in 2026, directly addressing enterprise audit and delegation pain.
  • SOC 2 Type II and enterprise self-hosting reduce procurement friction for regulated buyers.

What critics are saying

  • OpenAI, Anthropic, and Microsoft can bundle native agent governance into their platforms by 2027.
  • MintMCP depends on Okta; an XAA failure or policy change breaks distribution.
  • If MCP standardization moves into core vendors, MintMCP becomes a commoditized feature.

What makes MintMCP unique

  • MintMCP gives every agent its own identity, audit trail, and delegated permissions.
  • Its gateway enforces MCP tool scopes and revocation through Okta Cross App Access.
  • Few rivals pair self-hosted MCP governance with SSO, RBAC, guardrails, and observability.

Help us improve and share your feedback! Did you find this helpful?

Benefits

  • Health Insurance
  • Company Equity

Growth & Insights and Company News

Headcount

6 month growth

-15%

1 year growth

-8%

2 year growth

-8%
MintMCP
Jun 23rd, 2026
Okta partners with MintMCP to govern how agents connect to enterprise apps.

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.

MintMCP
Jun 15th, 2026
Two ways AI agents leak enterprise data, and how to close both.

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.

MintMCP
Apr 2nd, 2026
Introducing agent identities: give every AI agent its own credentials and delegated permissions.

Introducing agent identities: give every AI agent its own credentials and delegated permissions. Every AI agent in your organization access data as if they are a person. When an agent accesses a CRM, sends an email, or queries a database through MCP, it does so as the human who configured it. That means there's no way to tell agent actions from human actions in your audit logs, no way to scope an agent's access independently, and credential bleed when multiple agents share the same user's tokens. Today MintMCP is launching agent identities for the MintMCP gateway, so enterprises can give each agent its own identity with explicitly delegated permissions across services. The identity problem. This gap starts when individual users are using MCP tools at their desks. It becomes a big pain point as soon as companies move to team-owned agents: bots running in Slack, scheduled jobs pulling reports, automated workflows triggered by events. There's no clean way to separate what an agent can access from what the person who set it up can access. MintMCP hear the same thing from every enterprise MintMCP talk to. They gave hundreds of employees access to MCP tools and it worked great. Now they want to give access to autonomous agents that act like teammates, and the identity model breaks. A QA bot shouldn't have the same permissions as a deal-management agent, and both should be clearly distinguishable from human users in audit logs. Agent identities fix this by treating each agent as its own principal: separate identity, scoped permissions, and a dedicated audit trail, while the delegating user retains clear ownership of what the agent can do. "When each agent has its own credentials and its own scope, you stop worrying about what could go wrong and start focusing on what you can build next." Mark Shasha, CISO at Braze How it works: agent bundles. Agent identities ship as agent bundles in the MintMCP gateway. A bundle packages multiple tool connections under a single agent identity, with a specific credential bound to each connection. So an agent can access Outlook under one person's delegation, a CRM under another's, and a code repository under a team service account, all governed as one auditable identity. When creating an agent bundle, you select the agent-identity MCP type, which binds all connectors to the agent rather than to individual users: Each connection within the bundle gets its own delegated credential. Here, a single agent has GitHub access via one team member and Linear access via another, each with their own OAuth grant: Here's what this looks like in practice: * Dedicated authentication: each agent authenticates to the MintMCP gateway via its own token, so agents never handle raw credentials directly * Per-connection permissions: permissions are delegated within the bundle. One agent can read CRM records and draft emails, another can search LinkedIn and create notes, a third can only read * Shared administration: authorized team members share administration of the bundle through a secure sharing model, so credentials and tool access can be managed jointly without exposing secrets * Agent-level audit trail: every tool call is logged against the agent's identity, which means audit trails show which agent took which action, under whose delegation, at what time * Single-operation revocation: revoking an agent's access or rotating its credentials is one operation with no impact on other agents or users Why this matters for enterprises. The underlying challenge is that IAM was designed for humans and static services. Agents are neither - they're stateful, reasoning entities that act as proxy identities on behalf of users, but with their own logic layer. As organizations deploy more agents, they need a new class of identity governance to do it with confidence. "IAM was designed for humans and static services. Agents are neither. They're stateful, reasoning entities that act as proxy identities on behalf of users, but with their own logic layer. Enterprises need a new class of identity governance to deploy them with confidence." Tas Jalali, Cybersecurity Executive and AI Governance Leader Without agent identities, companies face a hard choice: let agents operate under human credentials (breaking auditability and least-privilege) or don't deploy agents at all (losing the productivity gains). Agent bundles give a third path: full agent autonomy with clear boundaries. Once every agent has its own identity, you get a clear picture of what's happening across your stack. That visibility is what lets you deploy the next ten agents with confidence, because you can see exactly what each one is doing, scope its access to what it actually needs, and revoke it in one step if something goes wrong. "Once every agent has its own identity, you get a clear picture of what's happening across your stack. That visibility is what lets you deploy the next ten agents with confidence." Brian Shultz, Co-founder and CTO at Tango Get started. Agent identities are available now in the MintMCP gateway. To set up your first agent bundle, see the agent identities documentation. If you're already using MintMCP, agent bundles work alongside your existing connectors and access policies. If you're evaluating MintMCP, get in touch and MintMCP can walk through how agent identities fit your setup.