MCP Security That Uses Your Identity, Your Credentials, and Your Policies

As AI agents start reaching into enterprise systems, the hard question is not whether they can connect. It is whether they can do so without bypassing the security controls your business has spent years building.

MCP has made it simple to expose enterprise systems to AI agents working through ChatGPT, Claude, Gemini, Cursor, Microsoft Copilot, and other platforms. Traditional enterprise applications were designed for humans. Now the same systems are reachable by agents, and that raises a real security question.

Many MCP implementations answer it by adding a new security layer that relies on shared service accounts, duplicated permissions, and centralized authorization logic. At Nexla we take a fundamentally different approach. Instead of rebuilding security for AI, Nexla extends the security architecture your enterprise already trusts. Authentication happens through Nexla. Authorization happens in the system that owns the data.

The security problem with most MCP architectures

Most MCP layers sit between the AI and your systems, authenticate once, then reach everything downstream through a single shared credential. Over time that creates a second authorization model running in parallel with the one you already maintain, and the two slowly drift apart.

The common failure modes look like this:

• Shared service accounts that hide who actually made a request
• Over-privileged access, because one service account has to cover everyone
• Policy duplication across the enterprise and the AI platform
• Security drift as those two policy sets diverge
• Difficult audits and reduced visibility into who accessed what
• The AI platform quietly becoming a shadow authorization system

To make this concrete, here is what the source system actually sees in each model. Toggle between them:

How MCP security works in Nexla

Nexla preserves identity from the MCP client all the way to the source system, and lets each system make its own authorization decision. Identity flows through five steps:

If a user has not connected a system yet, Nexla shows an authorization screen so they can create the credential, stores it securely in the control plane, and reuses it for future sessions. The result is zero trust from end to end. Nexla never over-privileges for users. It uses the same permissions the user already has in their systems.

Principle 1: Centralized credential management

Identity alone is not enough. Enterprise AI also needs a secure way to manage credentials across hundreds of systems. Nexla provides centralized credential lifecycle management in the control plane, covering OAuth credentials, API keys, service principals, cloud IAM, and enterprise authentication tokens.

• Users connect and authorize once
• Nexla stores, rotates, and governs credentials
• Optional bring-your-own-key vaults or fully Nexla-managed vaults
• Audit logs for every credential access

Organizations can choose between a fully managed Nexla Vault and a customer-controlled vault that uses their own key management, so security teams keep the level of control they require.

Principle 2: Credential pushdown, per user

Rather than a single service account that represents everyone, Nexla uses each user’s actual credential whenever it touches an enterprise system. So Salesforce sees Sarah, not a generic agent identity, and applies Sarah’s real permissions. Because identity never gets lost, access is least privilege by default, and revocation is instant. When a user’s access changes in the source system, the agent’s access changes with it. There are no shared service accounts to clean up later.

Principle 3: Native policy enforcement

The most important security decision should always happen where the data lives. Most enterprises have already invested heavily in access policy, and Nexla does not try to recreate it. Each source system keeps enforcing its own controls on every agent call:

Salesforce

• Sharing rules
• Territory security
• Object & field-level security

Snowflake

• Row-level security
• Dynamic masking
• Role-based access

Databricks

• Unity Catalog
• Data access policies

ServiceNow

• ACLs
• Role permissions

SAP

• Authorization models
• Business role controls

Your systems already know who can access what. Nexla lets them keep making that decision, with no policy duplication and no drift.

Why copying data and trying to mirror its policies breaks down

Any time you copy data out of a system, you also inherit its access policies, and the job of keeping that copy correct forever. The data moves once. The permissions behind it keep changing. So the moment you replicate a source into a central lake or warehouse, you have signed up to reproduce its authorization model in the new location and to re-sync it every time the original changes. That mirrored model is never fully caught up, which means the copy almost always grants access the source itself would have denied. This is a structural problem with copying data and mirroring policies, not a problem with any one tool.

Salesforce into Databricks is a good example of the pattern. A team replicates Salesforce into a data lake and then tries to recreate its sharing rules, territory rules, and field-level security as Unity Catalog policies so the copy enforces the same access. Hand-written pipelines and replication tools such as Fivetran make the data copy easy, but the access model is left to the customer to rebuild and maintain. Salesforce permissions are not static, so mirroring them downstream becomes a continuous synchronization problem that is never fully solved, and every gap between the two systems is an exposure.

The failure modes are predictable. Someone sees rows in the lake they could no longer see in Salesforce. A revoked permission takes effect in the source at once and in the copy on the next sync. Audits have to reconcile two systems of record instead of one. And the whole model has to be rebuilt for every source, because Snowflake masking, Databricks Unity Catalog, ServiceNow ACLs, and SAP authorizations do not share a policy language. Mirroring is not a one-time migration. It is a permanent tax.

Nexla does not mirror policy, because it never needs a second copy of your access model. It solves the problem in two ways.

• Credential pushdown for live access. When a user or an agent reads from a source, Nexla resolves and uses their own credential, so Salesforce, Snowflake, Databricks, ServiceNow, and SAP each apply their own live policy at query time. There is nothing to mirror and nothing to drift, because authorization never leaves the system that owns the data.
• A governed data product marketplace for sharing. When data genuinely needs to be packaged and shared, the unit of governance is the data product, not a copied table. Each product sits in a governed marketplace where a user requests access and an owner approves it, with lineage and audit attached. Access is granted on the product and recorded, rather than reverse-engineered from source permissions and hoped to stay in sync.

It is the same principle as the rest of this post, extended from agent access to data sharing. Authentication and packaging happen in Nexla. The authorization decision stays with the system, or the owner, that should be making it. Nothing has to be copied twice and kept identical forever.

What happens when a user has no credential

Enterprise AI cannot assume every user has already connected every system. When an agent requests a tool and no credential exists, Nexla launches an authorization flow, the user approves access, and the credential is stored in the control plane for future sessions. The benefit is frictionless, self-service onboarding with no administrator in the loop, and credentials that carry across future MCP sessions.

Why this approach is better

• Least privilege by design. The user’s existing permissions are always respected.
• No policy duplication. Security stays in the systems that already own it.
• No security drift. There is no second authorization model to maintain.
• Full identity fidelity. Every call carries the user’s real identity and context.
• Complete auditability. Trace any request from the MCP client through the connector to the source system.

Our philosophy

Your identity: the user remains the user. Your credentials: the user’s credentials remain the credentials. Your policies: the systems that own the data continue enforcing access. That is the way enterprise AI security should work.

By combining centralized credential management, credential pushdown, and native policy enforcement, Nexla lets AI agents access enterprise systems securely, without introducing a second security model. If you want to see it on your own systems, request a demo or explore MCP Studio.

FAQ

Does Nexla store my users’ credentials?

Credentials live in the control plane, encrypted and governed, with full audit logging. You can use a fully managed Nexla Vault or bring your own key with a customer-controlled vault. Agents call tools, never the raw credentials, tokens, or secrets.

Do I have to rebuild my access policies for AI?

No. Nexla pushes the user’s own credential down to each source system, which then enforces its existing policies. There is nothing to duplicate and nothing to keep in sync.

Which MCP clients does this work with?

Any MCP client, including ChatGPT, Claude, Gemini, Cursor, and Microsoft Copilot. Nexla is built to the open MCP standard, so it is not tied to a single AI vendor.