MCP in the Enterprise: Connecting Agents to Confluence, Jira and Microsoft 365 Safely

What is the Model Context Protocol?

MCP is a standard protocol between an AI agent and the tools it uses. A server exposes capabilities, such as searching a wiki or reading a ticket, and a client inside the agent discovers and calls them. Instead of writing a bespoke integration for every pairing of agent and tool, you write against one protocol.

Why is connecting agents to enterprise tools a security question?

An integration question asks whether the agent can reach Confluence. A security question asks what it may read once it gets there, on whose behalf, and what happens to the text it brings back. In a classic integration a person clicks and a service account is audited. With an agent, the tool call is made by a model, often in a loop, from text that may itself have come from a retrieved page.

Four concerns follow, and I treat them as the real scope of any MCP project:

• Permissions: the agent should see what the person asking may see, not what the shared token can see.
• Prompt injection through retrieved content: a wiki page or a ticket is data, but a model may read instructions inside it.
• Data classification: confidential and secret material must not flow to places it should not reach, external models included.
• Audit: you must be able to reconstruct what was served, to whom and why.

What are the main risks, and which controls answer them?

Most failures I expect in this space are not protocol failures. They come from a service account with broad rights that nobody scoped to the person asking. The table maps each risk to the control I look for when I review a connector.

How does ORBIT connect to Confluence, Jira and Microsoft 365?

ORBIT, the context platform I built, has two routes to external tools. Native connectors cover SharePoint and OneDrive, Confluence and Jira. MCP connectors cover Confluence and Jira, Microsoft 365, Google Workspace, Slack, GitHub, Linear, Obsidian and Figma, with a five-step start-up assistant. A worker synchronises connectors on a schedule, every 60 minutes by default.

Both routes feed the same ingestion pipeline. A Confluence page or a Jira ticket goes through personal-data detection, classification and chunking before it can be served to any agent. The design choice I care about is that the agent never talks to Confluence directly: it talks to ORBIT, which holds a synchronised, classified copy.

One limit to state plainly: interactive OAuth sign-in for Microsoft 365, Google and Linear through MCP is on the roadmap and is not delivered.

How does ORBIT keep permissions and classification intact?

The rule is stated in one line in the README: content is served only if its classification is at or below the lowest of the user’s clearance, the agent’s clearance and the ceiling set on the request. An agent acts on behalf of a project member. Without that, it reaches only what is open to the whole project.

NOVA, my personal product agent, retrieves ORBIT context as the user, so the same rule applies when a person asks it for a deliverable. These are the mechanisms behind the rule:

• A classification scale from C0 (public) to C3 (secret), aligned with the organisation’s policy.
• Access lists on documents, chunks and memory. Derived memory inherits the most restrictive list and the highest classification of its sources.
• Exclusions for access or classification are logged but redacted for anyone without access: no title, excerpt or identifier. Agents receive counters only.
• Personal-data detection at ingestion, and served context always uses the redacted text.
• Revocation events, such as document.acl_changed, member.removed and agent.revoked, in the change feed and in signed webhooks, so consumers can invalidate what they derived.

How does ORBIT deal with prompt injection in retrieved content?

Prompt injection is the risk that MCP makes most visible, because the agent now reads text written by people it never met. I do not believe a single filter solves it, so ORBIT layers several defences, all visible in its configuration:

• At ingestion, each fragment is scored. Above a threshold (0.6 by default) it is quarantined until a project owner releases it. A local classifier is an optional addition.
• At serving time, everything handed to agents is tagged as untrusted data, a technique often called spotlighting.
• Low-trust sources receive a ranking penalty (0.15 by default), so they surface less often.
• A poisoning alert fires when a recent source or an agent proposes an unusual number of items in a time window (8 within 24 hours by default).

What does ORBIT’s own MCP server expose, and how are third-party servers contained?

ORBIT is also an MCP server, over streamable HTTP. Each agent holds an API key bound to a project, and only its SHA-256 fingerprint is stored. The server exposes 12 tools, among them get_context, search_sources, expand_source and propose_memory. That last tool creates a proposal that a human must validate, so an agent cannot write straight into trusted memory.

For third-party MCP servers, ORBIT inverts the usual trust. Only preset servers can be launched, from an allow-list, with arguments built on the server side. They run in an isolated environment that holds only that connector’s credentials, with timeouts and caps on the number of items. Connector secrets are encrypted and never displayed again, and the backend images embed pinned versions of Node.js and the MCP servers, so no code is downloaded at runtime. A custom preset exists, but it is disabled by default and reserved for administrators.

Is ORBIT ready for production, and where should you start?

No. ORBIT is a public beta and is not validated for production use. Its README says that full production hardening, including single sign-on, multi-factor authentication, chained audit and backups, is still in progress. I have no measured results to quote: what follows describes what the project provides, not what it has achieved. Its demo set contains deliberately fictitious C2 (confidential) and C3 (secret) content, and the README warns never to mix in real data. I repeat that warning.

Whatever tool you choose, this is the order I would follow:

• Inventory every MCP server and connector, and name an owner for each.
• Replace shared service accounts with access on behalf of the person asking.
• Classify content before it reaches an agent, and cap what external models may receive.
• Treat all retrieved text as untrusted data, never as instructions.
• Allow-list servers and keep custom ones disabled.
• Log what was served and why, and test with fictitious data first.