MCP is making it much easier to connect AI assistants and agents to real tools.

A coding assistant can read GitHub issues, interact with Jira, query databases, or access internal services through an MCP server.

That's useful. But once an AI agent can call those tools, a different set of questions becomes important:

  • Which agent is making the request, and which person is responsible for it?
  • Can the agent read information without being allowed to modify or delete it?
  • What happens if an MCP server changes a tool's definition after it was approved?
  • Can we require human approval before a sensitive action?
  • How do we investigate what an agent attempted and what was actually executed?

These are the problems we're building Privometry MCP Security to address.

The idea: put an authorization boundary between agents and tools

Privometry is a security and governance gateway for MCP traffic.

Instead of connecting supported AI clients directly to upstream MCP servers, teams can route those connections through Privometry.

The gateway evaluates the request before forwarding it.

The basic flow looks like this:

AI Agent → Privometry MCP Gateway → MCP Server → Enterprise System

Inside the gateway, we focus on five areas.

1. Agent identity and access

Track registered agents, their owners, their identities, and the people they act on behalf of. This provides context for authorization rules instead of relying on one shared credential.

2. Trusted MCP tools

Review and approve servers and tools. Record trusted tool definitions, detect changes, and require re-review when a previously approved definition changes.

3. Policy-based authorization

Use Cedar policies to decide which agents can invoke which tools. The gateway can allow an action, deny it, or require human approval through Privometry's policy workflow.

4. Request and response protection

Inspect tool arguments and responses for sensitive credentials and suspicious content, including potential prompt-injection attempts.

5. Activity and audit visibility

Record tool calls, identities, authorization decisions, and execution outcomes so teams can investigate agent activity.

An example: preventing repository deletion

Suppose a team connects an AI coding assistant to a GitHub MCP server.

The assistant might legitimately need to search issues, inspect repositories, or create development tickets. That doesn't mean it should be allowed to delete repositories.

In Privometry, a Cedar rule can explicitly deny a sensitive tool:

@id("no-repo-deletes") @verdict("deny") @message("Agents may not delete repositories.") forbid( principal, action == Mcp::Action::"call_tool", resource == Mcp::Tool::"github/delete_repo" );

This uses Privometry's MCP Cedar schema and rule annotations.

The gateway evaluates the rule before forwarding the invocation. If the rule denies the action, the upstream MCP tool is not called.

We also support approval-oriented policies, where sensitive operations can be held for human review.

The intention is to make authorization deterministic and independently enforced, rather than asking an AI model to decide whether it should obey a security rule.

Why not rely entirely on MCP server authentication?

Authentication and authorization at the underlying service are essential. Privometry is not intended to replace them.

But an upstream service may know that a credential is valid without knowing which agent initiated the operation, what governance policy applies to that agent, or whether an additional human approval is required.

A gateway adds another enforcement boundary, with centralized policies and activity visibility.

There is an important limitation: a gateway governs traffic that actually passes through it. Direct connections that bypass the gateway must be identified and addressed separately.

What we're building toward

Our focus is deliberately narrow for the first product: MCP security, identity-aware tool access, policy enforcement, approvals, and visibility.

We're also working toward a self-service experience with a usage-limited free plan, reusable security policy templates, and more accessible policy authoring.

We're interested in feedback from developers, platform engineers, and security teams already deploying MCP connections.

How are you currently governing MCP tool access in your organization?

Are you relying on individual MCP servers, gateway policies, existing IAM systems, or a combination?

We'd be interested in hearing what works and where the difficult parts remain.

Learn more about the project: Privometry MCP Security

Privometry is building security and governance capabilities for AI-to-tool connections. This article focuses only on MCP Security.