❮ Back to blog
AI Security

Obsidian and Cloudflare extend Zero Trust to what AI agents do in your third-party apps

Secure your third-party apps with Obsidian and Cloudflare MCP Server Portals. Learn how to extend Zero Trust access and enforce policies on AI agent actions.

5 min read

With the Obsidian integration for Cloudflare MCP Server Portals, security teams using Obsidian and Cloudflare together can route AI agent traffic through the Cloudflare MCP gateway and have each tool call checked against the Obsidian Policy Engine before it reaches a third-party app.

Cloudflare provides the Zero Trust front door for agent traffic; Obsidian provides the policy-driven decision on each action behind it.

AI agents act with your employees' access, faster than anyone can review

Developers and business teams are connecting AI agents to the third-party apps that hold your data. Each agent acts with the access of the person or service account behind it, in seconds.

Agents know what they can do. They rarely know what they should do. A report the next morning that an agent pulled sensitive pay data for a non-finance user arrives after the data has left, so the check has to happen before the call reaches the app.

Consider a senior engineer who resigns. HR records the termination in Workday at 9am, and the engineer's coding agent sessions stay connected to company apps with the access the engineer held. The agent keeps acting with that access until someone notices the termination and revokes each credential by hand.

A gateway sees the request, not what the action means to your business

A gateway decides with the request in view: who connected, which tool they called, and its arguments. Nothing in that request says the engineer was terminated at 9am. Whether that call should run depends on facts that live in your HR system and your third-party apps, such as whether the person behind the agent still works for you and what their account can do in the app.

Without that context, you run into two problems:

  • Rules that block too much or miss the damage. A rule that sees only the request either blocks routine work, so the business routes around it, or lets through the action that does the harm.
  • The same policy, rebuilt in every tool. A rule like "block non-finance users from accessing sensitive pay information" has to be rebuilt in each coding agent, agent platform, MCP connection, and gateway, and each copy drifts from the others.

Cloudflare MCP Server Portals bring Zero Trust controls to agent traffic

Enterprises already trust Cloudflare One, Cloudflare's SASE platform, for Zero Trust Network Access. It puts identity, device posture, and policy in front of every application an employee reaches.

Cloudflare extended that model to AI agents with MCP Server Portals, a central gateway for MCP-bound traffic from any agent platform. Developers register servers with Cloudflare, administrators choose which tools are exposed, and users reach those tools from their agent platform of choice. Routing agent traffic through the portal gives security teams the controls they already apply to people: centralized access policies, logging, and least-privilege access for human and non-human identities.

The portal is where agent traffic bound for your business systems converges. That makes it the natural place to ask one more question: should this specific action run?

Obsidian decides each action with context from the Knowledge Graph

Obsidian AI Agent Security enforces policy at runtime on the actions agents take in third-party apps. For each tool call, the Obsidian Policy Engine weighs who the agent acts for, the action requested, and what that person's account can do in the app. It returns allow, block, or require approval, with a reason passed back to the agent.

The context comes from the Obsidian Knowledge Graph, Obsidian's connected map of identities, activity, entitlements, third-party apps, integrations, and agents, plus labels the customer supplies. When HR records a termination in Workday, the Policy Engine receives it through the Knowledge Graph and blocks the next tool calls made under that engineer's identity.

Learn how the Obsidian Policy Engine decides each agent action →

One proxy URL connects your portal to the Obsidian Policy Engine

Security teams can use their existing Cloudflare deployment as the centralized integration point for Obsidian policy enforcement. Each MCP server added to the portal is configured via a unique Obsidian proxy URL that ensures the traffic passes through the Obsidian policy engine before the actual tool call is executed. From the perspective of a portal administrator, using the Obsidian proxy URL when setting up an MCP server is the only requirement. No additional configuration is required in the portal, reducing the risk of configuration errors or drift.

From there, the two platforms divide the work cleanly:

  1. The agent connects through the portal. Cloudflare Access authenticates the user with enterprise SSO and applies the organization's Zero Trust policy.
  2. Cloudflare inspects the traffic. Gateway logs the session and scans MCP traffic for sensitive data.
  3. Obsidian decides the action. Each tool call reaches Obsidian with the agent, the invoking user, the tool, and its arguments. The Policy Engine evaluates the full authority chain, using Knowledge Graph context such as HR status and app permissions plus the labels you supply, and returns allow, require approval, or block.
  4. The decision is enforced before the app sees the call. Obsidian handles OAuth delegation to the third-party app, keeps the app's token out of the AI client, and logs the decision with its full payload.

One set of policies across your Cloudflare portal, and proof of every agent action it stopped

Security teams write policies in the Obsidian console, and they apply to every MCP server in the Cloudflare portal. No rule is rebuilt in a second format or copied into another environment, where it would drift as policies change. Platform teams keep the Cloudflare deployment they already run.

Every decision is logged with the agent, the user behind it, the tool, the arguments, the outcome, and the policy that matched. A security leader can show auditors which agent actions were held or blocked, and which policy stopped each one.

Getting started

If you run Cloudflare One and Obsidian, contact your Obsidian technical account manager for more information.

‍

Frequently Asked Questions (FAQs)