Ferentin Now Supports Enterprise-Managed Authorization: Agent SSO at the Front Door, Governance on Every Call

Ferentin now supports outbound Enterprise-Managed Authorization (EMA) for MCP. EMA brings single sign-on to AI agents, so your identity provider approves each agent's connection to an MCP server. But the IdP only guards the front door. Ferentin governs every call that follows, at machine speed, for every agent, including ones like Cursor that have no EMA support of their own.

Four agents, one employee, too many tokens

Picture one engineer on an ordinary Tuesday. Claude drafts a design doc from Jira tickets. Cursor refactors a service and opens a GitHub pull request. ChatGPT summarizes a customer thread from Salesforce. That afternoon, a Slackbot answers a teammate's question from the same Jira project while the engineer is in a meeting.

That is four agents reaching the same handful of enterprise systems for the same person. Under plain OAuth, each agent asks for its own consent and holds its own refresh token for each server. Four agents and five MCP servers already make up to 20 grants. Security can't see them in one place, the IdP can't revoke them and they outlive the reasons they were granted.

The agents aren't the problem. The problem is that every one of them talks to every server directly, with nothing in between that the enterprise controls.

Agent SSO: what Enterprise-Managed Authorization adds

Enterprises solved this problem for people a decade ago with single sign-on. EMA is SSO for agents: it gives the enterprise identity provider a seat at a table it was left out of.

Every agent connection has three legs:

In plain MCP OAuth, those three legs are tied together by a consent screen the user clicks, once per agent and once per server. Three agents and three servers make nine consents and nine refresh tokens. The enterprise isn't a party to any of them.

EMA adds the enterprise as a fourth party. It is an MCP extension (io.modelcontextprotocol/enterprise-managed-authorization) built on the Identity Assertion JWT Authorization Grant, or ID-JAG. Okta markets the same pattern as Cross App Access (XAA). It replaces the consent screen with two standard OAuth steps:

1. Token exchange at the IdP (RFC 8693). The client presents the user's identity token. The IdP applies its policy for this user, agent and server, then issues a short-lived ID-JAG for that one server.
2. JWT-bearer grant at the MCP server (RFC 7523). The client redeems the ID-JAG at the server's authorization server for an access token.

The IdP guards the front door, and only the front door

EMA settles whether a connection may be made. After that, the IdP steps out. The agent holds an access token and calls tools at machine speed: reading tickets, opening pull requests and moving tasks, often many times a minute and with no person watching. None of those calls go back through the IdP. It can't tell a routine query from a bulk export, can't see a secret pasted into a tool argument and can't stop a prompt-injected agent halfway through a task.

That is the gap Ferentin fills. EMA gets the agent in the door. Ferentin monitors, controls and governs every call the agent makes once it is inside.

EMA runs in two directions. Inbound, an agent presents an ID-JAG to sign in to a server. Outbound, the subject of this post, Ferentin's gateway presents the ID-JAG on the user's behalf. This puts Ferentin in the path of every call, and it works for every agent because the agent never takes part in the exchange.

Spotlight: outbound EMA

With outbound EMA, Ferentin's gateway asks your IdP for an assertion whenever it needs a new upstream token for a user. The IdP decides whether the connection may be made. The gateway then carries every call over that connection, so policy, DLP and audit apply to each one. The agent never holds the upstream credential, and the user never sees the upstream's consent screen.

When the user signs in to Ferentin through your IdP, Ferentin keeps their identity token. When an agent sends a tool call, the gateway exchanges that identity at the IdP for an ID-JAG addressed to the MCP server's authorization server (step 1). It redeems the ID-JAG there for an access token (step 2), then calls the MCP server as that user (step 3). If the identity token has expired, Ferentin refreshes it at the IdP first, so a disabled account stops working at the next refresh. A cached upstream token skips steps 1 and 2 entirely.

Why "federated" is the important word

Upstream MCP servers that support ID-JAG already trust enterprise IdPs such as Okta. Ferentin doesn't ask any SaaS vendor to trust a new issuer. It acts as a well-behaved client of a trust relationship you already control.

The gateway also handles the details that make this work against real IdPs:

• Okta custom authorization servers. Okta mints ID-JAGs only at its org authorization server. At sign-in, Ferentin silently collects the identity it needs from that server.
• IdP-specific parameters. Some IdPs require the RFC 8707 resource parameter on the exchange and others reject it. This is a per-IdP setting.
• Discovery, not configuration. Ferentin finds the upstream's authorization server, resource identifier and scopes from the server itself.
• One reconnect per IdP. If the IdP session lapses, the user gets a single "sign in again" prompt, as an MCP elicitation in their agent or in Slack, and every EMA server bound to that IdP comes back at once.
• Fast and quiet when warm. Upstream tokens are cached per user and per server for most of their lifetime, so a cache hit adds no IdP round trips.

Agents that don't speak EMA, such as Cursor

An agent doesn't need EMA support for outbound EMA to govern it. Cursor has no EMA client today, and many other agents don't either. Outbound EMA still covers them, because the ID-JAG exchange happens between Ferentin and your IdP, behind the gateway. The agent never takes part in it.

What Cursor needs is the standard MCP authorization flow it already supports:

1. Point Cursor at your Ferentin MCP endpoint instead of at Jira, GitHub or Salesforce directly. A developer adds one server entry rather than five.
2. Cursor signs in with standard MCP OAuth. It registers as a client and runs an authorization-code flow with PKCE against your tenant's Ferentin authorization server.
3. That sign-in is your SSO. Ferentin sends the user to your IdP, so the identity behind Cursor's token is the same one your IdP manages, and the IdP's MFA and conditional access apply.
4. Outbound EMA does the rest. When Cursor calls a tool, the gateway gets that user's upstream token from your IdP, as shown in the flow above. Cursor holds a Ferentin token and nothing else.

The result for an agent without EMA is the same as for one with it. It holds no upstream credentials, every call is checked against policy and DLP and disabling the user at the IdP cuts off its upstream access. Agents that do support EMA, such as Claude Code, can also sign in to Ferentin with an ID-JAG, which removes even the Ferentin consent step. That is an optional extra, not a requirement.

Closing the side door

Governance at the gateway only holds if agents go through the gateway. A developer can still paste a GitHub MCP server straight into ~/.cursor/mcp.json with a personal token. Ferentin's endpoint agent watches the MCP configuration files of Cursor and other AI tools on managed devices. It reports servers that bypass the gateway and can quarantine them, so the governed path is the only one.

Why the gateway is the right place for this

EMA settles who may connect. Ferentin settles what each call may do, at the speed agents work, on the same path.

Go back to Tuesday. Claude, Cursor, ChatGPT and the Slackbot all connect to one Ferentin MCP endpoint instead of to five servers each. Every call they make goes through the same chain:

1. Identity. Each agent arrives as the user, through inbound EMA or SSO, under a token the enterprise issued.
2. Policy. Per-server grants, per-tool allow and deny lists, tool constraints, step-up and human approval run before anything reaches the upstream.
3. Data protection. DLP and prompt-injection sanitization inspect tool inputs and results in both directions.
4. Credential. Outbound EMA gets that user's upstream token from your IdP. The agent never holds it.
5. Audit. Every call is recorded with the user, the agent, the server, the tool, the decision and the mint.

The outcome is a single question for the security team: what can this person's agents do? There is a single place to answer it and a single switch to change it. The answer doesn't depend on which vendor's agent is asking.

The Slackbot case

Background agents are where per-agent OAuth fails hardest. A Slackbot that works while you're in a meeting needs upstream access with no browser window to show a consent screen. Usually that means a long-lived refresh token sitting in yet another system.

Outbound EMA works offline because it starts from the identity your IdP already issued at sign-in. Ferentin's Slack agent dispatches through the same governed executor as every other surface. It gets the same policy, DLP and audit as a live session and is cut off by the same IdP revocation. Channel-shared connections are deliberately kept out of outbound EMA: a token tied to one person is never handed to a whole channel.

Design choices that matter to a security team

Getting started

Outbound EMA is available today, enabled per tenant, and we have verified it end to end against Okta.

To turn on outbound EMA for an MCP server:

1. Connect your IdP in the Ferentin admin console. Ferentin checks that it can issue ID-JAGs before it lets you bind servers to it.
2. Register Ferentin with the upstream. The upstream's authorization server issues a client for Ferentin to redeem assertions with. In Okta, the resource application's managed connection provides this.
3. Add the server in user mode and choose Enterprise-managed (federated) as its upstream authentication. Ferentin discovers the server's authorization server, resource identifier and scopes on its own.
4. Write the policy. Decide which users and agents may reach the server and which tools they may call.

Then point your agents at your tenant's Ferentin MCP endpoint. Cursor, ChatGPT and Codex sign in with standard MCP OAuth through your IdP. Agents with native EMA support can use it, but they don't have to.

What's next

• Ferentin as an assertion issuer. We also support a mode where Ferentin itself signs the ID-JAG after its own policy check. That mode is useful when an upstream will trust Ferentin directly. Today every upstream that advertises ID-JAG trusts the customer's IdP, which is why the federated mode is the one we lead with.
• More IdPs. Our next interop targets are additional identity providers that issue ID-JAGs.
• Agents speaking EMA natively. As more assistants and coding agents ship EMA clients, inbound EMA becomes the default way for them to reach Ferentin.

If your teams already use more than one AI agent, your IdP should decide what those agents can reach and every call should be governed on the way through. Talk to us about turning on EMA for your tenant.