Introducing MCP Governance: Control Agent Access at Runtime

The stakes to safely deploy AI are higher than ever. AI risk and agent capabilities are moving so quickly that leaders are all calling to pace the frontier of development, but the pressure to adopt AI and stay ahead is immense.

We constantly hear this tension in customer conversations: How do we give increasingly capable agents more access and responsibility, but safely?

Through MCP, employees are connecting Claude Code, Codex, and other agents to Salesforce, Slack, internal knowledge bases, and production infrastructure. They can ask an agent to investigate a problem, pull information from several systems, and make changes on their behalf.

Some of the most advanced teams we speak with are deploying multiple agent security tools and trying to figure out how to bring them together. They want to move faster with AI, and they need a way to stay in control as they do.

At Lumos, we believe agent security is largely an access problem, and managing that access must extend to runtime. Here’s why.

The connections that make agents useful are exactly how they become risky

Think about what makes an agent useful at work. It needs access to your company’s systems. Connected to Salesforce, it can research customers and update opportunities. Connected to your infrastructure, it can investigate incidents and change production settings.

But how much access did you just give it? And do you know what it’s doing with that access?

We’ve seen employees drive agents to modify production feature flags, publish applications, and delete knowledge base files. In one case, what looked like an agent making simple calls to Retool’s MCP turned out to be executing arbitrary TypeScript in Retool against a read-write Salesforce connection.

That last example was very surprising to us. Most of the Salesforce calls were read queries, but the connection also allowed the agent to update, create, or delete records—and we saw it perform updates. The access available to the agent went well beyond reading data.

These are useful workflows. We want people to use agents for this work, but an employee connecting a tool can give their agent far more access than any one task needs. Anything from a simple mistake to a deliberately malicious instruction can cause dangerous changes across company systems before anyone notices.

Managing permissions alone is not enough

Companies still need to decide who should have access, to what, and for how long. An agent using an employee’s account can inherit permissions that person no longer needs, so cleaning up that access matters.

But even appropriate permissions leave questions unanswered. Someone may need to update Salesforce as part of their job. Does that mean their agent should be able to change hundreds of records? An engineer may need access to production. Which actions should their agent be allowed to take there?

Companies need to govern both the access agents receive and how they use it. That means being able to make and enforce a policy decision before an action runs.

See and control all agent tool calls

Today, we’re introducing Lumos MCP Governance to provide visibility and runtime control over MCP servers and tool calls in Claude Code and Codex.

You can see which servers and tools your employees’ agents are using, including MCP servers that users add locally with no administrator approval. As people work, Lumos records every tool call, its inputs, the human identity, and the policy decision.

Once you see the activity, you can start answering practical questions. Which tools are people actually using? Which calls carry the most risk? What caused that spike yesterday?

Our AI, Albus, helps you investigate those questions and build policies based on what’s happening in your environment. Describe a rule in plain language, review the policy, and put it into effect.

For example, you might restrict who can use a tool that changes production feature flags, or block access to a code-execution tool connected to sensitive systems. Lumos checks the policy before the call runs and returns allow or deny.

Importantly, this is not an MCP gateway. We aren't proxying all of your organization's tool calls through a single chokepoint. This works through a tool-use hook, which doesn’t reroute MCP traffic or require reconnecting servers. MCP Governance is a small, fast check built into the call itself, making runtime decisions about whether an agent is allowed to take actions that a server enables. The same interface also covers other supported tool calls, including shell commands, browser use, and file operations.

You can start by seeing what’s happening, then introduce controls as you understand where they’re needed.

The access problem is growing quickly

MCP is an important place to start, but agents are gaining more ways to work with company systems, and some of the hardest access problems are still ahead.

We are seeing early signals that Browser Use will become an especially challenging enterprise problem. When an agent operates an authenticated browser, it can use the access available through those sessions and reach applications without ever using MCP. This type of access is entirely invisible to MCP Gateways.

Further, the proliferation of cloud agents and diverse client types - in terminal, desktop apps, web, mobile, custom harness - pose new challenges. Even products from the same vendor often expose different controls.

We need ways to govern access across all of these environments.

We also need to get much better at evaluating what an action will actually do. A tool name only tells you so much when the input is an arbitrary bash command or script. A browser click might open a menu or submit a payment. Several ordinary steps combined can become dangerous.

This is a serious research and engineering problem. Checks have to catch risky actions without constantly blocking useful work. They need to be fast enough to run on every tool call and reliable enough for companies to depend on.

We’re excited about tool-use interfaces because they give us a place to observe and control actions as agents work, and a foundation to build on as those agents evolve.

Lumos governs human and agent access

Agents work through employee accounts, machine credentials, and increasingly their own identities. To govern what they do, you need to understand who is behind them and what access they have.

Lumos helps companies manage that access. MCP Governance introduces runtime control so that teams can set boundaries on how agents use the permissions they receive.

Our goal is to make it safe for companies to give increasingly capable agents the access they need to be useful.

Book a demo to see MCP Governance in action -->