Privometry's MCP gateway puts authorization between AI agents and their tools

What was announced

Privometry, a company building security tooling for AI-to-system connections, has described a new product called Privometry MCP Security in a post on dev.to. The product is a gateway that sits between AI assistants and the MCP servers they call. Instead of connecting a client directly to an upstream server, teams route the connection through the gateway, which inspects and evaluates each request before deciding whether to forward it. The path the company outlines runs from the agent, through the Privometry gateway, to the MCP server, and finally to the enterprise system behind it.

It is worth noting that the details come from Privometry's own announcement rather than an independent evaluation.

The governance gap MCP opens up

The post starts from a familiar premise: MCP makes it straightforward to wire a coding assistant into GitHub, Jira, databases and internal services. That convenience creates a new class of problems the author lays out directly. Who is the agent making a request, and which person is accountable for it? Can an agent be permitted to read data while being blocked from modifying or deleting it? What happens when an MCP server quietly changes a tool's definition after that tool was approved? Should some actions require a human to sign off first? And how does a team reconstruct what an agent attempted versus what actually ran?

What the gateway actually does

According to the post, the gateway covers five areas:

• Agent identity and access: registered agents are tracked along with their owners and the humans they act on behalf of, giving authorization rules real context instead of one shared credential.
• Trusted tools: servers and tools go through review and approval, and the recorded definitions are monitored so that a changed tool definition triggers a fresh review.
• Policy-based authorization: Cedar policies decide which agents may invoke which tools, with three possible outcomes — allow, deny, or hold for human approval.
• Request and response inspection: tool arguments and responses are scanned for exposed credentials and suspicious content, including possible prompt-injection payloads.
• Audit visibility: tool calls, identities, authorization decisions and execution outcomes are all logged for later investigation.

Enforcement by policy, not by the model

The post walks through a concrete scenario: a coding assistant connected to a GitHub MCP server might legitimately need to search issues and open tickets, but should never delete a repository. Privometry demonstrates this with a Cedar rule, annotated with a deny verdict, that targets the delete-repository tool specifically. The gateway evaluates the rule before forwarding anything, so a denied invocation never reaches the upstream server. Approval-oriented policies can similarly pause sensitive operations until a person reviews them.

The underlying design philosophy is notable: authorization should be deterministic and enforced outside the model, rather than hoping an AI system chooses to comply with a security instruction.

Limitations and what comes next

Privometry is explicit that the gateway does not replace authentication and authorization at the destination service. An upstream system may confirm that a credential is valid, the post argues, but it has no idea which agent initiated the call, which governance policy applies to that agent, or whether a human sign-off is needed. The gateway adds a second enforcement point with centralized policy and logging on top of that.

The company also concedes a structural weakness: a gateway can only govern traffic that actually passes through it. Any client that connects straight to an MCP server, bypassing the gateway, escapes these controls entirely and has to be found and dealt with separately.

On the roadmap are a self-service experience, a usage-limited free tier, reusable policy templates and easier policy authoring. Privometry says it is actively seeking feedback from developers, platform engineers and security teams already running MCP connections.

Why it matters

MCP is rapidly becoming the standard way to hand AI agents real capability — repositories, ticketing systems, databases. That shifts the security question from what a model can say to what an agent can do, and existing per-service authentication was never designed for non-human callers acting on someone's behalf. A gateway model imports ideas security teams already rely on for people: strong identity, least-privilege policy, change detection on the things being authorized, and audit trails. The open questions are equally important — gateway coverage is only as good as its enforcement as the mandatory path, and vendor claims like these still need real-world validation. Still, the announcement is a clear signal that agent-access governance is emerging as its own product category.