Q:

How do I create a meteor topic that is for server-only security sensitive information (client cannot subscribe)?

The meteor pub/sub mechanism is excellent way to share information across packages on the server without having to share package implementation details with other packages.
I would like to use the publish/subscribe mechanism for security sensitive data. This sensitive topic must only be published and subscribed to by different server components. I.e. clients cannot subscribe to the sensitive topic. 
Since the client code can be altered by a malicious user, the server must explicitly prevent a client from successfully subscribing to the sensitive topic. 
How can I make a topic private to server(s)?
Update (for @alanning) :
Why I like pub/sub (partial list):

pub/sub is an easy way to reduce the coupling in large projects. packages/modules/whatever don't know who is handling their output or their request (or where) - refactoring is easy because the only entry points are at the topic level, not the code level.
pub/sub allows the request to be handled on different VMs without special coding change.
pub/sub provides an easy way to route to /dev/null certain kinds of requests when the server is under high load.
Easy mock point for testing.
Generator of data doesn't need to know how the data is used.
1-N consumers without the producer being aware of the multiple consumers.

Within Meteor:
I would like to be able to use the meteor pub/sub mechanism because:

Reusing code is awesome
meteor pub/sub has the Deps mechanism (awesome^2)
meteor pub/sub includes transport mechanism (server to server communication for free?)
meteor team is enhancing it - so I don't - hey I am lazy!
other servers running other technologies could be shimmed in. ( apache solr, hadoop? )

But sadness:

clients are insecure
some topics need to be authenticated
some topics are internal to server so don't need overhead of packaging data for transport.

A:

Meteor.subscribe is only available on the client, not the server.
http://docs.meteor.com/#meteor_subscribe
-- Update 2 --
Message passing between code within the same process
Nodejs provides EventEmitter which allows setting up custom events.  Import both the 'events' package and the 'util' package to set up inheritance, like so: 
util.inherits(MyQueue, EventEmitter);
Here's how you would import those npm packages: 

Npm.require('events') in a Meteor package 
Meteor.require('events') in a Meteor application using the npm meteorite package

Here is an example of using it to listen to a redis queue.  Setting up your own queue is primarily a matter of convention as to what events to publish and listen to.
-- Update 1 --
Message passing between code running in different processes
A pub/sub queue is definitely a great choice and you have several ways to implement that.  Here are two that come to mind:

implement a poor-man's queue using Mongo collections
use a 3rd-party message queue such as RabbitMQ

Mongo Collections
Doing it with Mongo is possible depending on your requirements.  A quick search brings up several implementations and design discussions (mostly Ruby): https://www.google.com/search?q=pubsub+queue+with+mongo . Careful, with this though...in the long run this could end up being more work.  Depends on what features you need.
A 3rd-party message queue
An actual queue solution provides the best means to enable distributed messaging.  You can set up a RabbitMQ cluster which your Meteor processes interact with to distribute work.  Provides nice benefits such as high availability and guaranteed delivery.  Also, workers don't have to be nodejs processes; any AMPQ client could receive tasks.

