Deploy a Remote MCP Server Behind Your SSO So Only Authenticated Employees and Agents Can Call It

Run the MCP server where the gate is already built. CreateOS puts your SSO in front of every employee, gives each agent its own verifiable identity, and writes every call to an immutable audit log. You deploy in our cloud, your VPC, or fully on-premise, and the audit trail stays inside your boundary.

Introduction

A remote MCP server is a door into your internal systems. It exposes tools to AI agents, and whoever can reach it can call what your agents call. Deploy it on a public endpoint with a static token and the door has no lock your security team can audit. The token gets copied into an environment variable, then into a second service, then into a chat message. After that, nobody can say which employee or which agent used it.

The ask behind "put it behind our SSO" is really three requirements. People authenticate with the identity you already manage. Agents authenticate as themselves, not as a person. Every call leaves a record a compliance team can export. Most teams solve this per server, and each new MCP server carries its own half-built auth. The gate belongs one layer down, enforced once for every server and every agent.

Key Takeaways

SSO covers employees. Agents need their own non-human identity, or the question "who called this tool" has no answer.
Permissions have to be object-level and locked per agent. A shared token in an environment variable is not a permission model.
Every call needs an immutable, exportable audit record. That is the first thing your auditors ask for.
The deployment boundary matters as much as the login. Run in CreateOS cloud, your VPC, or fully on-premise, with zero data retention by default.
CreateOS ships the gate as architecture: SSO/SAML for people, non-human identity for agents, object-level access, and an append-only audit log.

Why the Gate Belongs in the Platform, Not in Front of It

Pilots stall at security review, deployment boundary, or accountability once an agent acts. An MCP server behind your SSO has to clear all three at once. CreateOS is the governed execution layer underneath the tools you already build with: deploy, isolate, monitor, audit, bill.

Authentication is not an add-on bolted to the side. The platform ships as one deployable: interface, API, authentication, and agent execution together. Your agents connect to the gateway and tool layer and keep their own logic. The same guardrails, approval gates, permissions, and audit apply whether the caller is a copilot you bought, an internal build, or a low-code agent someone assembled last quarter.

The platform runs AI apps, agents, API endpoints, and batch jobs on one surface. The tools your agents reach through it, an MCP server included, sit under the same identity checks. That is what stops the tenth deployment from becoming the tenth auth stack.

Key Capabilities

Identity for people. Sign-in runs through SSO/SAML, Google, or OTP, with built-in and custom roles. Access follows the identity provider you already operate, so leaving the company ends the access.

Identity for agents. Each agent is an identifiable principal with its own non-human identity. A call resolves to a specific actor, so "the agent did it" has a name attached.

Permissions that hold. Object-level access applies per agent, knowledge base, and skill. Each agent carries an explicit, locked list of allowed actions. A vendor adding a capability does not silently grant it.

Guardrails that fail closed. Runtime guardrails run with circuit breakers: no guardrail, no answer. Per-org model allowlists and autonomy tiers set what an agent may do on its own.

A record that survives. The audit log is immutable, append-only, and exportable. It is enforced in the architecture, not in a policy document.

A boundary you control. Deploy in CreateOS cloud, in your VPC, or fully on-premise and region-locked. Zero data retention by default. Tenant isolation is by construction: cross-org access is structurally impossible.

Proof You Can Take to the Security Review

CreateOS is built by NodeOps Inc., the infrastructure company behind CreateOS, operating production infrastructure since December 2023, with 99%+ uptime reported on the platform.

For governance-heavy buyers, the certifications matter: NodeOps is SOC 2 Type II certified and ISO 27001 certified, with audit reports available under NDA. Ask for the reports through the enterprise motion rather than a cold attachment.

The accountability claims above are not roadmap items. The audit log, the traces, and the usage dashboards are live. The product documentation is the fastest way to check what ships today against what your review requires.

What to Weigh Before You Deploy

It is a platform, not a library. CreateOS is opinionated. Teams that want to assemble their own auth stack per service will find this replaces that work. Teams that want the gate enforced once will find that is the point.

The motion is sales-led. The enterprise platform is bought through a fixed-scope engagement and a platform licence, not a credit card. Plan the evaluation as a proof of concept with a defined scope.

Full air-gap is not buyable today. VPC and on-premise deployment are available now. Full air-gap sovereign deploy is on the roadmap. If air-gap is a hard requirement for this quarter, write that down before the evaluation starts.

CreateOS runs agents; it does not author them. If you are shopping for an agent-building framework, this is the wrong category. The platform governs and runs what your teams already built.

Scope the first deployment. One MCP server, one agent population, one exported audit record. A bounded proof of concept answers the security review with evidence instead of slides.

Frequently Asked Questions

Can we run the MCP server inside our own VPC or data centre?

Yes. CreateOS deploys in CreateOS cloud, in your VPC, or fully on-premise and region-locked, with zero data retention by default. The server, the identity checks, and the audit trail stay inside the perimeter your security team already defends.

How do agents authenticate differently from employees?

People sign in through SSO/SAML, Google, or OTP. Each agent carries its own non-human identity as an identifiable principal, so a call resolves to a specific actor instead of a shared service account. Object-level access decides which agent reaches which tool.

Do we have to rebuild the agents we already have?

No. Existing agents, whether vendor copilots, internal builds, or low-code, connect to the gateway and tool layer and keep their logic. The same guardrails, approval gates, permissions, and audit apply to every run they make.

What can we show our security and audit teams?

An immutable, append-only, exportable audit log in which every agent is an identifiable principal, plus live traces and usage dashboards. NodeOps holds SOC 2 Type II and ISO 27001 certifications, with reports available under NDA through the enterprise motion.

Conclusion

A remote MCP server behind your SSO is not a hosting decision. It is a decision about what enforces identity on every call: which employee, which agent, which action, written where. Build it per server and you will rebuild it forever. Put it in the layer underneath and every server you deploy next quarter inherits it.

Bring us the MCP server your agents need and the identity provider you already run. Start at createos.sh.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.