Your agents reach the world through MCP. Govern that boundary.

The Model Context Protocol gives agents real tools and real data. It should also give you real control.

MCP is fast becoming how agents connect to databases, code, files, and the web - often through servers you don't control. The MCP Gateway gates every connection: an approved registry, scoped credentials, adjudicated tool calls, and inspected results, all recorded to the Ledger.

The protocol

One standard, many open doors.

The Model Context Protocol is an open standard for connecting AI applications to the outside world. An AI host - an assistant, an IDE, an agent - connects to MCP servers, and each server exposes a set of tools it can call and resources it can read: a Postgres database, a GitHub repository, a local filesystem, a web fetcher. It has spread quickly because it solves a real problem elegantly - one protocol instead of a bespoke integration per tool.

But every server is also a door. The same protocol that lets an agent query your warehouse lets it exfiltrate from it; the same connection that reads a repository can read secrets in it. MCP standardized how agents reach capability - and in doing so, standardized a surface that enterprises now have to govern deliberately, not by trusting each client to behave.

The risk

The doors you didn't know were open.

Left unmanaged, MCP fails in predictable ways. Servers proliferate until no one can say which tools an agent can actually reach. Scopes are far wider than any task needs. Credentials live with the agent, so a compromised agent inherits everything its keys can do. And an unverified server - copied from a registry, run without review - is a supply-chain dependency sitting on your data path.

The subtlest failure is the data coming back. A tool result is untrusted input the agent will act on, and a malicious document or API response can carry instructions that hijack the run. Governing only the outbound call misses half the problem.

The MCP Gateway closes both directions. It allows only registered, verified servers, attaches scoped credentials per task, adjudicates each tool call, and inspects every result before the agent sees it.

The model

Four ways the gateway holds the line.

An approved registry

Agents may only reach MCP servers on an explicit allowlist. An unknown or unverified server - the supply-chain risk at the heart of MCP - is refused at the boundary, not discovered after it has already run.

Scoped credentials

The gateway holds the keys, not the agent. Each server connection is granted only the scope a task needs - read this database, this repository, these domains - so a compromised agent can't widen its own access.

Adjudicated tool calls

Every MCP tool invocation is evaluated against policy before it executes - the same deny-by-default adjudication applied to any request. A call outside scope or over a limit is blocked or escalated inline.

Inspected results

Tool results are data the model will act on - so they're inspected on the way back. PII is redacted and injected instructions hiding in a document or API response are caught before they ever reach the agent.

Policy, not honor system

A boundary you configure once, in code.

Securing MCP by configuring each client is the honor system: it depends on every agent being set up correctly and holds only until someone changes a setting. An enterprise needs a boundary that doesn't move when an agent does.

With the gateway, MCP access is Edict - the same policy language that governs every other request. You declare which servers are allowed, the scope each one gets, and what inspection their results require. It's versioned, reviewed, and testable, and it applies to every agent that connects, regardless of how that agent was built or who is running it.

Promote the policy and the boundary changes everywhere at once. Deny-by-default means a new server is unreachable until it's explicitly approved - the opposite of the default-open sprawl MCP tends toward.

mcp-access.edictENFORCING

policy "mcp-access" {
  applies_to = agents.*

  mcp_servers allow = ["postgres", "github", "web.fetch"]
  mcp_servers deny  = ["shell.*", "filesystem.write"]

  server "postgres" {
    scope  = ["orders.read", "tickets.read"]
    redact output.matches(pii.*)
  }

  require server.verified = true
  inspect tool_result for prompt_injection
  audit = always
}

The system

The same boundary, pointed at the protocol.

The MCP Gateway is the Enforcement Fabric applied to Model Context Protocol traffic. It shares the runtime, the policy language, and the Ledger with everything else DataStrict governs - one boundary, not a separate tool to operate.

Agent Control

MCP is how agents reach the world. Agent Control governs the agent; the MCP Gateway governs its connections.

Enforcement Fabric

The runtime data path the gateway runs on - inline, bidirectional, deny-by-default.

Edict

Server allowlists, per-server scopes, and result inspection expressed as versioned policy.

Ledger

Every server connection, tool call, and verdict, recorded as immutable evidence.

FAQ

MCP governance, answered.

What is MCP (Model Context Protocol)?

MCP is an open standard for connecting AI applications and agents to external tools and data. An AI host connects to MCP servers, and each server exposes tools to call and resources to read - a database, a code repository, a filesystem, a web fetcher. It has become a common way to give agents real capabilities, which also makes it a real governance surface.

Why do MCP servers create a governance problem?

Because they hand an agent live capability, often with broad scope and credentials the agent itself holds. The risks compound: untrusted or unverified servers (a supply-chain problem), over-broad access, sensitive data leaving through a tool call, and instructions injected into the results a server returns. Most setups configure this on the honor system, in the client, with no independent enforcement.

How does DataStrict sit in an MCP setup?

As a gateway between the agent (the MCP host) and the MCP servers. Instead of connecting to servers directly, the agent connects through DataStrict, which gates every connection: it checks the server against an approved registry, attaches only the scoped credentials a task needs, adjudicates each tool call, and inspects the results - all on the request path.

Can it stop prompt injection that arrives through a tool result?

That's a core reason it inspects results. A tool result - a fetched web page, a document, an API response - is untrusted input the agent is about to act on. The gateway inspects it on the way back with layered detection, including machine-learning classifiers trained and hardened against the latest injection techniques, and can redact or block content that carries injected instructions or sensitive data before it reaches the model. Those classifiers run inside your own environment - detection never requires sending your traffic to a third party.

Do you support remote and local MCP servers?

The model is transport-agnostic: the point of control is the boundary the agent connects through, whether a server runs remotely or as a local process. Because the gateway runs inside your own environment, the credentials and the traffic stay there too - no third-party hop to reach your own tools.

How is this different from just configuring the MCP client?

Client configuration is a setting; this is enforcement. A client allowlist depends on every agent being configured correctly and can be changed by whatever runs the agent. The gateway is an independent boundary with policy-as-code, deny-by-default behavior, and an immutable audit trail - it holds even when an agent, or the person running it, would rather it didn't.

Govern AI like infrastructure.

Talk to our team about deploying DataStrict across your enterprise stack.

Request a demo Contact sales